That is true. DNS names would be nearly useless without automatic lookup.
That is not true. If you supply an IP address, then chronyd will use the IP address and generate no DNS queries at all.
It’s easy to run
tcpdump -ni eth0 port 53 to see what DNS queries chronyd is (or is not) issuing. Use
port 4460 or port 53 or port 123 and you can see all the traffic it generates, including NTS and NTP. Best to run it in a VM with nothing else and run ‘tcpdump -ni eth0’ inside the VM so you can see all traffic.
-n option to tcpdump–without it, tcpdump will generate its own PTR query for every host chronyd talks to so tcpdump can print the host’s name in the output.
Can you specify which chronyd version you are talking about and what non-default options you have set.
I can’t find evidence of support for a peer information protocol implemented in chronyd on the chrony site, documentation, or in Google, or any evidence of network traffic from a captive chronyd instance that would enable such a feature to work. I did find a reference to a remote management interface which could be used to implement this feature (something like ntpc list-peers), but it was removed in chrony 2.2 (and ntpc access is disabled on almost all public servers so it won’t work with ntpd either).
I can’t find any sign of an A/AAAA lookup using a name obtained from a PTR record from a captive chronyd. This is the behavior being discussed here, and the point Bas keeps missing. Yes, chrony sometimes does A record lookups and at other times uses PTR lookups using names and addresses supplied by the user, but chrony never takes the name from PTR and uses it in an A/AAAA query by itself. This needs to happen to create the effect OP observed–the client can’t send an A/AAAA query for the name of any individual host in the NTP pool because the client doesn’t know any name that would reach the server operator’s DNS server for the A/AAAA records. The client only knows
pool.ntp.org or some subdomain thereof, and has to get the name for the individual server some other way (like a PTR query on the server’s IP).
While I was looking for ways chrony could be generating A queries from PTR records, I found NTS. NTS does use host names on certificates, but if you configure a NTS server with an IP address, it’s not possible to validate the name on the certificate because chrony doesn’t have a name, only an IP. chrony could look up the PTR record to find the host name, but then chrony has no way to securely verify the PTR information–it can prove that the client has a valid certificate but not which certificate. In the 4.0 build I tested, when I give chrony an IP address and tell it to use NTS, chrony doesn’t even try–there are no PTR lookups or NTP packets, and the IP address is dead to chronyd even if it is later found as the result of a name (A/AAAA) lookup with NTS.
It’s possible to trigger an A/AAAA DNS lookup on a NTP server-chosen hostname with a NTS-KE reply, but 1) if the OP had set up NTS then presumably they are already aware of it and would not ask this question here, and 2) NTS wouldn’t work for
pool.ntp.org servers anyway. Also 3) I’m observing the same behavior and I’m definitely not serving NTS.
If the queries are being generated then somebody has to handle them. It’s barely 0.1% of the total NTP traffic, but presumably even that will be a problem in some cases, e.g. something that generates 0.1% of China’s NTP traffic in DNS queries would crush a smaller DNS server.
The signup page (pool.ntp.org: the internet cluster of ntp servers) mentions PTR records but not A/AAAA records. Those are often handled by different DNS servers and sometimes the A/AAAA server is really tiny. It could conceivably create a problem with connection tracking too–we tell people to exclude NTP from conntrack, but we don’t mention DNS in that context. A server that has 500k pps of NTP could start having conntrack problems with DNS.
If the server is dedicated to NTP, there’s no need to provide a PTR record at all. That would prevent the following A record lookup, and also push the PTR DNS query costs up to whoever’s authoritative for the parent domain in the DNS hierarchy.