Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Right now I'm taking an online course for Linux sysadmin and I was asked a question I just generally don't understand. I know how to search for a name server, if I'm correct at least it's using the dig command to find the addressed in the additional section command, but I became a bit lost when asked the following question.

Assuming your configured nameserver does not have any cached results at its disposal, how many nameservers must your nameserver query in order to resolve maps.google.com? What command(s) would you use to find all these nameservers? List one from each level and explain why this level is needed.

I don't want the answer, I would just like to know what I am being asked to do exactly.

share|improve this question
    
I was thinking dig +trace, but I'm not sure what is meant by levels. This might be a question for Server Fault. –  Koveras May 8 at 17:36
    
Hi linux8807. I edited your question to hopefully make it more clear; particularly, I tried to put a better title on it. If you feel I changed your intent, feel free to revert the edit (click the "edited" link and then "rollback" above the original revision). –  Michael Kjörling May 8 at 20:37
add comment

2 Answers 2

Assuming your configured nameserver does not have any cached results at its disposal, how many nameservers must your nameserver query in order to resolve maps.google.com? What command(s) would you use to find all these nameservers? List one from each level and explain why this level is needed.

Well, let's pick this one apart.

"Assuming your configured nameserver does not have any cached results at its disposal" -- first off, if it has no cached data at all, then it cannot resolve anything. In order to prime the resolver's cache, you need to have the NS and address (A, AAAA) records for the . (A.K.A. root) zone. That's the root name servers, which are found in the root-servers.net. zone. There's nothing magical about that zone or those DNS servers. However, this data is often provided "out of band" to the DNS resolver, precisely to prime the resolver's cache. Authoritative-only name servers don't need this data, but resolving name servers do.

Also, "resolve" to what? Any RRtype at that name? An A RR? Or something else? What class (CH/Chaosnet, IN/Internet, ...)? The exact process will be different, but the general idea remains the same.

If we can assume that we know how to find the root name servers but nothing more, and that by "resolve" we mean getting the contents of any IN A RRs associated with the name, it gets a lot more practical.

To resolve a DNS name, you basically split the name into labels and then work your way from right to left. Don't forget the . at the end; you'd really be resolving maps.google.com. rather than maps.google.com. That leaves us with needing to resolve (we know this, but a DNS resolver implementation probably won't):

  • .
  • com.
  • google.com.
  • maps.google.com.

Start with figuring out where to ask for the content of .. That's easy; we already have that information: the root name server names and IP addresses. So we have a root name server. Let's say we decide to use 198.41.0.4 (a.root-servers.net, also 2001:503:ba3e::2:30) to continue the name resolution. In practice, one of the first things done by the resolver will likely be to use the provided root server data to ask one of the root zone servers for an accurate list of the name servers for the root zone, thus ensuring that if any one of the names and IP addresses is valid and reachable, it'll have a full and complete set of data for the root zone when resolution begins.

Shoot off a DNS query for maps.google.com. IN A to 198.41.0.4. It'll tell you in response "nope, not gonna do it, but here's someone who might know"; that's a referral. It contains NS records for the closest zone that the server in question knows about, along with any glue records the server happens to have available. If no glue data is available, you first have to resolve that host named in the NS record you picked, so spawn a separate name resolution to get the IP address; if glue data is available, you'll have the IP address of a name server that is at least "closer" to the answer. In this case, that'll be the set of servers for the com. zone, and glue data is provided as well.

Repeat the process, asking one of the com. name servers the same question. They don't know either, but will refer you to Google's authoritative name servers. At this point in the general case it'll be hit or miss whether glue data is provided or not; there's nothing preventing a com domain to have name servers only in nl, for example, in which case glue data is unlikely to be available from the gTLD servers. The provided glue data might also be incomplete, or if you're really unlucky it might even be incorrect! You have to always be prepared to spawn off that separate name resolution I mentioned above.

Basically, you keep going until you get an answer with the aa (authoritative answer) flag set. That answer will tell you what you're asking for, or that the RR you asked for doesn't exist (either NXDOMAIN, or NOERROR with zero response data records). Keep looking out for responses like SERVFAIL (and back off one step and try another server if you get one; if all named servers return SERVFAIL, fail the name resolution process and return SERVFAIL yourself to the client).

The alternative to asking for the full RRname from each server (which might be considered bad practice) is to use the split-up list of labels that we determined earlier, ask the name servers given by the server further toward the root for IN NS and IN A/IN AAAA RRs for that label, and use those to further the name resolution process. That's only marginally different in practice, and the same process still applies.

You can simulate this entire process by using the +trace option to the dig utility, which comes as part of BIND, or set debug in nslookup.

It's also worth remembering that some RRtypes (notably NS, MX and a few others; also, A6 was reasonably well-used for a while but has been deprecated) can and do reference other RRs. In that case, you may need to spawn off yet another name resolution process to give a complete and useful reply to your client.

share|improve this answer
    
I think that this answer is quite inline with the OP's request to understand the concepts rather than just the procedure. –  datUser May 8 at 21:10
    
So what I'm doing is dig maps.google.com IN A, then I would dig the same way but with ns1.google.com if that is correct, if that is, what levels are the teacher talking about and why would they be needed? –  linux8807 May 9 at 18:08
    
@linux8807 You would dig for the ns1.google.com name once you have received a referral to it that does not include an IP address in the glue records provided. Then you would continue with the previous name resolution process. –  Michael Kjörling May 12 at 7:20
    
@MichaelKjörling All of the ns1-4.google.com records have an ip address in the glue records. i.imgur.com/o79aIGB.png –  linux8807 May 20 at 16:36
    
@linux8807 That will very often be the case when the glue records are under the same TLD as the domain being queried for. You cannot rely on it in the general case however. –  Michael Kjörling May 21 at 7:41
add comment

There is a dnstracer command (you may need to install it, at least on Debian, that's also the package name) which will trace name resolution. You can also (as Koveras points out in a comment) use dig.

Here is with dnstracer. -s . means to start with the root; -4 means to use IPv4 (v6 is broken here...); -o means to actually show the resolved IP addresses at the end (I've omitted that part of the output, there are a lot of them).

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

That output continues, as dnstracer traces all paths (so you can see if, e.g., some of the nameservers have an outdated zone).

So, you can see it takes one query to the root name server, then one to the gtld-servers (the server for the .com zone), the finally one to a Google nameserver.

With dig, the output is much more verbose (so I will do a lot of cutting):

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

dig additionally shows that it did a query to obtain the current list of root nameservers. This is something a DNS server will typically do very infrequently. So I'm not sure if you count it in your cold cache case.

You can of course also watch the actual queries on the wire with, e.g., wireshark.

share|improve this answer
    
I wouldn't be able to install anything because it's setup in a terminal but once I get home from work I will try the dnstracer and see if that works, and is she asking for * (216.239.38.10) (216.239.36.10) (216.239.32.10) (216.239.34.10) * this? If so, I'm already in a sense able to access that but not with an authoritative answer. Also, is this what she is referring to by levels? –  linux8807 May 8 at 19:33
    
@linux8807 You can use dig if you don't have dnstracer (or if you like dig's formatting). The IP addresses dnstracer is outputing are the IP addresses of the nameservers; their names are to the left. a.root-servers.net is 198.41.0.4, etc. Those are the servers being queried, and it tells you for what zone as well in square brackets. I suspect the first level is *.root-servers.net (for .), second is *.gtld-servers.net (for .com), etc. –  derobert May 8 at 21:03
add comment

Your Answer

 
discard

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.