[Ntp] Antw: [EXT] Pool and DNS

>>> Hal Murray <halmurray@sonic.net> schrieb am 19.10.2022 um 06:42 in
Nachricht
<20221019044237.8DE2C28C1DB@107-137-68-211.lightspeed.sntcca.sbcglobal.net>:

>> Around 250 DNS queries are required by Khronos to obtain a pool of 1000
NTP
>> servers, which is equal to the number of queries performed by NTPv4 in a
>> duration of 10 days (assuming a query per hour).
> 
> Where did that "a query per hour" come from?

Good question: maxpoll default is still 10, and on typical servers a higher
number like 12 makes little sense.

> 
> It's not wildly wrong and I don't have a better number.  But I worry that 
> somebody will assume it is a solid data point and use it in some future line

> 
> of reasoning.
> 
> ‑‑‑‑‑‑‑‑
> 
> My reading is that pool traffic is bimodal.  ntpd makes a few DNS requests 
> on 
> startup then uses those servers for a long time.  sntp makes a DNS request 
> every time it is run.
> 
> You can see that by watching the traffic on a server in the pool when you 
> disable it by setting the traffic rate to monitor‑only.  The traffic drops 

By "disabling" you mean removing it from the DNS pool, but keep it running?

> abruptly by X%, then slowly decays.  "Slowly" is ballpark of 10% per day.  X

> 
> is ballpark of 60%.  (I didn't get decent data because I only figured out 
> what 
> was going on after I had already messed things up.  Next time...)
> 
> ‑‑‑‑‑‑‑‑‑‑
> 
> The main problem with DNS and the pool is that there is currently no clean 
> way to remove a server from the pool.  If you remove it from the pool, the 
> sntp traffic will vanish since it will get removed from future DNS answers. 

> But the ntpd traffic will continue to use existing servers as long as ntpd 
> keeps running and the servers keep responding.

Not quite: If the server performs worse than the rest, ntpd wil request
another one, dropping the bad one.
We are runníng most servers using manycast here, but the mechanism should be
similar.

> 
> There is no way to ask if a server is still in the pool.  If there was, ntpd

> should check every day or week or ...  That would add more DNS traffic from

> the long running ntpd servers.  Khronos would add much more.
> 
> ‑‑‑‑‑‑‑‑‑‑
> 
> The more interesting question is NTS.  The NTS‑KE step is fairly
heavyweight, 
> much more work than a DNS lookup.
> 
> The current parameters are 8 cookies with a lifetime of a day.  A day is 
> 86400 seconds.  That means we need to poll each server every 10800 seconds. 

> With 1000 servers and M=15 (from the draft) that will take a Khronos poll 
> every (10800/1000)*15 => 162 seconds.  If Khronos runs at 10x the poll time
of 
> ntpd, that's not going to work.
> 
> We could gain a factor of 2 or 3 by dropping cookies older than a day.  (and

> asking for several more to fill up again when we do poll a server)
> 
> Of course, NTS doesn't work with the pool and I don't see how to fix that, 
> so this is all a wild goose chase.
> 
> 
> Maybe we should be comparing Khronos with 1 or 2 trusted servers using NTS.
> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 