[ntp:questions] Bad NTP servers jeopardizing the pool.ntp.org initiative

Danny Mayer mayer at ntp.isc.org
Mon Mar 26 07:13:46 UTC 2007


Hal Murray wrote:
>> Yes, it could be that. The idea was laid out in previous messages. I
>> guess I need to document this in the twiki.
> 
> It's probably worth making a list of the problems that you want to
> solve.  The ones I can think of:
>   server xxx matching restrict xxx
>   server (1 IP address) gets moved to a new IP address
>     or gets turned off
>   get several working servers from pool
>   restrict for pool
>   server leaves pool
> 

You apparently haven't been reading my messages! :) They may have been
in hackers.

> Possible extensions:
>   Pick good/near servers from pool offerings.
> 

That's hard to even define.

> 
>> Basically you move on to the next address if the first one does not
>> respond (for some number of queries). When it runs out it requeries.
> 
> We have to make sure not to hammer the DNS.
> 

How would you do that if you don't requery until you run out?

> Is there any point in retrying a DNS lookup before the TTL expires?
> 
The first problem is knowing what the TTL is. getaddrinfo() doesn't tell
you. Assuming you are using a DNS server (instead of a hosts file for
example), then I'd have to resort to other tactics to get the TTL.
That's not straightforward. In any case it would do you no good since
you have no idea when that TTL started since you are disciplining the
clock and you may have gotten the TTL early on before you reset the
clock, perhaps radically. A simpler model, which is what I had proposed
is to use a count of failed packet responses. You then put a maximum
limit on failed responses before you move on. The count method has great
advantages. When you run out of addresses you requery.

Danny



More information about the questions mailing list