Mailing List SIMS@mail.stalker.com Message #9988
From: The Count of CipherSpace <CountZeroI@CipherSpace.org.in>
Subject: Re: Transfer from one SIMS server to another [OT]
Date: Sat, 5 Jan 2002 13:31:53 -0500
To: SIMS Discussions <SIMS@mail.stalker.com>
X-Mailer: Claris Emailer 2.0v3, January 22, 1998
Larry Stone at 2002-01-05 08:02 from lstone19@stonejongleux.com wrote:

>So the only way a server could be "notoriously slow about updating their DNS
>servers" is if they're not honoring the TTL and caching it longer than that
>which would make their DNS server non-compliant with the appropriate RFCs.

We recently had a problem, which made us look into this issue.  What we
found is, there are a number of DNS servers that do NOT honour the TTL
from the authoritative server.  This used to be common in the "old" days
of expensive and narrow bandwidth.  However, it seems that either people
are not updating their configs or are still treating bandwidth as a
precious resource.  The latter seems to be the case, as most of these
"non-honouring" servers are in countries with "insufficient" bandwidth.  
One notable exception, being AOL, who seems to also ignore the TTL.  Oh,
and FWIIW, the majority of the ones that use their own TTL, cache the
info for 2 days.

>However, when you cut TTLs, make sure you also cut the refresh interval of
>any secondary DNS servers for your zone or can arrange to force a reload of
>your secondaries. It does no good to cut TTL to 5 minutes if the secondary
>is only checking for zone changes every 3 hours as your secondaries will
>still be serving the old data for up to 3 hours (or longer if the primary
>server is unreachable) ("refresh" defines the interval the secondary checks
>with the primary for zone changes, if it can't reach the primary, it then
>rechecks in "retry" seconds but will continue to serve the zone data it has
>until the primary cannot be reached for "expire" seconds - typical values
>are 3 hours for refresh, 1 hour for retry, and 1 week for expire).

Modern DNS servers have the capability of sending notifications to
secondaries when changes are made.  Assuming that the secondary also
supports this, the RFC specifies that the secondary on receiving the
notification, has to immediately do a refresh.
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster