DNS: Do the NS names set for a zone have to match the NS names reported by the upstream TLD servers?

Kristian B picture Kristian B · Mar 11, 2009 · Viewed 7.3k times · Source

I've noticed that several service providers are operating DNS services for their clients' domains with NS names set for the zone and returned by the authoritative name server (in authority section / NS & SOA records) that don't match the NS names returned by the upstream server (e.g. TLD servers) and which were used for the lookup.

Example:

$ dig the-domain-name-here.com NS

; <<>> DiG 9.4.2-P1 <<>> the-domain-name-here.com NS
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7844
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;the-domain-name-here.com.          IN      NS

;; ANSWER SECTION:
the-domain-name-here.com.   172370  IN      NS      ns1.service-provider-here.net.
the-domain-name-here.com.   172370  IN      NS      ns2.service-provider-here.net.

;; ADDITIONAL SECTION:
ns1.service-provider-here.net.      7200    IN      A       192.168.100.1
ns2.service-provider-here.net.      7200    IN      A       192.168.100.2

;; Query time: 65 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Mar 11 19:44:00 2009
;; MSG SIZE  rcvd: 118

$ dig @ns1.service-provider-here.net. the-domain-name-here.com

; <<>> DiG 9.4.2-P1 <<>> @ns1.service-provider-here.net  the-domain-name-here.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48010
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;the-domain-name-here.com.          IN      A

;; ANSWER SECTION:
the-domain-name-here.com.   86400   IN      A       192.168.100.3

;; AUTHORITY SECTION:
the-domain-name-here.com.   86400   IN      NS      ns1.different-trade-name.net.
the-domain-name-here.com.   86400   IN      NS      ns2.different-trade-name.net.

;; Query time: 68 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Wed Mar 11 19:46:00 2009
;; MSG SIZE  rcvd: 100

The gTLD servers say the name server is ns1.service-provider-here.net and when we lookup the name at that server, it gives an authoritative answer but leaks a different NS name in the authority section (ns1.different-trade-name.net).

There are thousands of domains configured in this way. It doesn't seem to cause any problems, but it seems so wrong.

Does this actually matter? Is there ever going to be a situation where resolvers/clients will do an extra lookup or even fail to resolve the name because of this?

Answer

bortzmeyer picture bortzmeyer · Mar 12, 2009

Well, the answer depends on the point of view.

Technically, there is no doubt that any discrepancy between the parent and the zone is wrong. It should never happen (some registries use automatic tools to check that, for instance Zonecheck in .fr).

Practically, it happens quite often. The most common cause is that people change the NS records in their zone and forget to tell the registry (or registrar, if the registry forces you to go through a middleman) about the change.

Does it really matter? Well, as you said, as long as there is a non-empty intersection between the two sets, it should work. But it is dangerous to rely on it since one more change and the two sets may be completely separated. So, it is not a good idea to accept a discrepancy.

Legally speaking, the child zone is always right, the NS records in the parent are not authoritative. Resolvers must replace the delegation by the list they find in the child zone.