David Woolley wrote: > In article <[EMAIL PROTECTED]>, > Jan Ceuleers <[EMAIL PROTECTED]> wrote: > >> - the ntpd development team don't think it is a good idea to re-resolve >> before _every_ poll/query, but do think it is a good idea to do this > > What may not have been clearly pointed out is that re-resolving is a > very expensive operation for ntpd, as the standard resolver libraries > are blocking, so, to avoid blocking ntpd itself, it has to spawn a > separate process to do the resolution. (This actually generates a > relatively frequently asked question because people see two processes > when it is starting and thing something has gone wrong.) > >> I was wondering what the impact of such re-resolving behaviour would be >> on the pool. Both cases are relevant, I think: best-practice recommended > > It would be a serious problem for clients of the pool as it would cause > them to hop servers, thus invalidating the statistics previously > accumulated, every time that TTL ran out. pool names are expected *not* > to resolve to the same machine on each request. >
There is definitely a problem with the DNS lookup, and with the issue of "load balancing" and statistics management, what about servers that are sitting on dynamic IP addresses? A server who's IP address has changed isn't necessarily a new server (though I believe that the statistics would quickly show if it was) and there is a way to track a dynamic IP address without losing all statistics. One way of satisfying both needs is to somewhat ignore the TTL and do a DNS lookup after the TTL has expired but only when an attempt to contact the IP fails. Doing this would allow the same server to be contacted even though it's IP address has changed but without the expense of constant DNS lookups. At worst, a TTL's worth of connection failures would occur before switching over to the new address. This would especially be useful for the pools as illustrated by my recent experience. I have a server sitting in my dining room that hosts my domain. I have a static IP address and recently added my server to the pool. The FQDN I registered is ntp.otherother.com. All was going well until my wireless router died a messy and horrible death. On replacement, I was assigned a new address (my ISP assigns "static" addresses via DHCP keyed off the MAC address of the connected device). Assuming that this would be a new static address, I changed my DNS entries to reflect this new address. pool.ntp.org was still attempting to contact the old address (which quickly dropped to a rating of -100) so, sigh, I created a new server for the new address and it quickly came back up to +5. Meanwhile, my provider's systems recognized that I was not changing my MAC address anymore and re-assigned my original IP back to me. Off to my DNS provider to change my DNS entries... and pool.ntp.org was now seeing the original server coming back up, and the "new" server was dead. So I cancelled the deletion I had scheduled for the original server and scheduled the deletion of the "new" server. All of this would have been unnecessary if pool.ntp.org's checking resolved the domain name for it's checks (or at least resolved it after a failed connection). Now imagine that I was using a Dynamic DNS service (which my router will do automatically, as will many others) and wanted to host an NTP server. It would be impossible to keep a server up above +5 long enough to be useful, not to mention the fact that ntpd's around the net would keep seeing me disappear. Timing statistics shouldn't be an issue for this scenario since the server isn't moving, it's not changing its routing, but it is being assigned a different IP address. Resolving the domain name when necessary would open up the possibility of a whole new set of servers being available that would as currently set up cannot reasonably join the pools. Cheers, Bruce. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
