What is special about *.openwrt.pool.ntp.org

Last night I logged over a hundred DNS queries for the four servers in the *.openwrt.pool.ntp.org set. Almost all gave replies my DNS logging software classed as "N/A", which appears to be a catch-all for unidentifiable failures.

I know what "pool.ntp.org" is, I use the system to sync the clocks on my network. Network Time Protocol is pretty reliable. But it makes a big difference to use server addresses which are relatively close. So, here in Great Britain I use the *.uk.pool.ntp.org set. The general *.pool.ntp.org addresses also give good results.

Reading the documentation for pool.ntp.org I am not sure what you are trying to do, but the *.openwrt.pool.ntp.org set of servers seems a bad choice

https://www.pool.ntp.org/vendors.html#basic-guidelines

Original change request:
https://dev.archive.openwrt.org/ticket/2336

5 Likes

Thanks.

With the frequency of DNS requests I have logged, I draw your attention to a paragraph in the same document:

Do re-query DNS for a new NTP server IP address if one of the current NTP servers stops responding, though not more often than once per hour.

It looks as though OpenWRT should not be making so many DNS requests, over 100 in a few minutes. From my logs, it is possible that the root cause is slow responses from the DNS server I use. I was using Google's DNS servers. I have switched to another source.

(There are arguments for and against the Google public DNS servers. Privacy, for one thing.)

That would be an issue that must be fixed on the busybox side, OpenWrt uses it's ntp server applet.

Now we all know what is special about the bake in ntp service. For ten years.

My oldest running system OpenWrt: PogoPlug v4 Chaos Calmer 15.05 has it.

Users from all over the world use OpenWrt, and the question has been answered.

What remains for you is how to silence the logging or what is the "logging software you use that classifies the DNS queries as "N/A"" and how to point it correctly, yet that's a different topic/issue.

I for one just enable this and let Stubby handle my DNS.

Very briefly, the logging software I use does not limit the "N/A" classification to the {0,1,2,3}.openwrt.pool.ntp.org DNS queries. But there were a lot of them made for that domain which got that tag.

After changing the DNS server, I am seeing almost none. I can't explain that, but it is reported that there is a big difference in the response times of the two sets of servers.

That behaviour in general sounds very broken indeed and I would probably lean more towards using ntpdate or setup something like tlsdate ( https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+/refs/heads/master ) and have the user manually switch to ntpd avoiding not hammering online services by default. Perhaps it's also worth looking into using time. google.com/microsoft.com/apple.com etc

Actually it would be more worthwhile to notify upstream busybox about the issue instead of “silently” switching away from a known issue in OpenWrt…

1 Like

Obviously but looking at default (current) setup overall

I am getting confused. I had to look up busybox, and it appears there are a lot of compile-time options on which utilities it replaces. The references to "upstream busybox" initially had me wondering if people were making assumptions about the DNS servers.

The word "laconic" springs to mind, and I freely admit I don't have the skills or knowledge to get the context needed for some posts to make sense. But what I observed strongly suggests that the response times of the DNS servers is a factor.

Are you able to resolve these 4 hostnames if you try from the console or not?
They return all of them only 4 A records (at least for me when I tried now). Are the error messages connected to the lack of AAAA records from the answer?

They sometimes produce 4 AAAA records too for me - well 2 .openwrt.pool.ntp.org does.

My OpenWRT devices are sending >1000 DNS requests to *openwrt.pool.ntp.org over the span of several hours. My OpenWRT switch crashed, and since rebooting it I have not been seeing additional DNS requests. Does anyone have any suggestions for troubleshooting this?

As a side note I always change to time.cloudflare.com because it helps keep the load off of the ntp.org project and because of the vast amount of cloudflare points of presence it will always resolve faster.

4 Likes