[Ntp] Re: NTPv5 Requirements vs. NTPv5 Spec

["Windl, Ulrich" <[e-mail]>]

> -----Original Message-----
> From: Miroslav Lichvar <[e-mail]>
> Sent: Monday, June 23, 2025 3:24 PM
> To: Mike Ellis <[e-mail]>
> Cc: Windl, Ulrich <[e-mail]>; Tal Mizrahi
> <[e-mail]>; NTP WG <[e-mail]>
> Subject: [EXT] Re: [Ntp] Re: Re: Re: NTPv5 Requirements vs. NTPv5 Spec
> 
> On Fri, Jun 20, 2025 at 02:09:07PM +0000, Mike Ellis wrote:
> > Hi all,
> >
> > My thoughts, worth all of the nothing you've paid for them...
> >
> > An NTP server MUST carry out a new DNS lookup for peers after the TTL
> has expired.
> 
> I think the DNS TTL is normally way too short to be used like that.
[Windl, Ulrich] 

I disagree: If people set TL to improper values, it's their fault.
I don't see why someone would set a TTL to 5 minutes (or similar) for regular operation; it may be appropriate when changes are planned, like replacing a host soon, and then it wold be done ahead of time. Also an expired TTL does not mean the the NTP association has the be replaced; only if the IP used is no longer returned.
In the case of pool servers I think that the TTL is a very important element.

> This would increase the pool.ntp.org DNS traffic dramatically. Another
> problem is that the commonly used system resolver API - getaddrinfo()
> doesn't provide the TTL.
[Windl, Ulrich] 

Well, you have the coice:
1) Using outdated IPs that once were part of some pool, but preserving DNS traffic
2) Use up-to-date IPs from the pool, but require more frequent DNS queries.

On the TTL per se: I don't think that a TTL of one to three days will cause a lot of traffic, and OTOH I don't think that pool servers change more frequently than daily; if the do, they are not suitable for being pool servers IMHO.

> 
> I'd expect the recommended refresh interval to be at least a week.
[Windl, Ulrich] 
...and the reason is?

> I'm not opposed to have a recommendation like that in the draft.
> 
> >  * If the same IP address is returned, carry on using it.
> >  * If a different IP address is returned AND the new peer claims to share
> the same upstream reference, carry on using it.
> >  * If a different IP address is returned AND the new peer claims a different
> upstream reference, start using it, but flush the statistics related to the
> previous peer.
> 
> A different address to the same server could be routed differently and
> have a different network delay, so I'd suggest to reset the state on
> all address changes.
[Windl, Ulrich] 

Isn't that a non-argument as IP datagram routing may change anytime, even when using the same IP?

> 
> --
> Miroslav Lichvar