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

Danny Mayer mayer at ntp.isc.org
Sun Apr 1 13:06:41 UTC 2007


Jan Ceuleers wrote:
> Danny Mayer wrote:
>> Jan Ceuleers wrote:
>>> (I suggested that pool members with non-static IP addresses could be 
>>> accommodated by the pool).
>> Well you shouldn't have. It just won't work for any useful time period.
> 
> Well excuse me for thinking out loud...

Sorry if it sounds like I'm trying to prevent you from presenting ideas,
I'm not.
> 
> As you might have seen elsewhere I do agree that this is only a good 
> idea under well defined circumstances, and I would now add that it is 
> difficult to ascertain up-front whether these conditions are met (i.e. 
> whether it would be desirable for a particular NTP server on a dynamic 
> IP address to be admitted to the pool).
> 

There are *no* circumstances where this is a good idea. You *cannot*
make use of a server that is constantly moving IP address. Even fixed IP
addresses can be problematic in this environment since the clients don't
requery for addresses after they come up and if someone decides to move
the server elsewhere, they will never know about it.

>>> Advantages: dynamic DNS clients exist for lots of platforms.
>> Clients yes, servers no. The pool is a bunch of *servers* not clients so
>> why are you talking about the clients?
> 
> Because the pool members are NTP servers, but under my scheme would be 
> clients of the pool dynamic DNS service (in that they register their 
> current IP address with the pool). Users of the pool would be ordinary 
> DNS clients (in that they send ordinary DNS queries via their DNS 
> infrastructure which would ultimately be resolved by the pool 
> infrastructure servers), in addition to being NTP clients.

I know how dynamic DNS works having been part of the BIND 9 development
team. This is a detail of setup. You could equally well send a letter by
post to the maintainer of the DNS zone but you still have the same
problem that you started with: the NTP clients using it won't go back to
rerequest the address.

>>> The other disadvantage is that pool clients might, for a limited period 
>>> of time, hammer whoever next receives the IP address previously held by 
>>> a pool server.

Limited period? You must be joking. We've had enough instances of
publicly available NTP Stratum 1/2 servers been hammered for not just
months but *years*.

>>> Malevolant such inherintants of IP addresses might reduce 
>>> the perceived quality of the pool by telling the wrong time.
>> No, this isn't a limited length of time it's a long time, possibly
>> months until it ceases and even then maybe not. You should not be
>> guessing at the longevity of the provided IP address providing NTP service.
> 
> Please remember that I started this suggestion in the context of a 
> discussion of code being added to ntpd that re-resolves server addresses 
> in case of non-reachability. Such code, _if deployed on a critical mass 
> of clients_ (i.e. optimistically, not for a good few years) would 
> address your concern (while not completely removing it).

We are not the only provider of NTP Clients or for that matter servers
and unless they also make changes to also do this and have everyone
upgrade the problem will remain. For most people/admins this is a set
and forget item when they set up a system.

> Danny, please can you be a little less curmudgeonite? You have valuable 
> contributions to make, if only you made them less abrasively...

Sorry, it's not you.

Danny



More information about the questions mailing list