[ntp:questions] Best practice: re-resolve server IP address before each poll/query
drllama at otherother.com
Fri Jun 22 16:52:37 UTC 2007
David Woolley wrote:
> In article <46790346$0$13852$ba620e4c at news.skynet.be>,
> Jan Ceuleers <janspam.ceuleers at skynet.be> 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
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
More information about the questions