How to do full A-Record resolution from root DNS servers

3

1

I have a hypothetical situation that I've been unable to find any real answer to. Imagine we have a computer that has never been on the internet. The computer is also on a network where no DNS service is provided. Lets also pretend that things like google public DNS don't exist.

Now let's assume that the only thing this computer has is the root DNS servers' names and resolved addresses, like so.

Now this computer wants to know the IP address of say, superuser.com. How, with only having the IP addresses of root servers, does the computer work through queries to a root server in order to wind up with the resolved A-record of superuser.com?

I've made attempts but I always wind up in a place where I need to use an existing DNS server that I know of to resolve an A-Record. For example if I open command prompt and start trying to resolve google.ca (against a root server), I wind up with:

Served By:
ns1.google.com
google.ca
ns2.google.com
google.ca

... and so and and so forth. So basically at this point, I have to resolve nsX.google.com in order to query it to get the A-record for google.ca, however, given the scenario, I don't have a server I can to query for the address of nsX.google.com. If I attempt to resolve ns1.google.com back from the root server, I wind up in the same place.

Short version: How the hell do I resolve the A-Record for a domain without using any other information except what is provided to me by a root server? Thanks in advance. :)

user72945

Posted 2014-08-02T22:27:49.363

Reputation:

Answers

4

Your situation is not unusual the slightest bit; every time a full-featured recursive resolver is started – such as BIND9 or Unbound, even the copy I've running on my laptop – it starts with just a list of root zone 'hints', and descends from there all by itself.

(You said "Imagine a world where Google Public DNS doesn't exist". Ever wonder how Google Public DNS itself resolves all domain names?)

But replies to DNS queries can have more than just a straight answer. Specifically, if a domain's authoritative name servers are in the same domain, then a copy of their addresses – aka, glue records – will be held by the parent domain as well.

So when you query the com. name servers for www.google.com, they don't just say that it's hosted by ns1.google.com, but also give you the IP addresses of ns1.google.com in the same reply message!

In fact, you should have already hit this earlier, with the com. top-level domain. When you query the root name servers – they will tell you that all of com. is hosted by m.gtld-servers.net. and they will give you its IP address. You can see for yourself that the root zone file holds this information.

For example:

$ dig @198.41.0.4 www.google.com. A
;; opcode: QUERY, status: NOERROR, id: 61096
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 16

;; QUESTION SECTION:
;www.google.com.            IN  A

;; AUTHORITY SECTION:
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
...

;; ADDITIONAL SECTION:
m.gtld-servers.net. 172800  IN  A   192.55.83.30
l.gtld-servers.net. 172800  IN  A   192.41.162.30
k.gtld-servers.net. 172800  IN  A   192.52.178.30
...

Continuing with one of the com. name servers:

$ dig @192.55.83.30 www.google.com. A
;; opcode: QUERY, status: NOERROR, id: 46406
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5

;; 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  A   216.239.34.10
ns1.google.com.     172800  IN  A   216.239.32.10
ns3.google.com.     172800  IN  A   216.239.36.10
ns4.google.com.     172800  IN  A   216.239.38.10

Continuing with one of the google.com. name servers:

$ dig @216.239.34.10 www.google.com. A
;; opcode: QUERY, status: NOERROR, id: 7744
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.            IN  A

;; ANSWER SECTION:
www.google.com.     300 IN  A   173.194.32.50
www.google.com.     300 IN  A   173.194.32.49
www.google.com.     300 IN  A   173.194.32.52
www.google.com.     300 IN  A   173.194.32.48
www.google.com.     300 IN  A   173.194.32.51

We finally received an authoritative answer (aa) for the same name we asked for.

user1686

Posted 2014-08-02T22:27:49.363

Reputation: 283 655

ahhh ok thanks for the thorough answer @grawity, maybe it's because I was using crappy "nslookup" on the command line, it was just hiding these details from me. Thanks again. – None – 2014-08-03T00:58:29.670

Just as an FYI, this actually doesn't work. It may very well work for the com. TLD, but not everything. I'm looking up a .ca domain starting at the root and the chain that should happen (like you display here) completely breaks down. I wind up with just NS entries with no addresses provided for them. I suppose I then have to return to the top and start looking up those nameserver domains, then returning back to where i left off looking for the .ca. Will post back. Using dig on ubuntu server. – None – 2014-09-22T14:37:14.033

@DigitalArchitect: Yes, if the nameservers aren't actually "under" the domain they're serving, then the glue records are optional, and you will need to look up their address yourself, as a "side trip". – user1686 – 2014-09-22T15:30:43.843

(This unfortunately means it's possible to misconfigure multiple domains so that the resolver would bounce between them, e.g. a.com is at ns1.b.net, but b.net is at ns2.a.com...) – user1686 – 2014-09-22T15:31:27.340

I'm going to leave your answer as a the accepted answer, but after this I'm going to post an additional answer of how I'm resolving this problem in C# using arsoft.tools.net. I'll post the code of a function that (should) resolve any domain of any TLD from only the root zone file information. Just because this is such a ridiculously (over)complicated recursive method, I figure a code snippet will both expound on exactly how the process works and provide people with a code base to copy-and-paste from. :) – None – 2014-09-22T15:57:50.087

"... how I'm resolving the problem" .. see what I did there. ;) – None – 2014-09-22T15:58:20.910

Asked: 2014-08-02T22:27:49.363

Viewed: 1 423 times

Active: 2014-08-02T23:30:15.220