On Mon, Sep 01, 2003 at 05:51:19PM +0000, Shane Hollis wrote:
> I think we are beginning to go around in circles here ....
Probably... :)
> When the address is found, the
> four levels of DNS server that it has passed through will cache the result.
Important to note here, that they wont actually cache anything, since
they're authoritative for what they were asked for.
e.g., the root server was asked 'where's .nz' ? it answers.
the .nz server was asked 'where's .geek.nz' ? it answers.
etc. The *requesting* server, on the other hand, will cache these results,
with the TTL's given, so that it wont ask a root server again for .nz, until
it expires.. which is.. (goes to look...)
[EMAIL PROTECTED]:~> host -vvv -t NS nz
;; QUESTION SECTION:
;nz. IN NS
;; ANSWER SECTION:
nz. 86378 IN NS ns5.dns.net.nz.
...
looks suspiciously like 86400 secs, or 1 day.
etc etc.
> We are also agreed you do not always go to the source to find an address,
> rather you can get it from an 'upstream' trusted DNs servers cache.
Upstream from you. there is no law stating your DNS server must be a client
of another. you can set up your DNS server to not 'forward' unknown's, but
to recursively find them out itself, which in this case, means you *will*
get the result from the source. (and then cache it)
> Having all agreed on that ( I hope) that brings us back to the thing someone
> originally picked me up on.... if it is faster to disperse IP changes from a
> backbone or the small pimple on the butt of the internet DNS server.
Ok, you're starting to make sense... and yes, this was the point I was
tripping you on.. (well, trying.)
> It is still my contention that to make an internet wide change of IP address,
> one that will eventually affect all caches and all DNS's then it is better to
> do it from a central location with lots of traffic ( especially DNS traffic)
> if you want to get the fastest possible way of spreading the changes. This
> however does not apply to new addresses. It also doesn't mean a change will
> not be spread from the pimple of the internet, just that it will take longer.
> This length of time would be especially important to someone using one of
> those dynamic DNs lookups such as zoneedit. If your ip chages, you want that
> change spread as fast as possible so there is as little ooops where is that
> machine now as possible.
*NO*. Time to propogate is IRRELEVANT when you're talking about the server,
or location.
Propogation time is ONLY relative to the TTL for the record. doesnt matter
if it's a pimple, or a huge whopping great puss ball. if the pimple is
authoritative for a domain, it will still take the same amount of time for
the change to 'propogate' as it would from the puss ball. (as long as the
TTL's are the same).
Now.. here's a point for you: 'propogation' is a really bad word to use for
this purpose, as what is really meant, is *expiry* of all old records cached
aroung the net. Nothing actually get's propogated anywhere, except to the
secondary servers for the domain, via AXFR :)
> does this sum it all up?
Sort of...
Mike.
--
Mike Beattie <[EMAIL PROTECTED]> ZL4TXK, IRLP Node 6184
The first 90% of the code in a project takes 90% of the time.
The next 10% of the code will take another 90% of the time.
-- J. S. Labuschagne
