Strange ns answers...

Thu Aug 24 07:47:52 UTC 2000

> 
> Rodney Joffe wrote:
> 
> > Kevin Darcy wrote:
> >
> > > For any *child* *zone* served by a nameserver whose name is outside of th
> e *parent* *domain*, e.g.
> > > ns2.msas.net serving baylink.com, then yes, if RFC 2870 is strictly adher
> ed 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 overla
> p between the root
> > > servers, the "com" servers, the "net" servers, etc. f.root-servers.net, f
> or 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 a
> s 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 o
> r a com slave?
> 
> > However...
> > >
> > > None of this, however, has anything to do with your inconsistent Addition
> al Sections from 4.2.2.1,
> > > which is neither a root, "com" or "net" server, for a baylink.com NS quer
> y. 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 an
> d that this explains the
> closeness of the TTL's, but you have a good point. I'm now starting to lean m
> ore towards "single
> machine, inconsistent Additional sections" rather than multiple machines. Whi
> ch is rather bizarre.
> Maybe it's "trimming" the responses based on dynamically-updated link-level-u
> tilization 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 a
> rrived 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 millis
> econds after the server
> answered you. What you showed before was an Additional section A record appea
> ring, 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?

	No.  It just didn't cache it in the first place.

> 
> > 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
> 
> 
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com