DNS Answer, Part I -- Illustration of an iterative query

[Benjamin Scott]

On Aug 17 at 12:38pm, Cole Tuininga wrote:
> We are in the process of moving servers and providers.  We have a new server 
> with the IPs 64.34.179.90 and 64.34.182.198. [...] it doesn't really make 
> sense that a ns1.code-energy.com could be the primary nameserver for 
> code-energy.com since it's required in order to resolve itself!

   Home come you didn't come to my DNS talk?  ;-)

   I'll take you through an iterative query.  You can't really understand DNS 
until you understand how this process works.

   Let's say a full-service resolver with an empty cache is asked to lookup the 
A record(s) associated with <www.code-energy.com.>.  The resolver starts by 
picking an arbitrary root server and asking it, "What are the A records for 
<www.code-energy.com.>?"

   The root server will respond with an answer: "I don't know.  Ask one of the 
authoritative name servers for the <com.> domain.  Here is a list of those 
servers, as NS records."  This is called a referral.  The resolver is being 
referred to some other nameservers, which should have better information.

   This also illustrates the major purpose of NS records: Delegation.  NS 
records delegate authority for a subdomain of the current zone to other 
nameservers.  In this case, the root servers delegate authority for the <com.> 
domain to the GTLD (Global Top-Level Domain) servers.  All of the GTLD servers 
have names like <a.gtld-servers.net.>.

   So the resolver next picks an arbitrary GTLD server.  Let's say it picks 
<c.gtld-servers.net.>.  In order to send a query to that nameserver, the 
resolver needs to know *its* IP address.  So it asks a root server, "What are 
the A records for <c.gtld-servers.net.>?"

   The root server again responds with: "I don't know.  Ask one of the 
authoritative name servers for the <net.> domain.  Here is a list of those 
servers, as NS records.  Since those NS records reference domains which are 
themselves in the <net> domain, I know you'll need to know their IP addresses, 
too.  Here they are, as A records."  Those A records are called "glue 
records".

   When one delegates to a nameserver which is within the domain one is 
querying for, one has to include glue records, too.  For example, if you 
delegate authority for <code-energy.com.> to <ns1.code-energy.com.>, you need 
to provide glue (A records) for <ns1.code-energy.com.> as well.  This solves 
the chicken-and-egg problem you noticed yourself.  Glue records are *not* 
authoritative.  They're there so you can find your way to the authoritative 
servers.

   Back to our query.  The resolver now has NS and A records for the <net.> and 
<com.> domains and so can ask a GTLD server: "What are the A records for 
<www.code-energy.com.>?"  The GTLD server, of course, responds with, "I don't 
know.  Ask one of the authoritative name servers for the <code-energy.com.> 
domain.  Here is a list of those servers, as NS records.  Since those NS 
records reference domains which are themselves in the <code-energy.com.> 
domain, I know you'll need to know their IP addresses, too.  Here they are, as 
A records."

   So now the resolver picks one of your two nameservers.  Let's say it picks 
<ns2.code-energy.com.>.  It has the A record for same, as glue.  It sends the 
query, "What are the A records for <www.code-energy.com.>?"  And <ns2> 
nameserver responds with, "The domain <www.code-energy.com> is an alias.  The 
canonical name is <code-energy.com.>."

   So now the resolver changes its whole question to, "What are the A records 
for <code-energy.com.>?" and starts over.  However, it already has the answers 
from above cached (thank $DEITY), so it can just go right to 
<ns2.code-energy.com.> again and ask the new question.

   The final answer from <ns2>: "<code-energy.com.> has an A record 
208.3.246.215".

   I went through things in very linear fashion in the above.  In actual 
practice, optimizations eliminate some of the iterations.  The root servers 
know they have delegations for both <com.> and <net.>, so the first query 
actually returns NS records for <com.> and glue A records for <net.> at once. 
Likewise, when <ns2.code-energy.com.> is asked about <www.code-energy.com.>, 
it returns both the CNAME record for <www> *and* the A record for 
<code-energy.com.> at once.

   You can test this process yourself.  Use "dig" and start with:

 	dig A www.code-energy.com. @198.41.0.4

That IP address is the IP address of <a.root-servers.net>.  Using just the 
results from dig, you should be able to ask, in turn, a GTLD server, and then 
one of your own servers.

   Go ahead.  Try it.  I'll wait.

/me plays around on Wikipedia for a bit

   Okay, now that you've done it manually, you should know that "dig" can do it 
for you.  Use the "+trace" switch:

 	dig A www.code-energy.com. @198.41.0.4 +trace

   *phew*  Now you know how DNS works.  This is all protocol stuff, and the 
politics of ICANN and VeriSlime and GoDaddy and such don't enter into it. 
For purposes of sanity, I'll cover the rest in a separate message.

-- 
Ben <dragonhawk at iname.com>