short ttl and servermmirroring

[Jim Reid]

>>>>> "john" == hilgart  <hilgart at my-deja.com> writes:

    john> At the suggestion of Jim Reid, I looked at the code and
    john> found that BIND does indeed intentionally put a delay in
    john> sending out NOTIFY from anywhere between 5 seconds to 15
    john> minutes, using a random value.  The delay is roughly
    john> proportional to the number of zones you have.

Well I'm pleased somebody thinks I might be telling the truth.... :-)

    john> For us this is unfortunate as this is an ideal
    john> high-availability mechanism.  It looks simple enough to
    john> re-write the code, and I may do so.  Once we sign up for a
    john> support contract with the ISC, I will suggest that some more
    john> switches be offered around this cool NOTIFY feature.

Taking out a support contract is a Good Thing. And so is asking for
this feature, though some might gripe at adding yet more syntax to
named.conf. Contributing code that implemented your feature would be
even better. Just hacking the code is unwise because of the open-ended
commitment it implies for local software maintenance. Just how many
versions of BIND do you want to have to apply this local hack?

If you do make this change, please do it in such a way that the name
server and net won't get hammered when thousands of zones get loaded
at once. The random delay was added for a good reason and some sites
really need that functionality.

    john> I'm surprised there hasn't been more request for this.  If
    john> you want to switch the IP of your Web server in seconds (or
    john> at least within minutes), you need 1) a short TTL on its
    john> record and 2) all authoritative servers to have that new IP
    john> ASAP .?  This thread is focussed on 2) .

But (1) is also important, probably more important than (2). Fast
propagation of new zone data doesn't help if the rest of the world's
name servers have cached the old value of the resource record. It's
even worse if that record has a TTL of days. When I've had to change
important resource records - like a web server - I usually drop the
record's TTL to 5 minutes at least 1 zone-refresh-interval or default
TTL (whatever is greater) before the actual change is made. That's
usually "good enough" to close the window when stale data is cached by
other name servers. 5 minutes is normally long enough for the NOTIFY
mechanism to kick in and propagate the new zone data to the slave
servers.

    john> Isn't that how Distribued Director and Resonate Global
    john> Dispatch work?

Most people use stuff like Distributed Director for things like load
balancing or automatically switching traffic to another box when one
dies. Or pointing clients to the "nearest" server.