Fraser Campbell wrote:
No. It doesn't. Most people setting up round-robin DNS type setups for redundancy with scripts to change things for failover get bit by these things:On Thursday 07 October 2004 13:20, August MacBeth wrote:cache. Surprisingly, Mac OSX (unix based) cache's DNS as well, which bum's me out.That is surprising. Are you saying that Mac OSX caches the DNS permanently and/or for longer than the TTL supplied by Bind?
- They don't REALLY understand TTL- They don't understand that there might be multiple DNS servers between their top-level and the machine they're servicing (3X and 4X TTL) - They don't understand negative caching and how important it is to ALWAYS answer DNS queries. - They don't understand that some implementations of resolvers will refuse to update quickly if the TTL is set very very low -- and will cache for longer than the TTL time. (But OSX doesn't do this, as far as I can tell.) - They don't understand that it can take a very long time to fail-over when you factor in all of the above.
DNS with low TTL times and the ability to be changed on the fly is really good for a secondary physical SITE, but in terms of server failover, virtual IP type solutions work much much better. Some really nifty solutions I've seen are the hardware load-balancers that publish all the SITES as round-robin'ed DNS entries and change on-the-fly to remove entries when a site isn't responding, while the load-balancer is actually the front-man for multiple servers at that location, with a single virtual IP on the front-side. Decent amount of redundancy in that setup, and still relatively cheap -- you don't HAVE to do that with a hardware load balancer, you can do that with IP takeover services and two single boxes that can individually handle all the load by themselves. At the point a single box can't do the job, it's a good idea to weigh the cost of hardware against having one box always doing "nothing"... although you could use it for cronjobs and things that would bog down the other box... DB cleanup, etc... Lots of options, always.
-- Nate Duehr, nate@natetech.com