[ntp:questions] Best practice: re-resolve server IP address before each poll/query

Bruce Thompson 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 
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.




More information about the questions mailing list