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 doesn't. 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 is rebooted.
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... Rob _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
