[time] What is happening here?
Wed Aug 8 07:59:08 UTC 2007
Rui Ferreira wrote:
> I actually tested the cache's round-robin on several public dns servers including of my ISP, and all resulted in *not* performing round-robin on cached queries of pool.ntp.org and 0.pool.ntp.org.
> I have made same test with a local windows 2000 dns server and same result.
> Then I have made same test again but on a BIND server on linux and indeed it *does* make round-robin on cached queries of 0.pool.ntp.org but for some reason I cant understand it doesnt respond to queries of pool.ntp.org, instead it responds with the list of authoritative name servers.
We use DNS rotation for load balancing on our company internal network,
and what I found is that BIND does rotation by default, and Windows 2000
I think it could be enabled by registry entry. However, there also is a
default caching time in the Windows 2000 DNS resolver that is very long.
Our DNS is BIND, but the result of the above is that any Windows 2000
client that resolves the multi-address name gets a different rotated
reply, takes one address out of it, and caches that. The local
application returns the same address for every lookup essentially a
whole working day.
So, while the load of several workstations is distributed over the
servers nicely, a single workstation remains on the same server until it
I fixed that by setting the caching time to a lower value using a
registry change. However, I could understand that a default
installation at an ISP would be returning the same address for a long time.
However, I don't know if this issue affects only local caching in the
DNS client, or would also occur when a Windows system is used as a DNS
cache to be used as a recursive DNS server by ISP clients.
Maybe someone with more Windows knowledge can answer that.
It is unfortunate that we have such a monoculture in OS land, where
broken or bad-default-setting network protocol implementation affects
the whole network with no chance of resolution.
For example, a while ago I researched why so many systems re-try a TCP
connection (SYN) on which they receive an RST. Originally RST on a SYN
just was meant to be a final response that the server is not prepared to
accept a connection on that port, and there was no reason to retry.
Nobody did. But in early Windows servers, an RST was also sent when
the server's incoming connection queue was overflowing and Windows
clients just retried to see if they could get in later. And now MS
simply doesn't remove that anymore, resulting in lots of useless traffic
from zombies trying to connect nonexisting services...
More information about the pool