Strange ns answers...

[Kevin Darcy]

Rodney Joffe wrote:

> Kevin Darcy wrote:
>
> > For any *child* *zone* served by a nameserver whose name is outside of the *parent* *domain*, e.g.
> > ns2.msas.net serving baylink.com, then yes, if RFC 2870 is strictly adhered to, the requesting
> > server will have to do an extra lookup to get the address information for the Additional Section.
> > But RFC 2870 is *not* strictly adhered to: there's still plenty of overlap between the root
> > servers, the "com" servers, the "net" servers, etc. f.root-servers.net, for instance, consistently
> > returns ns2.msas.net in the Additional Section of a baylink.com referral, because that root server
> > also happens to serve "net" and the ns2.msas.net address record is held as glue for the msas.net
> > domain.
>
> But RFC 2870 *is* strictly adhered to by all the ?.root-servers.net and
> ?.gtld-servers.net. Which is what counts here.

If it's being strictly adhered to, how can a root slave also be a net slave or a com slave?

> However...
> >
> > None of this, however, has anything to do with your inconsistent Additional Sections from 4.2.2.1,
> > which is neither a root, "com" or "net" server, for a baylink.com NS query. I still maintain that
> > you got those responses from different nameservers.
>
> I disagree. Perhaps you can explain the decaying ttl in the ns record
> that is consistent and logical based on the intervals timestamped
> between the queries? Or are you suggesting that a query of one
> nameserver in a local pool triggers immediate mirroring on the "other"
> local machines behind the nat? Or that two different people made queries
> for the same domain at the same time, hitting different machines?. I
> believe that the 4.2.2.1 recursive servers at Genuity consist of single
> machines sharing the same ip address but at different points in
> Genuity's network. And not, I believe, behind a nat or load balancer
> anywhere. However, that's not really the point of my query, although it
> is an apparent weirdness in the bind installation on that machine. The
> following is the point I should have made, and I assure you, there is
> *only* one machine answering :-):

Well, it's conceivable that they are somehow communicating with each other and that this explains the
closeness of the TTL's, but you have a good point. I'm now starting to lean more towards "single
machine, inconsistent Additional sections" rather than multiple machines. Which is rather bizarre.
Maybe it's "trimming" the responses based on dynamically-updated link-level-utilization metrics (???)

> [rjoffe at layer9 rjoffe]$ dig baylink.com ns
>
> ; <<>> DiG 8.1 <<>> baylink.com ns
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> ;; QUERY SECTION:
> ;;      baylink.com, type = NS, class = IN
>
> ;; ANSWER SECTION:
> baylink.com.            19h35m24s IN NS  NS1.THPL.LIB.FL.US.
> baylink.com.            19h35m24s IN NS  NS2.MSAS.NET.
>
> ;; ADDITIONAL SECTION:
> NS2.MSAS.NET.           5h50m56s IN A   209.216.94.44
>
> ;; Total query time: 1 msec
> ;; FROM: layer9.com to SERVER: default -- 204.74.73.5
> ;; WHEN: Wed Aug 23 16:25:59 2000
> ;; MSG SIZE  sent: 29  rcvd: 103
>
> [rjoffe at layer9 rjoffe]$ dig baylink.com ns
>
> ; <<>> DiG 8.1 <<>> baylink.com ns
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
> ;; QUERY SECTION:
> ;;      baylink.com, type = NS, class = IN
>
> ;; ANSWER SECTION:
> baylink.com.            19h35m22s IN NS  NS2.MSAS.NET.
> baylink.com.            19h35m22s IN NS  NS1.THPL.LIB.FL.US.
>
> ;; ADDITIONAL SECTION:
> NS2.MSAS.NET.           5h50m54s IN A   209.216.94.44
> NS1.THPL.LIB.FL.US.     23h59m58s IN A  204.198.80.2
>
> ;; Total query time: 1 msec
> ;; FROM: layer9.com to SERVER: default -- 204.74.73.5
> ;; WHEN: Wed Aug 23 16:26:01 2000
> ;; MSG SIZE  sent: 29  rcvd: 119

This pair of queries isn't nearly as strange as what you showed before. It's quite common for a
recursive nameserver to return a partial (or empty) Additional section on the first query, and then a
full one on the next, because the answer to the "fetch-glue" query may have arrived in the interim.
Note that the extra A record on the second response has only aged 2 seconds, which is also the time
between queries, so maybe the "fetch-glue" response arrived only a few milliseconds after the server
answered you. What you showed before was an Additional section A record appearing, disappearing and
then re-appearing, even though the TTL was nowhere near expiration. *That* is bizarre. That implies
that the server deliberately omitted the A record on the second response even though it was still in
its cache. Why?

> This would indicate that it can be detrimental to use nameservers that
> are outside the domain's Tree/Parent/Zone etc. especially if the "in
> zone" nameserver is unreachable.

Detrimental only if you use bizarro nameservers like 4.2.2.1 :-)


- Kevin