0

In Chapter 2.5 of Kurose - Ross (Computer Networking), DNS lookup is described. As an example, it is explained what happens when Alice requests www.networkutopia.com. Apparently, the TLD server replys to Alices local DNS server with two resource records:

(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)

So Alice client can then contact dns1.networkutopia.com. I wonder, why is the first record returned, since Alice only needs dns1.networkutopia.com. Doesn't she?

  • This question appears to be off-topic because it is not about webmastering as defined in the FAQ. – John Conde Aug 17 '18 at 22:14
  • Questions on professional server, networking, or related infrastructure administration are off-topic for Pro Webmasters. You may be able to get help on Server Fault. I recommend reading their FAQ to ensure your question is appropriate for their site. – John Conde Aug 17 '18 at 22:16
2

The example may be a little misleading, because you have the second record only as an additional information, and only because the nameservers are in the same TLD as the name queried, and even being glues (same domain).

TL;DR the NS records are what is sent as authority and they show the zone cut and the relevant "next" nameservers to query. Additional data with IP address is to help resolution, but the registry is not authoritative on it.

Let us take an example, and you can nicely see things with dig:

$ dig @a.gtld-servers.net NS google.com +nodnssec


; <<>> DiG 9.12.0 <<>> @a.gtld-servers.net NS google.com +nodnssec
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43618
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a5d7c8468ed53166
;; QUESTION SECTION:
;google.com.        IN NS

;; QUERY SIZE: 51

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43618
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.        IN NS

;; AUTHORITY SECTION:
google.com.     172800 IN NS ns2.google.com.
google.com.     172800 IN NS ns1.google.com.
google.com.     172800 IN NS ns3.google.com.
google.com.     172800 IN NS ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     172800 IN AAAA 2001:4860:4802:34::a
ns2.google.com.     172800 IN A 216.239.34.10
ns1.google.com.     172800 IN AAAA 2001:4860:4802:32::a
ns1.google.com.     172800 IN A 216.239.32.10
ns3.google.com.     172800 IN AAAA 2001:4860:4802:36::a
ns3.google.com.     172800 IN A 216.239.36.10
ns4.google.com.     172800 IN AAAA 2001:4860:4802:38::a
ns4.google.com.     172800 IN A 216.239.38.10

;; Query time: 147 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Fri Aug 17 16:13:07 EST 2018
;; MSG SIZE  rcvd: 287

I am querying one of the .com authoritative server.

Remark how the "authority" section only has the NS records telling us who are the authoritative nameservers for the domain requested, which means that any recursive DNS client should now contact any of these nameservers to go further into this resolution. There is also no "AA" flag showing that it is not an authoritative reply (because the child is authoritative on the NS records, not the parent, they are in the parent just to be able to find where the child is).

Now in the "additional" section the registry also gives you the IP addresses of those nameservers because they are "in-bailiwick" that is in the domain name itself. Without those "glue" records you will have no way to find out the IP addresses of those nameservers... because you are in fact searching how to resolve the domain name under which they are. So an infinite circle.

Let us take another example without glues.

I have simplified the output, you have the authority section and then the additional one.

$ dig @a.gtld-servers.net NS amazon.com +nodnssec +noall +auth +add +nocookie

; <<>> DiG 9.12.0 <<>> @a.gtld-servers.net NS amazon.com +nodnssec +noall +auth +add +nocookie
; (1 server found)
;; global options: +cmd
amazon.com.     172800 IN NS pdns1.ultradns.net.
amazon.com.     172800 IN NS pdns6.ultradns.co.uk.
amazon.com.     172800 IN NS ns1.p31.dynect.net.
amazon.com.     172800 IN NS ns3.p31.dynect.net.
amazon.com.     172800 IN NS ns2.p31.dynect.net.
amazon.com.     172800 IN NS ns4.p31.dynect.net.
pdns1.ultradns.net. 172800 IN AAAA 2001:502:f3ff::1
pdns1.ultradns.net. 172800 IN A 204.74.108.1
ns1.p31.dynect.net. 172800 IN A 208.78.70.31
ns3.p31.dynect.net. 172800 IN A 208.78.71.31
ns2.p31.dynect.net. 172800 IN A 204.13.250.31
ns4.p31.dynect.net. 172800 IN A 204.13.251.31

Observe that you do not get the IP address of pdns6.ultradns.co.uk. because it is in a TLD not managed by this registry at all. Other nameservers are in .NET which is the same registry as .COM so you find out these records that helps the client but which are not authoritative. Instead of using these IPs a client could start to resolve pdns1.ultradns.net. again by the exact same process (and then discover that ultradns.net has at least pdns196.ultradns.net. has glue).

In fact an even more telling example:

$ dig @a.gtld-servers.net NS ultradns.net +nodnssec +noall +auth +add +nocookie

; <<>> DiG 9.12.0 <<>> @a.gtld-servers.net NS ultradns.net +nodnssec +noall +auth +add +nocookie
; (1 server found)
;; global options: +cmd
ultradns.net.       172800 IN NS pdns196.ultradns.com.
ultradns.net.       172800 IN NS pdns196.ultradns.net.
ultradns.net.       172800 IN NS pdns196.ultradns.org.
ultradns.net.       172800 IN NS pdns196.ultradns.info.
ultradns.net.       172800 IN NS pdns196.ultradns.biz.
ultradns.net.       172800 IN NS pdns196.ultradns.co.uk.
ultradns.net.       172800 IN NS ari.alpha.aridns.net.au.
ultradns.net.       172800 IN NS ari.beta.aridns.net.au.
ultradns.net.       172800 IN NS ari.gamma.aridns.net.au.
ultradns.net.       172800 IN NS ari.delta.aridns.net.au.
pdns196.ultradns.com.   172800 IN A 156.154.64.196
pdns196.ultradns.com.   172800 IN AAAA 2001:502:f3ff::e8
pdns196.ultradns.net.   172800 IN A 156.154.65.196
pdns196.ultradns.net.   172800 IN AAAA 2610:a1:1014::e8

See how this domain has 10 nameservers, in 7 TLDs (6 different registries), with only two in the same registry as the one you were querying, so in the second part, the additional part you only have A and AAAA records for the 2 nameservers that are under .COM and .NET.

This also explains why sometimes you will have no IP addresses at all there in fact.

For example, let us ask the .FR registry what it thinks about amazon.fr:

$ dig @d.nic.fr amazon.fr NS +noall +auth +add

; <<>> DiG 9.12.0 <<>> @d.nic.fr amazon.fr NS +noall +auth +add
; (1 server found)
;; global options: +cmd
amazon.fr.      172800 IN NS ns1.p31.dynect.net.
amazon.fr.      172800 IN NS ns2.p31.dynect.net.
amazon.fr.      172800 IN NS pdns1.ultradns.net.
amazon.fr.      172800 IN NS pdns3.ultradns.org.
amazon.fr.      172800 IN NS pdns4.ultradns.org.
amazon.fr.      172800 IN NS pdns5.ultradns.info.

Absolutely no IP addresses are returned because all of amazon.fr authoritative nameservers are outside of the .FR zone, so the registry has no idea about what their IP addresses are and just gives you, as expected, the names you will need to resolve yourself before being able to connect to them to ask for further resolution of amazon.fr, etc. (yes that may involve a lot of steps, but remember that the DNS uses caches, so "hot" domains will not need many steps after the first query because all relevant IP addresses of nameservers involved will be cached; but besides these operational/perfomance aspects these steps also show you the dependencies between things, where they are normally mostly hidden; various studies such as https://arxiv.org/pdf/1806.08420.pdf can show you DNS/CDN/X509 dependencies as they exist today).

Not the answer you're looking for? Browse other questions tagged or ask your own question.