[oclug] newbie more dns questions

[Adrian Irving-Beer]

On Fri, Mar 04, 2005 at 03:10:11PM +0000, ed stuckems wrote:

> >My knowledge starts to break down a little around here, but as far
> >as I know, the  '.' zone refers to the top level.
>
> I don't know why the documentation doesn't explain this part well.
> The how-to doesn't seem to deal with the case of an isolated network
> very well. It basically says "for zone '.', do this" without any
> explanation of the how and why.

If they told people how and why, they might get ideas on how to try to
use the root nameservers 'better'.  They don't want that.  The root
nameservers are already plagued with many thousands of needless
requests per day from misconfigured nameservers around the world.
Better to just follow a set of instructions.

If you're setting up your own DNS root, though, I think it's assumed
you know enough about DNS to know what to do, or (like me) you're
willing to just plug away until it seems to work. ;)

> >Since a nameserver needs to know who to contact for any arbitrary
> >domain, '.' is just a list of the root servers on the Internet (who
> >delegate everything to everyone else).
>
> This I understand - basically, it says "when all else fails, try
> these guys".

And then it caches that, so that it knows for a very long time (two
days) that .com is handled by a particular nameserver.  A properly
configured nameserver should very rarely actually talk to the root
servers, because it's cached all the delegations.

Try downloading the actual root zone used on the Internet today, at
ftp://ftp.rs.internic.net/domain/root.zone.gz ... I found it to be
quite informative.

> I concerned about this because I believe that when someone on the
> local, isolated network attempt to resolve an unknown name there
> will be an extremely long delay as the name server attempts to reach
> servers that are non-existant.  I'm hoping to avoid the long delays.

I've tested this.  If you declare yourself authoritative for the root
domain (.), you'll avoid that.

The simplest zone should contain an SOA, an NS pointing to a name (can
be bogus, e.g. I used 'kitson.bogus.net.'), and an A record mapping
that name to the IP of the local server.

I did this, and I found that requesting anything the server didn't
know about would result in NXDOMAIN, domain not found.  (If you leave
out the NS and A records, you get SERVFAIL instead.)


If that server is authoritative for all domains in your network, you
can leave it at this.  Otherwise, for every domain you want to
delegate, e.g. delegating '.net' to 11.22.33.44, you'd do

        net. NS nameserver.somedomain.com.
	nameserver.somedomain.com. A 11.22.33.44

with nameserver.somedomain.com being any name you like.  It could be
inside .net, or it might not be (as in my example).

Don't forget to include the A record, or to be authoritative for (in
this case) 'somedomain.com'.  Otherwise you won't know the IP address
you're delegating to.

> >I suspect this would result in the server getting mad at you.
> >"Authoritative for '.'?  I don't know anything about that."
>
> I don't understand why.  There would be a machine designated as
> authoritative for '.' - localhost (or its equivalent name on the
> network).

No, you're not designating it as authoritative.  You're designating it
as the next place to try for the authoritative answer.

If you say 'get your root info from localhost', and then either
queries localhost or recognises that localhost is itself, your DNS
lookups will hang.  I've tested this as well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://tux.oclug.on.ca/pipermail/oclug/attachments/20050304/3a182686/attachment.bin