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

Question

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 1

If the parent has valid records referring to DNS servers that are authoritative for the zone then resolution should mostly work.

I can think of at least one case where their might be an issue if you had different records and a couple other miss-configurations.

The issue would be related to how the name server sends out notifies when the zone updated. For example when you are using bind on the primary dns server, you update the zone and then reload, bind will send out update notifications to all the servers that are listed in the zone. If their was another authoritative server didn't have an NS record in the primary zone then it wouldn't get the notify and would have older data. If the parents where pointing at this server that isn't getting updates, then you could have problems because that server would be providing out of data results.

Also, keep in mind that there is such a thing as 'split-horizon' DNS. Sometimes you need to provide a different view of your zone to your internal hosts that are inside your network versues what you display to the public. When you are comparing the name server records make sure you viewing the zone from the same perspective.

Answer 2

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.