Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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?

like image 546
Kristian B Avatar asked Mar 11 '09 19:03

Kristian B


People also ask

Can a domain have multiple NS records?

A domain often has multiple NS records which can indicate primary and secondary nameservers for that domain. Without properly configured NS records, users will be unable to load a website or application. Note that NS records can never point to a canonical name (CNAME) record.

What does NS mean in DNS records?

An NS record (or nameserver record) is a DNS record that contains the name of the authoritative name server within a domain or DNS zone. When a client queries for an IP address, it can find the IP address of their intended destination from an NS record via a DNS lookup.

Why are multiple nameservers NS provided in the authority section?

NS records help to ensure that all of the domains on your server are available at all times. Multiple NS records ensure that your customers are able to reach your site each and every time without any problems, even if one or more of your nameservers are unreachable.

Which zone maps name to IP address in DNS?

The in-addr.arpa Domain The domain is the part of your zone that enables address-to-name mapping. in-addr.arpa domain IP addresses are read from lowest level to the root. Thus, the IP addresses are read backward.


1 Answers

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.

like image 174
bortzmeyer Avatar answered Oct 13 '22 19:10

bortzmeyer