Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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, 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

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 (against a root server), I wind up with:

Served By:

... and so and and so forth. So basically at this point, I have to resolve in order to query it to get the A-record for, however, given the scenario, I don't have a server I can to query for the address of If I attempt to resolve 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. :)

share|improve this question
up vote 4 down vote accepted

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, they don't just say that it's hosted by, but also give you the IP addresses of 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 and they will give you its IP address. You can see for yourself that the root zone file holds this information.

For example:

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

;            IN  A

com.            172800  IN  NS
com.            172800  IN  NS
com.            172800  IN  NS

;; ADDITIONAL SECTION: 172800  IN  A 172800  IN  A 172800  IN  A

Continuing with one of the com. name servers:

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

;            IN  A

;; AUTHORITY SECTION:     172800  IN  NS     172800  IN  NS     172800  IN  NS     172800  IN  NS

;; ADDITIONAL SECTION:     172800  IN  A     172800  IN  A     172800  IN  A     172800  IN  A

Continuing with one of the name servers:

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

;            IN  A

;; ANSWER SECTION:     300 IN  A     300 IN  A     300 IN  A     300 IN  A     300 IN  A

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

share|improve this answer
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. – Technik Empire Aug 3 '14 at 0:58
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. – Technik Empire Sep 22 '14 at 14:37
@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". – grawity Sep 22 '14 at 15:30
(This unfortunately means it's possible to misconfigure multiple domains so that the resolver would bounce between them, e.g. is at, but is at – grawity Sep 22 '14 at 15:31
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 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. :) – Technik Empire Sep 22 '14 at 15:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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