update caching nameserver immediately

[Will Yardley]

In article <blufbi$1lpc$1 at sf1.isc.org>, Simon Waters wrote:
[ Sorry if the threading is messed up - my news server isn't allowing posts
at the moment, so I'm sending this via mail ]

>> and without setting ridiculously low TTLs?
 
> I think a TTL that matches the length of time a record is going to be
> valid for isn't ridiculously low

Well part of the issue is that while changes aren't too frequent, when
they happen it is important that they're updated quickly.

> Remember individual client operating systems probably have some DNS
> caching ability these days, that will respect TTL.

In this case, however, the client hosts are all UNIX and Linux hosts,
with no internal caching. We're not concerned about external clients
resolving this stuff quickly; that's already taken care of (as we leave
any out of date public-facing IPs working for well past the TTL, for a
designated "expiration" period).
 
> Come on what are you moving around behind the scenes? I assume it is
> only one or two records?

Well a couple of examples....

1) We occasionally move customer database instances around. We use DNS
records to point foo.example.com to the correct database machine /
instance. Obviously it's important that once a database has been moved,
the customer's machine is able to connect.

2) When a mail service is moved from one mail server to a new one, and
the old mail server (temporarily) is configured to relay (but not
accept) for a domain, the old mail server will bounce messages if it
sees the old MX record (pointing back to itself) when it's not
configured to handle mail for the domain locally.

These things don't happen too frequently, but it does seem a bit
overkill to flush the entire cache... and performing any sort of action
will require changes to our code. Seems like the ideal system would be
something that allowed NOTIFY requests from a particular host to flush
an individual zone from the cache... sounds like that won't really be
easy to accomplish, though. 

> If it isn't a routine thing, then caches can just be restarted, if it is
> routine a low TTL for those records seems sensible, rather than hacking
> some out off band fudge.

Yeah - a low TTL may end up being our best bet, at least for #1... for
#2 above, a transport map (in Postfix) should solve the problem.

-- 
No copies, please.
To reply privately, simply reply; don't remove anything.