I think it is a valid concern. That made me thinking of the following:
What if the NTP servers would be able to report back the actual QPS value to the pool system?
That creates regulatory closed loop and permits the pool system to fine tune the traffic level to a particular NTP server.
That would probably miss the bozos who hit some arbitrary minute on the hour. Realistically it should be Qph, and there is no good option to decrease traffic levels other than opting out and hoping the bozos do not flood you. Particularly given clown clients that triple their query rate every time they’re told to go away (via KOD, ICMP administratively prohibited, or unnaturally lousy time). [/rant]
In the more innocent past, the Pool monitoring system could have used ntpdc/ntpq to scrape servers’ metrics…
I am thinking to submit a JSON object with members of packet number and time period.
That would allow QPS or QPh, or any arbitrary period, for example since the previous submission. It is flexible. Then, it is up to the pool infrastructure how to use those values.
Other members of the JSON object is the list of IP addresses for multi-homed systems, I am having system with both IPv4 and IPv6 addresses. The NTP daemon does not report separately the packet rate by protocol. One more member of the object would be a credential token, retrievable from the management interface after authenticating to it.
Try ntpq -c “keyid #” -c “passwd controlkeypass” -c ifstats
Cheers,
Dave Hart
The system is counting DNS queries per second, so that’s not completely impossible; though typically for this type of work the thing being measured will just count and then the thing measuring will calculate a rate based on that. To do per second measurements the thing being measured have to report the data with timestamps.
More than ten years ago I built a tool to try figuring out how many clients are behind each DNS server. The idea was to see if having really popular DNS servers get a shorter TTL (or more IPs or something else) would make the load get distributed better. https://www.mapper.ntppool.org/
I can’t find the code now but I did also at some point look into what it’d take to have a tool server operators could run to count the NTP queries (I think I used pcap to count on the network device; but it was awkward so if I tried again I’d use the chrony and ntpd control channel instead assuming the daemons can count reliably – though as @NTPman pointed out that’ll not work well on dual-stack servers. Firewall rules with counters is another option, but that’d require manual configuration across a bunch of different platforms to setup the rules; I don’t think a tool like this should mess with your firewall rules).
It was surprisingly much work (tweaking and fussing over I think several years) to get the DNS query logs and the infrastructure to count and process them reliably working all the time, but the tools are in place to deal with NTP query count data as well.
The new “zone generation” tool will use the DNS query logs (they are summarized by the country/continent of the client) as a proxy for “how many NTP queries”.
It’d be interesting to find out how accurate that actually is, but I don’t know how easily we could do that without having the tools setup to count on a bunch of servers (and the database tables, tools, etc to load and query the data), so I’ve been pushing it down the list of things to explore.
ntpq’s ifstats does break down packets received and sent per local address, so you would be able to differentiate IPv4 and IPv6 counts, and ignore loopback traffic and private-net traffic as needed.
