[Pool] Valid pool server checks

Harlan Stenn stenn at ntp.org
Wed Apr 1 20:50:12 UTC 2015

Hal Murray writes:
>> 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.

Me too,  but I didn't find one.

> 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 
> think.)
> 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.

This is a bigger-scope issue with TTLs.  I'm bringing that up separately
as it's not pool-specific,

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

Yes, that's true.  And we have other work in-progress to detect and
address this issue.

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

That's the bigger-scope TTL issue.  But that will not directly address
the issue of "is the pool server I am currently using still listed as
being "valid".

The related issue for 'server' entries has different constraints.

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

I'm not sure what you mean here - for the pool directive a mechanism to
do this already happens.  For servers, it does not, but that's a
"feature" of the server directive.

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

There is no useful DNS mechanism to get the TTL.

It's not clear that "use the TTL to decide when to refresh the DNS
cache" is the same as "look up this name again after the TTL has

They are similar, and this is a case where we need to look at the
consequences of the choices - this is not an "intellectual exercise".

> 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?

It's documented.  Well enough for some/most, and if all else fails,
support.ntp.org is a community-maintained service and any registered
user can add more content. If folks want better "official" docs they can
open bug reports, send patches, and/or send $ so we can pay
documentation people to work on things.

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

Not sure directly, but a) that's a bigger scope issue, and b) if we can
look up the TTL for pool servers that information will certianly be


More information about the pool mailing list