[Pool] Valid pool server checks

Hal Murray hmurray at megapathdsl.net
Wed Apr 1 10:47:34 UTC 2015

> There might also be a case where a pool server operator wants to say "Please
> tell my clients to go away" without taking their service offline or
> otherwise degrading its answers.

I think that's an interesting case.

> So I'm thinking that we might want to add an option to ntpd that would
> periodically send a message (do a DNS lookup?) to the pool DNS servers to
> ask "Is XXX still a recommended pool server?" and if the answer is "no" we'd
> drop that association and spin up a new one.

> Thoughts?

I think it's a good idea.  I'd be slightly surprised if there isn't already a 
bug to track that sort of suggestion.

I think it's unreasonable to expect that mechanism to catch LEAP problems.  
That would require too many DNS lookups.  (But maybe DNS is cheaper than I 

There is a variation of the problem for servers that are located via DNS 
lookup, that is you say:
  server ntp.example.com
Suppose the operator wants to move the server to a new IP Address.  With the 
current code, clients will keep trying to contact the server at the old 
address until they get rebooted or the server gets restarted.

There is another problem with the installed base that are using servers from 
the pool with the server command rather than the pool command.  A mechanism 
added to the pool command won't catch those clients.

I think that both would get fixed if ntpd occasionally did another DNS lookup 
for each server it is using and switched to a new address if the address it 
is using isn't one of the addresses returned.

It should probably drop the server if it can't get an answer after several 
tries.  I don't mean retransmission type tries.  I was thinking of do a 
confirming DNS lookup (and maybe a few retries) every day or so, and drop the 
server if it doesn't get an answer within a week.

The same logic might be good enough for the pool command.  It would probably 
hop around a lot, but it doesn't require any new DNS mechanism.

I think there is some mechanism in the current code that drops bad pool 
servers and tries to add new ones whenever it doesn't have enough.  Is that 
well documented?

How does this interact with laptops that hibernate, and maybe wake up in a 
new location and get a new local address via DHCP?

These are my opinions.  I hate spam.

More information about the pool mailing list