I want to get an understanding of how the DNS system works. How domain names actually get resolved and how admins setup a domain name so it is resolved correctly to a target machine.

The sources you find with Google are either very very technical and so hard to get a proper feel for the whole system or so dumbed down they are not very useful. Anyone have a good source that explains it as a whole but without be having to become an expert in the process of reading it?

  • 2
    "DNS" = "Domain Name System". "the DNS system" = "so very painful to hear people say" – jj33 May 3 '09 at 0:46

10 Answers 10


None of the answers given so far make these distinctions, but they're worth documenting:

The Different Types of DNS Server:

Authoritative Server

This is the server that holds the definitive (authoritative) information about a domain name. Authoritative answers from such a server have the AA bit set.

The answers from authoritative servers always contain the actual configured TTL from the zone file. i.e., if the TTL is set to 86400s, that's the value that'll be in the responses.

ISPs run authoritative servers to host the domains that they manage on behalf of their customers. The name servers run by the TLDs and ccTLDs are also authoritative servers, as are the root name servers.

Recursive Server

A recursive resolver only receives requests from stub resolvers. If the answer is in its cache it will return it immediately. If the answer is not in the cache it will iteratively ask the relevant authoritative servers for the answer, and then return it to the stub resolver.

Caching is a fundamental feature of recursive servers. The TTL received from the authoritative server continues to tick down, and when it reaches zero the entry is purged from the cache.

Similarly answers received from the recursive server show the decreasing value, not the original value from the zone. Per the example above, if a record was received with a TTL of 7200s exactly an hour ago, the answer from the recursive server will say 3600s.

ISPs run recursive resolvers for your PCs talk to, albeit most consumers actually rely on the DNS proxy in their home gateway, which forwards the query to the ISPs resolvers.

Stub Resolver

A stub resolver isn't a server in the normal sense, it's typically a library, and calls to gethostbyname() and related functions just invoke the code in that library.

The stub can't do anything except talk to a recursive resolver, relying on that recursive resolver to obtain all of its answers for it. All such upstream requests have the RD (Recursion Desired) bit set.

Some (but by no means all) stub resolvers have a cache.

Forwarding Server

A forwarding (or proxy) server doesn't (usually) cache. They're used to proxy packets between one network and another, typically sitting between a stub resolver and the recursive resolvers.


I'm having trouble finding a really good resource online. O'Reilly's cricket book ("DNS and BIND, 5th Edition") has good coverage, but not exactly freely available...

(TL;DR version: it's complicated, that's why sysadmins get all the good biscuits at morning tea time)

The answer to "how does a name get looked up" is basically that the entire system is like a big tree -- each part of the name you're trying to lookup is another level. At the top, the "root" servers know which DNS servers are responsible for each of the "top level" domains (.com, .net, .org, .us, .eu, .uk, .au, etc), and the servers responsible for each of those names knows which DNS servers are responsible for each of the domains under them (so the .com servers know which DNS servers are responsible for serverfault.com and stackoverflow.com, but they don't know who is responsible for hezmatt.org -- the .org nameservers know that).

When you want to know what a given name corresponds to, you start by asking the root servers. They'll "refer" you to the right servers for the "top level" name you want, and then the appropriate "top level" servers will point you where to go from there. Eventually (usually after just a couple of hops, but there's no reason why it couldn't be more) you'll get pointed to a server that knows the actual answer to the question you're asking, and you'll get your answer.

If you want to watch this process at work, you can use a tool like http://squish.net/dnscheck/ to look up a name and see all the queries that can get done.

As far as how an admin sets up a DNS server and integrates it into the whole thing, that kind of falls out of the above. Once you've setup a DNS server to answer for a given domain, you need to ask the DNS servers for the level above you to "delegate" that domain name to your servers. In practice, this done by your domain registrar on your behalf, when you tell them what DNS servers to use for a domain that you "own".

  • @womble - the root name servers contain "delegations", but the resulting answers are called "referrals". – Alnitak May 2 '09 at 7:53
  • @Alnitak: Good point, answer updated. – womble May 2 '09 at 8:57

You also need to know about DNS spoofablity the exploit that happened in the middle of last year.


i'm sure you'll get plenty of interesting answers that go beyond wikipedia and earlier questions. i hope you'll learn that dns can be used for:

on the funny side - if you have some time to spend - take a look at one of presentations of Dan Kaminsky about interesting ways of [ab]using dns. start with black ops of tcp/ip on chaos communication congress #22. highly entertaining. than take a look at his newer presentations.


Okay, second shot at an answer. Hopefully a better one!

When a user asks for the address of, say, serverfault.com, the DNS client software starts out by looking at its list of root servers. This list is built into every DNS resolving client[1]. The root servers are a special kind of DNS server. They simply tell the DNS server which servers to then ask, for the top-level domain (in this case, .com) being sought after.

This process of telling the DNS client software which content server to ask next is called delegation. So, in this case, the root servers delegate the request to serverfault.com to a.gtld-servers.net, b.gtld-servers.net, etc. In this case, gTLD stands for "global top-level domain", referring to .com, .net, etc. (as opposed to country-code top-level domains, ccTLD).

So, the DNS client then asks one of these gTLD servers (which are, like the root servers, also content DNS servers) for the address of serverfault.com. The server comes back, delegating the request to ns21.domaincontrol.com and ns22.domaincontrol.com. The DNS client then continue by asking one of these servers.

When the DNS client asks ns21.domaincontrol.com or ns22.domaincontrol.com (which are also content DNS servers), they respond with serverfault.com's IP address, Thus, we're done.

There are some points to take into account here. Each step of the lookup request to a DNS server has one of three possible results:

  1. The requested data (in this case, the address of serverfault.com)
  2. A delegation to another DNS server (if this doesn't ultimately result in the requested data, then this situation is called a lame delegation)
  3. An error (such as the a nonexistent domain name)

Now, when you're trying to run your own DNS server, you must have some way for people to know to talk to it. You do this by registering your domain with a registrar of the top-level domain you're interested in, along with information about the address of your DNS server. You can find a list of registrars from ICANN.

Hope this helps!

[1] This is a huge simplification, because I don't want to touch on caching servers or anything. DNS experts, please forgive. :-)

  • I want to acknowledge womble's excellent feedback in improving this; obviously any remaining bugs are mine to keep. :-) If you like this answer, you're encouraged to upvote womble's great answer too! – Chris Jester-Young May 2 '09 at 4:14
  • 1
    -1 for implying that the DNS clients have a list of root servers. That job remains with DNS servers. A client will have the IP address (not name) of one or more servers, typically from DHCP, but can be static. The client asks the server(s) for the answer. The server(s) the start the walk of their parent(s) up to root and then down to the athoritative server. – WaldenL May 2 '09 at 4:24
  • DNS clients in this case referred to recursive-resolving DNS server, such as the ones at your ISP. I wanted to not muddle the point with "content" DNS servers, though. Hence my footnote about huge simplification. – Chris Jester-Young May 2 '09 at 4:25
  • All the "DNS servers" in my post, i.e., content DNS servers, are authoritive only (i.e., strictly non-recursive). – Chris Jester-Young May 2 '09 at 4:27
  • And if you talk about how there can be authoritative servers that can also be recursive, I will send Freddie Krueger your way. :-P – Chris Jester-Young May 2 '09 at 4:30

Lots of information there, but consider how it starts.

First of all, there's a (usually small) DNS server right there in your computer. And maybe it already looked that address up recently. So if it's in a cache, you're done. If not, we dig a little.

There's a "hosts" file on your computer. You can put entries in there; for instance, you can put names of things on your LAN that translate to their IP address. The file can be empty, too.

So failing all the easy answers, this DNS service does the next easy thing. I looks to see who your ISP said to ask (when you connected you got this info), and so it asks that server.

That server may or may not know the answer, but think "recursion" here. This process will repeat as necessary, all the way back to the "root" server (called '.' or "dot"). Eventually the answer comes back down the chain, with each DNS in the chain pretending that it knew the answer all along!

Digest this picture for awhile, then go back and read the detailed answers here.

  • 1. the hosts file isn't part of "DNS" proper. 2. the stub resolver in your PC only talks to your ISP's DNS, not the whole world. 3. when the ISP doesn't know the answer it starts at the root and works down, not the other way around. – Alnitak Jul 25 '09 at 7:23
  • Maybe I wasn't clear on (2), that as far as the stub resolver knows, the ISP knew the answer--regardless of how the ISP really got it. I question point (3); can we verify (cite?) that somehow? – gbarry Jul 26 '09 at 18:29
  • @gbarry - sure - read RFC1034 and RFC1035. – Alnitak Nov 24 '09 at 17:53

Despite it's name, DNS for Rocket Scientists might be what you're looking for? The DNS overview section covers key concepts like domains, zones, record types and delegation. If you're then looking to implement DNS with BIND, it goes on to have more detail about BIND itself.

That said, as has been mentioned previously, DNS & BIND really is the bible when it comes to DNS; if you're going to be administering your own DNS servers, it's probably worth having your own copy.


Old, but still helpful LJ article — "An Introduction to DNS and DNS Tools"


In addition to pQd or if you've got a longer commute, listen to the dns-specific episodes of SecurityNow. On first glance episodes 163, 157 and 155, though there have been some additional episodes (after these) with listener Q&A.


Illustrated DNS tutorial:

TMBG37 Goes to the Market

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