update caching nameserver immediately

[Kevin Darcy]

Will Yardley wrote:

>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.
>
What some folks do is reduce the TTL gradually prior to a move, and then 
bump it up to normal operating level once the move is done. At least 
then, you're only beating up caches temporarily instead of all of the time.

That requires a high degree of co-ordination, though, and to be 
perfectly honest, I can probably count on the fingers of one hand the 
number of times someone around here (including me) has had the presence 
of mind to actually implement this prior to a move...

- Kevin