NTP Pool Project - Latest posts

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@stevesommars Steven Sommars — Wed, 18 Mar 2026 00:45:00 +0000

Are you thinking about https://publicntp.org/ ?

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@ebahapo — Wed, 18 Mar 2026 00:25:38 +0000

There used to be one, which was akin to a club of aficionados about time keeping. They would add their servers, all stratum 1, to their publicly available pool and would even meet up to exchange information and socialize. Unfortunately, I lost the bookmark eons ago and my memory failed me to find them again.

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@grifferz Andy Smith — Tue, 17 Mar 2026 23:40:41 +0000

I’d be really interested to see and participate in a new pool that is IPv6-only from the start.

As it seems that full IPv6 adoption on the pool’s side has been something that has intentionally not been pursued over a time period of many years, it would be a clear differentiator and an additional reason for existence of another pool.

404 error on retrieving metrics this morning

@FerGaX Fernando Garduño — Tue, 17 Mar 2026 23:32:02 +0000

I confirm error continues on 2026-03-17, 17:31 CST (23:31 UTC).

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@ebahapo — Tue, 17 Mar 2026 17:47:56 +0000

Of course that it’s possible, but the threshold to fork off an open source software project is historically higher. Methinks that we’re still far from that and that not all remedies have been tried yet.

Problems with API for getting server scores

@HAHAHAHA — Tue, 17 Mar 2026 08:26:21 +0000

As server score is not available since 3/16:

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@Kets_One — Tue, 17 Mar 2026 07:50:52 +0000

Hi, just playing with a thought here.

Would it be possible to start a new NTP pool to overcome some of the issues we have been facing over the last few years? Surely this would be a massive undertaking, but we could start small.

Problems with API for getting server scores

@ChrisJ Chris — Tue, 17 Mar 2026 07:31:16 +0000

I don;t know if this is related to the recent migration but for the last couple of days my automated mechanism to periodically check my server scores is not working:

$ curl --connect-timeout 5 --max-time 10 -s ‘https://www.ntppool.org/scores/212.69.48.211/json?limit=1&monitor=24’
{“message”:“Not Found”}

Is there some known issue? Has the API call changed? It has been working fine for many months.

404 error on retrieving metrics this morning

@andersnordh Andersnordh — Tue, 17 Mar 2026 07:27:43 +0000

Hi, this started yesterday …

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@HAHAHAHA — Tue, 17 Mar 2026 03:29:56 +0000

Different problems require different solutions.

Having the server metrics being inoperative for a prolonged period of time will cause trouble to server management and damage reputation of this project to the public (even if the actual NTP service is unaffected).

If you have been here long enough, you might have heard about the delayed responses to vendor zone applications in the previous years, which was another example of the lack of process and timely management impacting operation and reputation of the Pool.

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@HAHAHAHA — Tue, 17 Mar 2026 03:27:22 +0000

From a management point of view, I do agree that this important project could benefit from establishment of reasonable (but not excessive) structures and processes, to ensure that it could be well maintained with timely failure resolution for the long run.

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@HAHAHAHA — Tue, 17 Mar 2026 03:19:14 +0000

I just want to share that since the 404 error on server monitor metrics started appearing from 3/16, traffic to my server has increased dramatically (from 40-50K requests per second to over 80K requests per second), as shown in the real-time statistics of my router below.

Both my server and router are handling such load very well, but just curious if this is a coincidence or causation of the 404 error.

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@ebahapo — Mon, 16 Mar 2026 22:25:28 +0000

Quod erat demonstrandum.

Truncated FQDN/addresses via 'chronyc sources'

@Mpegger — Mon, 16 Mar 2026 13:11:01 +0000

I see.

But I also see that was 2 weeks ago and the last release was from 2025. So until the next official release, this would be something only accessible to those able to compile the code on thier own, and willing use it in essentially a untested Alpha state.

404 error on retrieving metrics this morning

@ronv42 Ronv42 — Mon, 16 Mar 2026 10:23:24 +0000

Looks like the monitor is not functional this morning:

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@Kets_One — Mon, 16 Mar 2026 08:41:57 +0000

Looks like issues are back again, but now with an 404 Error.

Truncated FQDN/addresses via 'chronyc sources'

@mlichvar Miroslav Lichvar — Mon, 16 Mar 2026 08:23:13 +0000

… using the Web UI. They were merged manually by the maintainer.

Truncated FQDN/addresses via 'chronyc sources'

@Mpegger — Sun, 15 Mar 2026 14:45:25 +0000

Merge details

The changes were not merged into master.

Truncated FQDN/addresses via 'chronyc sources'

@paulgear Paul Gear — Sun, 15 Mar 2026 11:50:23 +0000

There’s also a wider output option recently added: chronyc: add wide output option (!32) · Merge requests · chrony / chrony · GitLab

Truncated FQDN/addresses via 'chronyc sources'

@Mpegger — Sat, 14 Mar 2026 21:54:25 +0000

Doh. Stupid me, I was using the switch after the command. Apparently, some switches, like -v for verbose, works after the command. No wonder -n never seemed to show a different result when I was using it after the command. Would be nice if the output adjust the size of the columns according to the size of the “screen” like htop and other apps do.

Truncated FQDN/addresses via 'chronyc sources'

@avij Anssi Johansson — Sat, 14 Mar 2026 21:51:46 +0000

My chronyc (v4.6.1) shows the untruncated IPv6 address with “chronyc -n clients”. Doesn’t yours?

I’d use the -n option to not look up the reverse DNS name for the address. You can look up the reverse DNS name separately later on if needed.

I’m confused why you mentioned “sources”. You can see your sources from your /etc/chrony.conf or with “chronyc ntpdata”.

Truncated FQDN/addresses via 'chronyc sources'

@Mpegger — Sat, 14 Mar 2026 21:30:06 +0000

For the life of me I can’t find the answer to this, and I could have sworn it was possible, but when using a command like ‘chronyc sources’ if the FQDN or IPv6 address is too long to show in the column, it gets truncated. Wasn’t there a switch that could be used with chronyc that would prevent truncating the name/address and show it in it’s entirety? If there isn’t, is there a log I could grep to get the full FQDN/IPv6 address? I just opened up port 123 to the WAN yesterday, but I am not part of the pool, yet I already see some traffic from unknown clients in the ‘chronyc client’ log. Most likely just port scanners (they only have around 2 connect attempts hours ago), but for those malicious actors I’d like to know so I can block them at the firewall.

Marantz SR5015 AVR – firmware bug causing excessive NTP polling (every 20 seconds)

@torsten — Sat, 14 Mar 2026 10:23:14 +0000

Firmware version: 4400-2103-8116-8080

Can’t confirm if it’s a regression – I only started monitoring network traffic recently. The device has been running for years, so I wouldn’t have noticed before.

Marantz support responded asking for HEOS app diagnostics, which completely misses the point. I’ve clarified that this is a firmware-level NTP issue, not an app problem. Will keep you posted.

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@davehart Dave Hart — Fri, 13 Mar 2026 19:57:32 +0000

That stuff all sounds awfully dreary to me, but I understand the motivation. Are you volunteering to take on that type of work for the project?

It is also possible to have the appearance of hitting all your checkpoints and still have nonobvious single points of failure or choke points that butterfly wings could bring down.

Marantz SR5015 AVR – firmware bug causing excessive NTP polling (every 20 seconds)

@davehart Dave Hart — Fri, 13 Mar 2026 19:44:56 +0000

No apology necessary. The rapid-fire retries are abusive. Is this a regression with the latest version of their firmware? Regardless, which version did you see this with?

Thanks for sharing your findings. Please keep us posted on the vendor response.

Paper: Measurement-Informed Understanding of the NTP Pool’s Robustness to Monopoly Attacks

@Bas Bas Heijermans — Fri, 13 Mar 2026 15:02:55 +0000

Ok, that is bad. didn’t know that.

Some DNS servers unresponsive

@MagicNTP — Fri, 13 Mar 2026 09:35:13 +0000

The Pool’s own view of the situation.

NTS Pool experiments

@MagicNTP — Fri, 13 Mar 2026 08:06:59 +0000

You pointed out that there may be an issue. I pointed to a potential solution. Whether that suits your needs is up to you.

On the chain of trust, as I re-iterated several times, some aspect of this depends on how important this issue is, and how much effort one is willing to spend. If it is important, and one is willing to spend a little effort, one can achieve the exact same level of trust as an Ubuntu user would when they install the certificate via their package manager.

Also, again up to you obviously whether it is sufficient for your purposes, simply downloading from a trusted source may also be sufficient.

On the other hand, one can also exxaggerate things and put requirements on this step that by far outsize the security guarantees that other steps/aspects of the whole construct of using NTS provide. When one assumes that the server from which one downloads the certificate has been hacked, and the protections afforded by the certificate that “protect” that server have been broken, what makes you assume that the same thing cannot happen with the NTS server itself? And why do you trust the root certificates that some vendor has placed on your system and that are the basis for trusting other NTS servers such as Cloudflare’s, SIDN’s, or pretty much any other out there? Have you ensured every step from their generation and them ending up on your system was trustworthy, when you probably simply downloaded the packages for your OS from some source on the Internet?

Anyway, as said, I just provided information I considered relevant, what you do with it is up to you. If it is not helpful to you and does not meet your requirements, sorry to hear. But maybe it helps other people that have similar expectations as myself, which I believe to be reasonable: Get a similar level of trust as an Ubuntu user who installed the certificate via their package manager. Nothing more, nothing less.

Marantz SR5015 AVR – firmware bug causing excessive NTP polling (every 20 seconds)

@torsten — Fri, 13 Mar 2026 07:26:39 +0000

Update: Turns out part of this was my own misconfiguration. My router was running as NTP server, but I forgot to open port 123 in the firewall. The device never got a response, so it kept retrying.

After fixing that, the polling stopped immediately.

However, the underlying behavior is still problematic:

poll 0 (1s) is way too aggressive for retries
No exponential backoff
Garbage timestamps in the requests
Using 0.linksys.pool.ntp.org without a proper vendor zone

So the firmware still has issues, but the constant polling was amplified by my setup. Apologies for the noise.

Marantz SR5015 AVR – firmware bug causing excessive NTP polling (every 20 seconds)

@mlichvar Miroslav Lichvar — Fri, 13 Mar 2026 06:44:04 +0000

Ok, that doesn’t look like something that could be easily detected on a public server.

NTS Pool experiments

@ebahapo — Thu, 12 Mar 2026 23:51:58 +0000

You are suggesting a weak chain of trust that defeats the purpose of NTS.

It’s better to configure a plain NTP server than the illusion of a trusted NTS server.

Some DNS servers unresponsive

@lordgurke Max — Thu, 12 Mar 2026 23:07:29 +0000

Hi,

some of the authoritative DNS servers for pool.ntp.org are unresponsive at least since about two weeks, thus are slowing down name resolution.

Currently (2026-03-12, 22:50Z) the following servers do not respond to DNS queries, tested from multiple locations in Europe and North America:

185.134.197.79 (part of a.ntpns.org), no response
77.90.25.251 (part of b.ntpns.org), connection refused
160.119.216.201 (part of b.ntpns.org), connection refused
2001:43f8:d60:300::201 (part of b.ntpns.org), no response, network not in BGP DFZ
2a0e:b107:27f9:123::53 (part of b.ntpns.org), no response, ICMP network-unreachable
89.40.214.141 (part of c.ntpns.org), connection refused
2600:3c02::f03c:92ff:fe5f:baf1 (part of c.ntpns.org), connection refused
2a00:14b0:4200:32e0::1e5 (part of c.ntpns.org), connection refused
2a05:91c0:1506:145:: (part of c.ntpns.org), connection refused
2a0b:4341:1500:142:5054:ff:fef5:ba1c (part of c.ntpns.org), connection refused
2407:b9c0:f001:3a2:5054:ff:fe83:a2ff (part of d.ntpns.org), no response
51.89.70.90 (part of d.ntpns.org), no response
2001:41d0:700:335d::12 (part of d.ntpns.org), connection refused

I have a feeling, some of these servers were shut off by their operators (those that are unresponsive to DNS and ping) – which could pose a risk, if the corresponding IP gets reassigned to some other customer in the future. In that scenario, the new owner of that IP could send malicious replies to questions for the NTP pool.

Those servers, that respond with some sort of ICMP “port-unreachable” or TCP-RST might just have trouble with the DNS service and might just need a restart.

Is this a known problem?

NTS Pool experiments

@MagicNTP — Thu, 12 Mar 2026 21:27:22 +0000

Yes, that is what I meant by “manual configuration”: Get the certificate, and two configuration snippets needed to make use of the certificate, and put them in their proper places.

Not sure what exactly you consider “not officially publicly”. It is available through different publicly accessible means that one could consider “official” in the sense that they are run by Ubuntu. To my knowledge, it is not explicitly presented for download on a dedicated page like a CA such as Let’s Encrypt would publish their root certificates.

Not sure whether there is some sort of license needed to “officially” be allowed to make use of it once obtained, or permission to “officially” be allowed to access the server (which Ubuntu users might both be granted automatically).

Which way one gets the certificate depends on the way one wants to establish the chain of trust for the certificate, and how important this topic is, i.e., how much effort to spend.

Marantz SR5015 AVR – firmware bug causing excessive NTP polling (every 20 seconds)

@torsten — Thu, 12 Mar 2026 19:43:47 +0000

Sure, here you go:

sudo tcpdump -i eth0.30 -v -n port 123 and host 10.0.30.254 -c 30
tcpdump: listening on eth0.30, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:32:16.164103 IP (tos 0x48, ttl 63, id 17866, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.42525 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 563978829.226622598 (1917-11-15T12:47:09Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 563978829.226622598 (1917-11-15T12:47:09Z)
20:32:16.164174 IP (tos 0x48, ttl 63, id 21332, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.57812 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 493850233.576861346 (1915-08-26T20:37:13Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 493850233.576861346 (1915-08-26T20:37:13Z)
20:32:16.164222 IP (tos 0x48, ttl 63, id 55530, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.43218 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3267198725.596538964 (2003-07-14T19:12:05Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3267198725.596538964 (2003-07-14T19:12:05Z)
20:32:16.164265 IP (tos 0x48, ttl 63, id 22522, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.45629 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 2430285343.915923795 (1977-01-05T07:15:43Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 2430285343.915923795 (1977-01-05T07:15:43Z)
20:32:16.164381 IP (tos 0x48, ttl 63, id 55408, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.34224 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 815330357.519660853 (1925-11-02T16:39:17Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 815330357.519660853 (1925-11-02T16:39:17Z)
20:32:36.185634 IP (tos 0x48, ttl 63, id 19866, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.38556 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 4034398744.605182001 (2027-11-05T10:19:04Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 4034398744.605182001 (2027-11-05T10:19:04Z)
20:32:36.185704 IP (tos 0x48, ttl 63, id 23291, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.48777 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 2935196462.833741018 (1993-01-05T04:21:02Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 2935196462.833741018 (1993-01-05T04:21:02Z)
20:32:36.185751 IP (tos 0x48, ttl 63, id 55828, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.37040 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3889099884.946815201 (2023-03-29T17:31:24Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3889099884.946815201 (2023-03-29T17:31:24Z)
20:32:36.185863 IP (tos 0x48, ttl 63, id 23867, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.47649 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3102538026.539462763 (1998-04-26T00:07:06Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3102538026.539462763 (1998-04-26T00:07:06Z)
20:32:36.185980 IP (tos 0x48, ttl 63, id 56519, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.39742 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 1921798956.527349175 (1960-11-25T01:02:36Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 1921798956.527349175 (1960-11-25T01:02:36Z)
20:32:56.206162 IP (tos 0x48, ttl 63, id 21503, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.38364 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 496630368.599049167 (1915-09-28T00:52:48Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 496630368.599049167 (1915-09-28T00:52:48Z)
20:32:56.206215 IP (tos 0x48, ttl 63, id 24242, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.35129 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 1712793442.186327524 (1954-04-11T23:57:22Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 1712793442.186327524 (1954-04-11T23:57:22Z)
20:32:56.206325 IP (tos 0x48, ttl 63, id 56255, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.35438 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 454817106.682610539 (1914-06-01T02:05:06Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 454817106.682610539 (1914-06-01T02:05:06Z)
20:32:56.206326 IP (tos 0x48, ttl 63, id 24095, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.54097 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3920274484.827418594 (2024-03-24T13:08:04Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3920274484.827418594 (2024-03-24T13:08:04Z)
20:32:56.206371 IP (tos 0x48, ttl 63, id 57779, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.52239 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 2892811552.717540332 (1991-09-02T14:45:52Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 2892811552.717540332 (1991-09-02T14:45:52Z)
20:33:16.228834 IP (tos 0x48, ttl 63, id 22060, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.33181 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 2191987289.664144060 (1969-06-18T05:21:29Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 2191987289.664144060 (1969-06-18T05:21:29Z)
20:33:16.229311 IP (tos 0x48, ttl 63, id 25971, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.39218 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 2349432189.463985518 (1974-06-14T12:03:09Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 2349432189.463985518 (1974-06-14T12:03:09Z)
20:33:16.229856 IP (tos 0x48, ttl 63, id 57885, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.42238 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 2232868913.905411968 (1970-10-04T09:21:53Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 2232868913.905411968 (1970-10-04T09:21:53Z)
20:33:16.230479 IP (tos 0x48, ttl 63, id 24276, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.43769 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 734808686.219598611 (1923-04-15T17:31:26Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 734808686.219598611 (1923-04-15T17:31:26Z)
20:33:16.230967 IP (tos 0x48, ttl 63, id 57855, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.52509 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3476407165.639297549 (2010-03-01T04:39:25Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3476407165.639297549 (2010-03-01T04:39:25Z)
20:33:36.252859 IP (tos 0x48, ttl 63, id 23895, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.56704 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 2334423824.805036689 (1973-12-22T19:03:44Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 2334423824.805036689 (1973-12-22T19:03:44Z)
20:33:36.252924 IP (tos 0x48, ttl 63, id 26097, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.47066 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 280080920.840844357 (1908-11-16T16:15:20Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 280080920.840844357 (1908-11-16T16:15:20Z)
20:33:36.253052 IP (tos 0x48, ttl 63, id 58427, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.51535 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3076136720.724097436 (1997-06-24T10:25:20Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3076136720.724097436 (1997-06-24T10:25:20Z)
20:33:36.253054 IP (tos 0x48, ttl 63, id 25603, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.45724 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 203035239.183283398 (1906-06-08T22:40:39Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 203035239.183283398 (1906-06-08T22:40:39Z)
20:33:36.253109 IP (tos 0x48, ttl 63, id 59221, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.51893 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 1712032538.783680989 (1954-04-03T04:35:38Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 1712032538.783680989 (1954-04-03T04:35:38Z)
20:33:56.280829 IP (tos 0x48, ttl 63, id 25255, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.37316 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 4162381657.322145718 (2031-11-25T17:07:37Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 4162381657.322145718 (2031-11-25T17:07:37Z)
20:33:56.281275 IP (tos 0x48, ttl 63, id 26412, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.58140 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3482150668.682849832 (2010-05-06T16:04:28Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3482150668.682849832 (2010-05-06T16:04:28Z)
20:33:56.281777 IP (tos 0x48, ttl 63, id 58888, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.35674 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 1713922678.527505960 (1954-04-25T01:37:58Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 1713922678.527505960 (1954-04-25T01:37:58Z)
20:33:56.281978 IP (tos 0x48, ttl 63, id 27372, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.35656 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 1668834161.368705711 (1952-11-19T05:02:41Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 1668834161.368705711 (1952-11-19T05:02:41Z)
20:33:56.282194 IP (tos 0x48, ttl 63, id 60773, offset 0, flags [DF], proto UDP (17), length 76)
10.0.30.254.34743 > 10.0.30.2.123: NTPv4, Client, length 48
Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 1744706319.902365646 (1955-04-16T08:38:39Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 1744706319.902365646 (1955-04-16T08:38:39Z)
30 packets captured
30 packets received by filter
0 packets dropped by kernel

Marantz SR5015 AVR – firmware bug causing excessive NTP polling (every 20 seconds)

@mlichvar Miroslav Lichvar — Thu, 12 Mar 2026 18:19:27 +0000

Can you please post tcpdump -v output (without IP addresses if you want to keep them private) showing some of the NTP requests?

Marantz SR5015 AVR – firmware bug causing excessive NTP polling (every 20 seconds)

@torsten — Thu, 12 Mar 2026 17:59:33 +0000

Hi all,

I wanted to report a firmware bug in the Marantz SR5015 AV receiver that’s hammering NTP infrastructure.

After a recent firmware update, the device sends NTP-related DNS queries every 20 seconds – 10 requests per cycle:

time1.google.com / time2.google.com / time3.google.com / time4.google.com (A + AAAA)
0.linksys.pool.ntp.org (A + AAAA)

That’s approximately 4,300 DNS lookups per hour or 43,000 per day – per device. After each DNS resolution, it sends the actual NTP request.

I have logs showing 65,000+ queries accumulated in roughly 36 hours.

My network mitigates the impact:

AdGuard Home caches the DNS responses (response times ~0.1ms confirm cache hits)
dst-nat rules hijack all outbound NTP traffic to my local MikroTik Router

So in my case, neither the pool nor Google’s NTP servers actually see the traffic. But I suspect the vast majority of SR5015 owners don’t have this setup – meaning this bug is likely generating millions of unnecessary requests against pool.ntp.org and time.google.com globally.

The device queries 0.linksys.pool.ntp.org – that’s Linksys’ vendor zone, not Marantz’s. Suggests they’re using inherited code without a proper vendor zone.

I’ve submitted a bug report with 1000 lines of DNS logs to Marantz DE support. No response yet.

Wanted to give you a heads-up in case this is visible in pool traffic patterns or if there’s a way to escalate with vendors.

Cheers

NTS Pool experiments

@ebahapo — Thu, 12 Mar 2026 17:15:20 +0000

It does not work on other systems without Ubuntu’s certificate file installed. AFAIK, this certificate is not officially publicly available.

NTS Pool experiments

@MagicNTP — Thu, 12 Mar 2026 15:47:21 +0000

Yes, on other systems, it requires manual configuration. I have a tar file that I can just extract on new hosts. Ultimately, I guess it depends on how badly one wants to prevent the issue you describe, and how much effort one is willing to spend. The infrastructure and the means are there. YMMV.

NTS Pool experiments

@ebahapo — Thu, 12 Mar 2026 15:41:58 +0000

That works only with Ubuntu out of the box, which comes with a special certificate pre installed.

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@marco.davids marco.davids@sidn.nl — Thu, 12 Mar 2026 15:12:51 +0000

While I agree with you, it could still be a one-man show to some extent.

For example:

Do other people have access to the backend systems that operate the pool?
Is there a legal entity (e.g., a foundation) to ensure continuity?
Is there a budget to cover operational expenses?
Is there any kind of advisory or oversight board?

Etc.

I genuinely don’t know the answers to these questions.

Ultimately it comes down to the bus factor: how many people could realistically keep the pool running if the primary maintainer disappeared tomorrow?

–
Marco

NTS Pool experiments

@MagicNTP — Thu, 12 Mar 2026 14:47:06 +0000

I use Ubuntu’s NTS bootstrap service to prevent that. It uses certificates that have an extremely long validity so that even devices without RTC, whose clock may be off as far as the Unix epoch, will accept them, and set initial time off of those servers before transitioning to use the other NTS servers as well.

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@ebahapo — Thu, 12 Mar 2026 14:16:02 +0000

I quite disagree. The number of open PRs, not to mention neglecting fully supporting IPv6, for years in GitHub is the sign of anything, but a benevolent dictator.

NTS Pool experiments

@ebahapo — Thu, 12 Mar 2026 14:12:20 +0000

It is an interesting article, thank you.

I do run NTS servers using chrony and noticed that, once it’s established a secure connection to another NTS server, it would reject non NTS servers.

However, upon start, it might not validate its NTS servers, because its time was too far off to validate their certificates, so it might linger unsynchronized. Then, it’s necessary to there be non NTS servers to set the initial time accurately in order to validate the NTS servers. That’s when it’s vulnerable to attacks, as any NTP server, which might be used even to establish an impostor NTS server.

NTP Stratum 1 statistics?

@ebahapo — Thu, 12 Mar 2026 13:00:44 +0000

In actuality, each server was returned in 100% of the queries. The current metrics are misleading.

NTS Pool experiments

@richard Richard Ames — Thu, 12 Mar 2026 06:15:44 +0000

This article may be of interest:

https://www.potaroo.net/ispcol/2026-03/nts.html

Paper: Measurement-Informed Understanding of the NTP Pool’s Robustness to Monopoly Attacks

@gunnar Gunnar Hofmann — Thu, 12 Mar 2026 04:04:04 +0000

No, the “server” directive in ntpd used to resolve the hostname once on start-up and keep trying the IP for as long as your ntpd was running. That was no foul play by caching DNS resovers, just the architecture of ntpd. For your convenience you could put a hostname or IP there, and it was expected to be a long living time server. And since it was a server line with one server expected, it took just one IP even is multiple were returned by a DNS lookup. So the approach of resolving the hostname once on start-up made sense.
Then the “pool” directive was introduced later when the ntppool was well established and more and more people ran servers and the distros shipped default configuration files. This directive
a) takes all IP adresses from the lookup and add them as sources
b) replaces non-responsive servers after I think 1h by new IPs resolved from the hostname in the config file
c) removes duplicate IPs (if you have several pool lines for example and they include a common server)

Unfortunately the “pool” directive came late in the grand scheme of things, so not every ntpd (especially on LTS distros or embedded devices) understands it yet and still uses the old “one static IP/server per line” approach.

NTP Stratum 1 statistics?

@HAHAHAHA — Thu, 12 Mar 2026 02:59:01 +0000

As described in the server stats page, 100 ‱ means 1%. This really helps eliminating many zeros in the numbers, especially for low-load servers.

NTP Stratum 1 statistics?

@alica CS Chen — Wed, 11 Mar 2026 19:54:14 +0000

The reason to use ‱ is to put the decimal point in the proper place to get an easy-to-read number without many zeros. If stick with % then the former listing will become:

Global points 0.01909 %
Top Countries
uy 18.62509 % 73.52941 % (0.25x)
br 0.00482 %
ar 0.01236 %
us 0.00038 %
bo 0.11281 %

Example in the reverse direction would be the k/M/G prefixes. Maybe you would like to describe a computer as 4000000000 Hertz octa-core CPU with SSD of 4000000000000 bytes…

NTP Stratum 1 statistics?

@Bas Bas Heijermans — Wed, 11 Mar 2026 16:00:54 +0000

@ask. maybe you should drop the entire ‱ thing and just turn it into %.

I mean, not many of us get it, and I had an A+ on math when I was younger.

I never learned about this one, and I do not get it. Sorry.

Why not simply state, it seems your server is serving 0.0182% of the be zone, to give an example and then x-number of DNS-requests counted out of total-zone-requests.

That will make far more sense to most people. Simple point out that this is counted at the DNS-server, it could differ with your experiance.

Your listing and way of showing it, sorry to say, it terribly confusing and hard to grasp.

Your example, if a country has 4 servers, eacht server would do 25%…now that is easy to understand. This 2500‱ is horrible.

Monitoring and DNS services seems to have issues today ( 2026-03-01)

@Bas Bas Heijermans — Wed, 11 Mar 2026 15:51:14 +0000

Dave, ignore it. It’s an AI-bot testing it’s capabilities to pass for humanoid skills.

Useless to react to such nonsens postings.