Manually doing a recursive DNS query

Question

In my ongoing experiments to understand DNS, I'm trying to understand how a nameserver does a recursive query. I get the basic idea - you start with a top level dns server, then it sends you a list of authoritative nameservers to contact, then you contact those servers, etc., until you get a authoritative response.

Sounds simple enough.

But when I try it in practice, I get stuck after the first step. I'm just doing this manually with command line tools - (I make sure to turn off recursion.)

Okay, so step 1: start with a root name server. I randomly picked 198.41.0.4 (Verisign) from the list of root name servers on Wikipedia.

I send it a request to resolve "google.com".

It sends me back the following:

+---------------------------------------------------------------------------+
| 47547 | QR: 1 | OP: 00 | AA: 0 | TC: 0 | RD: 1 | RA: 0 | Z: 0 | RCODE: 00 |
+---------------------------------------------------------------------------+
| QDCOUNT:     1,   ANCOUNT:     0,   NSCOUNT:    13,   ARCOUNT:    15      |
+---------------------------------------------------------------------------+

ANSWERS : 0

AUTHORITIES:
NS: m.gtld-servers.net
NS: l.gtld-servers.net
NS: k.gtld-servers.net
NS: j.gtld-servers.net
NS: i.gtld-servers.net
NS: h.gtld-servers.net
NS: g.gtld-servers.net
NS: f.gtld-servers.net
NS: e.gtld-servers.net
NS: d.gtld-servers.net
NS: c.gtld-servers.net
NS: b.gtld-servers.net
NS: a.gtld-servers.net

ADDITIONAL:
A: 192.55.83.30
A: 192.41.162.30
A: 192.52.178.30
A: 192.48.79.30
A: 192.43.172.30
A: 192.54.112.30
A: 192.42.93.30
A: 192.35.51.30
A: 192.12.94.30
A: 192.31.80.30
A: 192.26.92.30
A: 192.33.14.30
AAAA: 2001:0503:231d:0000:0000:0000:0002:0030
A: 192.5.6.30
AAAA: 2001:0503:a83e:0000:0000:0000:0002:0030

Okay, so I'm not sure what the point of all those ADDITIONAL records are - they all appear to be local LAN addresses so I don't know what use they are to me. But anyway, looking at the results returned in the authority section, I see another list of name servers. Okay, so I guess the next step is I need to choose one of the name servers returned, and get it's IP. So I issue a request to resolve a.gtld-servers.net, and...

...it just returns the exact same list of nameservers.

So... I'm not sure how to proceed here. How do I ultimately get to the authoritative name server for "google.com"?

EDIT:

Okay, so it appears those 192 addresses are not LAN addresses as I wrongly assumed, but they are other nameservers. I'm assuming I can contact those nameservers to get closer to the authority. But, how am I supposed to know to use these nameservers? I thought that the ARCOUNT section was just for additional information... why are all those nameservers placed in the ADDITIONAL section instead of as answers or authorities? Is it just some convention that referrals to other nameservers go in the ADDITIONAL section?

Answer 1

You can use the dig +trace command : it will exactly show you each query made by a typical recursive nameserver.

If you try for example for www.google.com (if you do not specify the type, dig uses A by default, and I removed DNSSEC related information with +nodnssec to simplify the output):

$ dig +trace www.google.com +nodnssec

; <<>> DiG 9.12.0 <<>> +trace www.google.com +nodnssec
;; global options: +cmd
.           307678 IN NS f.root-servers.net.
.           307678 IN NS a.root-servers.net.
.           307678 IN NS m.root-servers.net.
.           307678 IN NS e.root-servers.net.
.           307678 IN NS i.root-servers.net.
.           307678 IN NS l.root-servers.net.
.           307678 IN NS c.root-servers.net.
.           307678 IN NS g.root-servers.net.
.           307678 IN NS b.root-servers.net.
.           307678 IN NS k.root-servers.net.
.           307678 IN NS h.root-servers.net.
.           307678 IN NS d.root-servers.net.
.           307678 IN NS j.root-servers.net.
;; Received 447 bytes from 192.168.10.229#53(192.168.10.229) in 5 ms

com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.
;; Received 839 bytes from 192.36.148.17#53(i.root-servers.net) in 88 ms

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.
;; Received 291 bytes from 192.5.6.30#53(a.gtld-servers.net) in 145 ms

www.google.com.     300 IN A 172.217.7.196
;; Received 48 bytes from 216.239.34.10#53(ns2.google.com) in 83 ms

Each paragraph is one query, showing the reply and who replied (who we queried).

Let us go back at first query, to redo what you did with 198.41.0.4 (aka a.root-servers.net:

$ dig A www.google.com @198.41.0.4 +nodnssec

; <<>> DiG 9.12.0 <<>> A www.google.com @198.41.0.4 +nodnssec
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44332
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b56cbe6c8ffd3856
;; QUESTION SECTION:
;www.google.com.        IN A

;; QUERY SIZE: 55

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;www.google.com.        IN A

;; AUTHORITY SECTION:
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
m.gtld-servers.net. 172800 IN A 192.55.83.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30

;; Query time: 134 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Wed Aug 15 09:39:43 EST 2018
;; MSG SIZE  rcvd: 839

So what is happening here:

1. you have no aa flag in reply, which shows that the nameserver replying is NOT authoritative for this query (it will be authoritative if you ask it for . NS for example)
2. it tells you in AUTHORITY SECTION who is authoritative for the next step, that is com.; this means giving you a set of nameservers (NS records)
3. to help you go faster in ADDITIONAL SECTION it gives you IP addresses of the above nameservers, as otherwise you will first need to resolve their name to an IP to be able to contact them.

The sections are defined in RFC1034:

The four sections are:

Question Carries the query name and other query parameters.

Answer Carries RRs which directly answer the query.

Authority Carries RRs which describe other authoritative servers. May optionally carry the SOA RR for the authoritative data in the answer section.

Additional Carries RRs which may be helpful in using the RRs in the other sections.

So the data could not be put in the "Answer" section, since it does not answer directly the query presented, nor in the "Authority" section, since the nameserver you queried is not authoritative over gtld-servers.net

Which also explain why dig A e.gtld-servers.net. @198.41.0.4 +nodnssec will return basically the same answer, but it is mostly because .com and .net are handled by one and the same registry (VeriSign) and they share the same authoritative nameservers (and VeriSign also handles two root nameservers - a and j - but this is unrelated)

So, yes, next step would be to connect to any IP given for a gtld-servers.net nameserver to redo the query and find out if it is authoritative for www.google.com, and since it is not it will provide the next step in the "Authority" section.

Like so:

$ dig A www.google.com @a.gtld-servers.net. +norecurse +nodnssec

; <<>> DiG 9.12.0 <<>> A www.google.com @a.gtld-servers.net. +norecurse +nodnssec
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26904
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 22d54e7533355129
;; QUESTION SECTION:
;www.google.com.        IN A

;; QUERY SIZE: 55

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26904
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

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

;; 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: 142 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Wed Aug 15 09:54:27 EST 2018
;; MSG SIZE  rcvd: 291

And so on.

Also you are mistaken about:

they all appear to be local LAN addresses so I don't know what use they are to me.

Private addresses space is described by RFC 1918 which lists:

10.0.0.0 - 10.255.255.255 (10/8 prefix)

172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

None of the IP are in these blocks, thankfully.

Answer 2

There is something wrong in your query to Verisign servers. Try this:

1. dig @<VeriSign-nameserver> google.com NS. : this should get you the aUuthoritative nameservers for google.com
2. dig @<NS for google.com> www.google.com A. : this gets you the A records for www.google.com from google.com nameservers.

Note: if google.com nameservers are in the same zone as google.com, #1 should return you glue records, which means it would also resolve the IP address for the nameservers.