[email protected] said: >> Is there a way to do that? I assume it would use DNS. > There isn't. I could setup a "DNSBL-style" zone to check "is this server > still ok to use", but I don't think that's really what we need.
I was thinking of something like if you got 1.2.3.4 from de.pool.ntp.org you could ask if 4.3.2.1.de.pool.ntp.org existed. (Maybe 1-2-3-4.de.pool.ntp.org?) Normally it would return its own IP Address. If it got an error of NXDOMAIN you knew it wasn't in the pool any more. I don't know enough about DNS to be sure my suggestions would work right and/or would be reasonable to implement. Does any of the pool stuff use CNAMEs? [email protected] said: > For example then a server operator might now be asking for less queries per > second; or maybe the server used to be in the NL zone, but now is in the DE > zone so a server in the Netherlands shouldn't get it anymore, but a server > in Germany should still. I think there are two ideas tangled up in there. One is reducing the load on a server. I've been assuming you could do that without any new mechanism by just reducing the amount of time that a server shows up as an answer to DNS queries. I'm assuming that users get rebooted or whatever occasionally, and that forgets the servers they are using, and that it happens often enough to reduce the load quickly enough. The other idea is removing a system from the pool, or a sub-pool. If we could do that, moving from one zone to another is easy: remove from one, add to another. So all we need is a good way for ntpd to detect that a system has been removed from the pool where ntpd found it. So far, the best (and current) mechanism is for the system to stop responding. There is still the problem of people getting an IP Address from the pool using dig or such and then manually wiring it into a config file. -- These are my opinions. I hate spam. _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
