Strange ns answers...

[Rodney Joffe]

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.

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 :-):

[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 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.

Do you agree with that? Or is there a way around it?

-- 
Rodney Joffe
CenterGate Research Group, LLC.
http://www.centergate.com
"Technology so advanced, even we don't understand it!"(SM)