Re: a question on heirarchy

From: Oskar Pearson <oskar@dont-contact.us>
Date: Thu, 17 Apr 1997 14:11:46 +0200

Graham Toal writes:
>

> If you've done it in the DNS, the behaviour is undefined and depends
> on the behaviour and timeout periods of the clients DNS cache. There's
> a good chance many clients will pick one server and stick with it.
Not really.

Bind these days will take the two entries and randomize the results it
returns (if you set this option). This means that even if the machine ALWAYS
uses the first entry, it will still pick a random host.

> If you're really unlucky, all your clients could pick the same
> server. I'm not sure how well the PC IP stacks cope with multi-homed
> hosts. I've noticed I can change the DNS address of a host, and
> Windows machines don't pick up the new one at all until the PC is
> rebooted!
Linux doesn't do this. There is some broken client software (netscape
included) that does a lookup for an address ONCE and never again, and
seems to store the result in some internal cache instead of calling
"gethostbyname". Thus if you set the DNS TTL to 10 minutes, thinking that if
one of your caches freaks out you can just remove the entry and leave
the caches up for 10 minutes and then no new connections will happen on
the old cache, you are wrong... until they re-start netscape things will be
broken.

About reliability: The correct behavior for client software is to try and
connect to each of the hosts in succession in case of failure.
So if it tries host1 and there is a problem connect to host2 and so on.
Note that when I last checked this didn't happen in squid (I think this is
why www.microsoft.com is so yicky - they rely on this behavior to get their
web pages down at all)

Major problem is sysadmins finding out the IP addresses and telling people
"it's more reliable to use that, since if our DNS breaks you can still
web-surf". Kills load balancing terribly.

Oskar

Oskar
Received on Thu Apr 17 1997 - 05:30:25 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:35:00 MST