[Gllug] DNS

[Dave Cridland]

On Tue, 2001-11-13 at 14:11, Paul Brazier wrote:
> Does the number of nameservers queried along the chain match the number
> of dots in the domain name (maybe plus or minus one or something)
> (assuming it doesn't used a cached result)?

Umm... Yes, usually.

Firstly, a domain name technically has an extra dot on the end.

Secondly, records within a zone may have dots within them.

Thirdly, if you're not after an authoritative answer, you might end up
using the glue records if you're after something that has one.

Fourthly, your server will be after the NS records as well as the actual
record it's after.

So for finding the IP address for www.domain.tld non-authoritively, but
without cached data present:

1) "IN NS ." -> From hints file - really these are local glue records,
of a sort.
2) "IN NS tld." -> From (possibly random) root server. Bind can figure
out "good" root servers, and can also be swayed towards using "closer"
ones.
3) "IN NS domain.tld." -> From (possibly random) gtld server.
4) "IN A domain.tld." -> From (possibly random) domain.tld nameserver.

The last will either give you an A record, if there is one, or both a
CNAME and an A, if the server can provide both, or just a CNAME, if the
actual A record for that CNAME is outside the scope of that nameserver.

Generally, CNAMEs are used within a single server, for instance by ISPs
doing stuff like:

www.domain.tld. IN CNAME virtual-www-server.isp.net.

Since the ISP probably holds both zones on the same server, then your
rule of thumb will hold - three dots, three external queries, albeit the
last one may give two records.

However, you may need to do the whole thing again with the CNAME you got
back, although some records would probably be cached.

If you were insisting on authoritative records, you'd forget the cache,
and possibly also verify the glue records by asking the nameserver you
got from the level above what nameservers it thinks you should use. Not
sure though.

> Surely the ISPs' nameservers must periodically query the root servers
> even for sites like google just to check the IP address hasn't changed
> since the last query. But they also cache the results for some pre-set
> duration to avoid a lookup each time. Is this right?

The duration is set by the "Time To Live", or "TTL" of each and every
response from a nameserver. So every single query above will be told how
long (in seconds) to cache the response for.

Note that for www.google.com address checking, a nameserver will
probably have the response for "IN NS google.com." cached considerably
longer than the one for "IN A www.google.com.", since it's less likely
to change.

A word on DNS propogation of changes:

This has nowt directly to do with the root servers, and everything to do
with the TTLs of the individual records.

Let's say that we change the A record for "IN A www.domain.tld.":

Nameservers that haven't ever been asked for "IN A www.domain.tld."
should pick this up immediately.

Nameservers that have will have cached the record, and will still return
the old one for some time. The worst case is that the nameserver was
queried immediately before the change, and will take the total TTL to
expire the record and get a new one.

Let's suppose that we change nameservers, and our new nameserver, at our
new ISP, has a different record for "IN A www.domain.tld.".

The worst case now becomes the greater of the TTL of "IN A
www.domain.tld." and "IN NS domain.tld.". Note that the "IN NS
domain.tld." in the zone "domain.tld." is probably not the one we're
concerned with, but instead, the "IN NS domain.tld." in the "tld." zone,
controlled by the registrars, and changing by your "domain transfer".

These worst case times only start ticking from when all relevant servers
are handing out the right records - this may take a few minutes, but it
shouldn't be more than that.

The solution to this is:

1) You want to change the A record alone.
a) Work out when you want to do it, well in advance.
b) At approx 2*TTL at the latest, change the TTL right down for that
record. 5 minutes is fine. Check this has actually happened.
c) When you change the record, change the TTL back up to normal.

2) You want to change the A record, and the nameservers.
a) Work out when you want to do this.
b) Again, drop TTL times for the records that are changing.
c) Get new ISP running DNS with low TTL and old record for A.
d) This is the tricky bit. When you change your nameservers, make sure
that the old ISP changes their zonefiles to the new record. They should
leave the TTL very low. New ISP should switch to the new record, normal
TTL.
e) After the TTL of the nameserver record in the GTLD servers - or more
helpfully 2*TTL to be sure, the old ISP can drop the zone entirely.

Both these methods will basically minimise propogation times (to about 5
minutes), or else hide the effects.

However, if you find yourself in a position where "old ISP" in (2)
atually does this for you, then I'd advise not changing ISP if you can,
because they're obviously pretty good. If they actually suggest it, then
certainly don't, as ISPs which are helpful even when you're leaving them
are gold-dust. (Actually, ISPs which are helpful after you've signed the
contract are getting pretty rare these days.)

Apologies for the uberwaffle.

Dave.

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug