example: internally dd05:cafe::1bad:babe gets 20a2:XYZA:GHJZ:ESIT::1bad:babe on public. In combination with dynv6 it is pretty useable as a consumer. Well, getting a static connection is better, but not all ISP offer it for free. 1 of 3 of mine does at least…

The CSV tells the truth – the data from the monitors stopped flowing at around 12:42:16, ie. 6.5 hours ago.

EDIT: I would have written a new message, but “An error occurred: No more than 3 consecutive replies are allowed. Please edit your previous reply, or wait for someone to reply to you.”

What I meant to say: Looks like the certificate problem is fixed now and test monitors can send their measurements again.

EDIT2: IPv6 address of api.test.mon.ntppool.dev is still unreachable, though.

level=ERROR msg=“batch processing” env=test err=“getting server list: unavailable: tls: failed to verify certificate: x509: certificate is valid for localhost, ingress.local, not api.test.mon.ntppool.dev”

level=INFO msg=“detected certificate/connection error, flushing connection pool” pool-flusher.url=https://api.test.mon.ntppool.dev/monitor.v2.MonitorService/GetServers pool-flusher.error=“tls: failed to verify certificate: x509: certificate is valid for localhost, ingress.local, not api.test.mon.ntppool.dev”

Many test monitors seem to be unable to phone home now, based on the plots on e.g. 194.100.49.152.

Issue with registration of a test NTP Pool Agent version v4.1.4

Maybe a new topic for the airport codes would be nice. I don’t think that mechanism has changed during this ongoing service move. Reading this message first may be informative.

I guess this topic is generic enough, so for me looks fine, thanks for the heads up.

I have the same issue, in the drop down menu an airport of the distance about 10 kilometers (nearest one from the location of my monitor) is not offered. May be free input of the IATA code could help?

Yes, please, implement this feature, if possible.

As for this test monitor, I now get:

level=ERROR msg=“could not get config, http error” env=test ip_version=v4 err=“unavailable: tls: failed to verify certificate: x509: certificate is valid for localhost, ingress.local, not api.test.mon.ntppool.dev”

so something is still not quite working.

Edit: Additionally, api.test.mon.ntppool.dev has an IPv6 address as well but that seems to refuse connections.

The next issue, may be I should open another topic for that?
The nearest airport (~10 km) is missing from the list of airports that I could select for the name of the monitor.

Ho hum, nothing happened when the certificate expired. I had left this test agent instance running, waiting for the cert to expire (the server where I tried to restart the agent was a different one). So this instance will keep testing for now.

But I get it, the agent keeps a connection open all the time and the cert gets checked only when establishing the connection. Restarting the service would probably trigger a certificate check. But restarting the service would currently fail anyway due to the issue mentioned above.

Restarting the agent that was already failing to start up (my previous message) but with a certificate that had expired in the meantime gave me this:

level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s
level=INFO msg=“load failed” env=test err=“unexpected response code: 404 (trace )”

I had expected some other error than a 404. Maybe renewing the certificate does not need a valid certificate?

So I guess as long as a back-end connection was still active since before the current outage on beta, it’ll keep working. But once it needs to be re-established, e.g., due to agent restart, or newly established (as during registration), the daemon will refuse to run due to the inability to successufully connect with the back-end.

It will be interesting to see whether the upcoming expiry of the certificate will also break the connection. I guess as long as it tries to obtain a new certificate over an existing connection, it might be fine. But should it get a new certificate and try to re-establish the connection, that might break things.

Except that it seems not unlikely that once the certificate renewal starts working again, also the other issue currently preventing connections would be solved as well - assuming both have the same underlying likely cause of systems not yet being properly interconnected again after the recent migration of the beta clusters (and many other things before that) to new infrastructure.

systemd[1]: Started [email protected] - NTP Pool Monitor (test).
ntppool-agent: level=INFO msg="certificate expiring, request renewal" env=test nextCheck=2h0m0s
ntppool-agent: level=INFO msg="load failed" env=test err="unexpected response code: 404 (trace )"
ntppool-agent: Usage: ntppool-agent monitor --env=test [flags]
ntppool-agent: run monitor
ntppool-agent: Flags:
ntppool-agent:  -h, --help                Show context-sensitive help.
ntppool-agent:      --debug               Enable debug logging
ntppool-agent:      --log-level="info"    Log level for stderr (debug, info, warn, error)
ntppool-agent:                            ($MONITOR_LOG_LEVEL)
ntppool-agent:      --state-dir=STRING    Directory for storing state ($MONITOR_STATE_DIR)
ntppool-agent:  -e, --env=test            Deployment environment (prod, test, devel)
ntppool-agent:                            ($DEPLOYMENT_MODE)
ntppool-agent:      --[no-]ipv4           IPv4 monitor (default)
ntppool-agent:      --[no-]ipv6           IPv6 monitor (default)
ntppool-agent:      --once                Only run once instead of forever
ntppool-agent:      --sanity-only         Only run the local sanity check
ntppool-agent: ntppool-agent: error: unexpected response code: 404 (trace )
systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
systemd[1]: [email protected]: Failed with result 'exit-code'.

This seems to affect only the test environment so it’s not the end of the world, but it’s still worth fixing, of course.

level=WARN msg=“failed to reload AppConfig” env=test appconfig-manager.err=“unexpected response code: 404 (trace )”

Other than that message my test monitors seem to be working fine.. Oh, or maybe not, because I also get:

Apr 24 09:29:53 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s
Apr 24 09:31:54 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s
Apr 24 09:33:54 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s
Apr 24 09:35:54 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s
Apr 24 09:37:55 level=INFO msg=“certificate expiring, request renewal” env=test nextCheck=2h0m0s

When the certificate actually expires in around 1h 20m the agent might start having problems communicating. We’ll see. But yes, there are issues, it seems.

openssl x509 -in /var/lib/ntppool-agent/test/cert.pem -text -noout | grep Not
Not Before: Apr 19 11:03:34 2026 GMT
Not After : Apr 24 11:04:04 2026 GMT
date
Fri Apr 24 09:44:01 UTC 2026

Seting-up a new test monitor, sudo journalctl -u ntppool-agent@\* -f gives:

Apr 24 08:44:40 tumbleweed.home ntppool-agent[51010]: level=WARN msg="no API key, please run ntppool-agent setup" env=test cmd="ntppool-agent setup --env test --state-dir '/var/lib/ntppool-agent'" wait_time=4m59s
Apr 24 08:44:43 tumbleweed.home ntppool-agent[51010]: level=WARN msg="failed to refresh JWT token" env=test appconfig-manager.err="no API key available for JWT token request"

and that is normal. However, the next step
sudo -u ntpmon ntppool-agent setup -e test -a 355n9ds
gives a 404 error:

tumbleweed:~ # sudo -u ntpmon ntppool-agent setup -e test -a 355n9ds
time=2026-04-24T08:01:30.440Z level=INFO msg="using hostname for registration" env=test hostname=tumbleweed.home
default backend - 404
tumbleweed:~ #

2. AS8820 82.139.222.46 0.0% 2 14.6 14.0 13.3 14.6 0.9

3. AS5405 45.153.83.146 0.0% 2 13.2 19.0 13.2 24.9 8.3

4. AS5405 94.103.180.66 0.0% 2 13.1 16.6 13.1 20.0 4.9

5. AS5405 94.103.180.75 0.0% 2 15.2 15.1 15.0 15.2 0.2

6. AS5405 94.103.180.54 0.0% 2 13.7 14.3 13.7 14.9 0.9

7. AS2914 199.245.24.156 0.0% 2 14.8 13.9 12.9 14.8 1.3

8. AS2914 129.250.7.43 0.0% 2 13.5 18.1 13.5 22.6 6.4

9. AS2914 129.250.5.33 0.0% 2 218.6 217.1 215.6 218.6 2.1

10. AS2914 129.250.6.6 50.0% 2 102.2 102.2 102.2 102.2 0.0

11. AS2914 129.250.6.1 0.0% 2 173.5 166.2 158.9 173.5 10.4

12. (waiting for reply)

13. AS2914 157.238.231.167 0.0% 2 168.6 168.4 168.1 168.6 0.4

14. AS46375 70.36.205.5 0.0% 2 169.5 169.5 169.5 169.5 0.0

15. AS46375 70.36.205.62 0.0% 2 838.7 838.7 838.7 838.7 0.0

16. (waiting for reply)

17. AS46375 157.131.243.221 0.0% 1 167.0 167.0 167.0 167.0 0.0

18. AS46375 192.184.185.178 0.0% 1 182.5 182.5 182.5 182.5 0.0

19. AS46375 192.184.185.190 0.0% 1 186.2 186.2 186.2 186.2 0.0

20. AS46375 198.27.244.46 0.0% 1 167.0 167.0 167.0 167.0 0.0

21. AS46375 209.148.110.246 0.0% 1 157.7 157.7 157.7 157.7 0.0

22. AS8820 2a01:170:0:10::1 0.0% 4 13.0 17.3 12.7
    22.4 5.2

23. AS3320 2003:0:130e:9::1 25.0% 4 10.7 10.3 9.7
    10.7 0.6

24. AS3320 2003:3c0:1600:800a::1 50.0% 4 116.4 122.9 116.4
    129.4 9.3

25. AS3320 2003:3c0:1600:800a::2 0.0% 4 109.6 113.8 109.6
    121.8 5.8

26. AS2914 2001:418:0:2000::2cd 0.0% 4 125.2 115.9 109.8
    125.2 8.2

27. AS2914 2001:418:0:2000::16e 0.0% 3 118.9 124.8 118.9
    136.0 9.7

28. AS2914 2001:418:0:2000::31f 33.3% 3 137.1 137.5 137.1
    137.9 0.6

29. AS2914 2001:418:0:5000::d69 0.0% 3 132.9 128.4 124.4
    132.9 4.3

30. AS23352 2001:1838:2000:1::34b 0.0% 3 134.7 132.3 126.8
    135.3 4.7

31. AS23352 2001:1838:2000:1::4f 0.0% 3 141.1 133.3 127.5
    141.1 7.0

32. AS23352 2001:1838:2000:41b::80:0 0.0% 3 132.0 130.8 125.2
    135.2 5.1

Dunno if that is a policy or just randomness.

Also, I have used https://bgp.tools a lot for my most common autonomous system neighborhood. As long as hurricane electric isn’t on the way, all peering and ix using seems to be the same. No idea what ISPs do internally, though.

The traffic continued at that rate up to around an hour ago, when my ISP apparently thought my server was under DDoS and null routed its IPv4 traffic. I can kind of understand their thinking. Normally null routing the traffic would also make the pool monitors drop the server from the pool DNS and the traffic would slow down, but as the pool DNS zones are stuck, the ISP will continue receiving tons of traffic (like 6 MB/sec) until this issue gets fixed. The server won’t see this incoming traffic until the ISP drops the null routing, and I won’t be asking the ISP about this until the pool DNS issue is fixed.

Those who have IPv6 can still view that server’s statistics. Apparently this server can handle 70k queries per second at around 85% CPU utilization.

Then there’s the issue of servers not getting promoted/demoted to/from pool DNS in case of new servers, or the server’s time being wildly off, for example. I’m hoping that this issue gets fixed soon.

Marking this issue as solved.

Welcome to the community!

Three aspects to your questions:

• Only 2.pool.ntp.org (and analogue country, region, and vendor zones starting with “2.”) even returns AAAA records, see this lengthy thread. All other numbered and unnumbered zones only return A records.
• There indeed currently is an issue with the zone file not getting updated, i.e., any changes to server configurations, e.g., additions, removals, netspeed changes, … are currently not getting reflected in the DNS. Thus, any of those changes are also not getting reflected in the trafic patterns, e.g., new servers not getting traffic.
• The recent issues noted on the Status page are a bit outdated. They reflect some underlying issue that pops up every now and then. But the current issues, also this one, are likely caused by the currently ongoing migration of the Pool infrastructure away from Equinix Metal to some other infrastructure.

I saw something similar recently, but had the impression it had been going on for a while already, so not sure it was related to 4.1.3, and now I can’t find it anymore to investigate…

I now have three monitors running on 4.1.4 (2x production, 1x test), and so far, all look ok to me…

Is this related to the recent issues noted on the Status page?

The pool is being used by hundreds of millions of systems around the world. It’s the default “time server” for most of the major Linux distributions and many networked appliances

Glad I am not one of them. GPS+PPS, NIST, USNO

marco.davids:

Do you think that the problems with https://manage.beta.grundclock.com/ (as mentioned in my initial post) could be related to the migration?

I believe so. I understood he specifically moved the beta site in the morning Asia time today and had the impression it was working. He now seems aware of the issue, thus I think it likely he’ll look into it after work.

Perhaps @ask is able to provide us with an update?

The DNS data was updated 1 days, 10 hours, 39 minutes ago (current time: 2026-04-23T13:24:01)

I think it is fair to say that by now this is becoming a pretty serious issue.

Let those inclined to shout at the clouds do so, even if from a smartphone through IPv6.

Bas:

Get real!

It’s amusing to read another one of your reality-denying threads this time from the place I am visiting the last few days: the UK residence of two people between the ages of 75 and 80.

They have a fairly basic Internet setup available to anyone in this area, at a cost in the lower end of the UK broadband market, competitive to the largest provider, British Telecom. They chose it based on its low price alone, because they are pensioners and on a fixed retirement income.

It has fully working IPv6. They didn’t know this or care about it because they don/'t know what IPv4 or IPv6 is. I didn’t know there was IPv6 either until I looked just now. My laptop which is a new device in their home, gained a globally-routable IPv6 address when I joined their wifi.

All the devices in their home are using IPv6. They have some Google Nest smart speakers and an Amazon Alexa that they use every day. These are going over IPv6. They also watch TV every day but gave up broadcast TV some time ago, not really through active choice it’s just that they found that they are mostly satisfied by streaming. So all their TV is by an Amazon Fire device which is also using IPv6. If you turn it off, the TV says it has no other signal.

So isn’t it strange how a pair of non-technical pensioners in UK are making full use of what IPv6 has to offer without even knowing or caring, while you are busy telling everyone who will listen how it is doomed and can never work. Clearly their unknowing use in a domestic setting is a real-world use whether you like it or not, so will your argument shift to saying that this somehow doesn’t count?

But then, clearly also server-to-server use of IPv6 is a real-world thing because we see stats from Google and similar about the percentage of such traffic

If your arguments — which we have been subjected to now for more than 5 years — held up then none of the companies involved in providing these elderly people with mass market Internet service would have bothered doing it over IPv6. But they did, as is pretty common amongst such service providers in UK now. Why is that, do you think? Are all of these companies stupid and just not seeing your wisdom of “IPv6 doesn’t work and never will”? Or could it possibly be the case that you are mistaken and they do it because it does actually reduce their costs?

The nature of my job means I am often in other people’s homes. This year it will be around 20% of the year spent in other people’s homes. Most of the time when I get on their wifi, IPv6 comes up. That means those people, their phones and most of their other devices, are having the majority of their traffic (by byte count) go over IPv6 without them even knowing.

It is by now usual to read your messages and leave feeling that we live in very different realities. This thread just makes that even more explicit. I do not doubt that IPv6 isn’t there for you at home, and not there for you as a concept, but it’s all around you and still you continue to deny it. I fully expect you will still be denying it when Google reports 60%, 75%, 90% going over IPv6. I expect you will continue shifting goals to things like, “does this device come with no IPv4 at all? No? IPv4 is perfectly adequate then!”

As the reality-based community (now featuring 75 year-olds in UK!) recedes into the distance in your rear view mirror, try to enjoy the ride but please stop telling us that our sky must be the same colour as yours.

marco.davids:

Meanwhile around 59% of the servers in the NTP pool are reachable via IPv6.

The more interesting statistic would be load balance in total. I mean, I have a IPv6 only server, but it has only 6 mb/s configured, since it is a on a customer connection and only a small router.

I wonder how much traffic comes to IPv4 servers and how much to IPv6, regardless how many servers we have. I would expect 4:1 because IPv4 adresses are distributed more often. Adding one dns point (3.pool.ntp.org) would mean doubling the traffic. Therefore I would like to know the summarized bandwith configured for IPv4 and IPv6 to have an idea about the future load sharing.

Wanting something is something different then how it works…and IPv4 work, IPv6 doesn’t.

Bullshit, as many people told you. The traffic statistics from certain
IX can show you that, but I assume you will not care.

Ask companies, I can tell you now, nobody cares about IPv6…they just add it, hope it’s a bonus.

Get real!

Get real and accept the fact that various ISPs provide it to their
customers. Some managers and controllers supported that and still do,
otherwise they would have stopped.

It might be hard, but the nonsense of an old man from Belgium will not
stop those companies.

Bas:

Get real, tell me how many companies profit from IPv6 over IPv4…I can tell you 0.0%

Simply no. Public IPv4 adresses costs you money, IPv6 comes for free. There are server parks which have IPv6 only internally and only a IPv4 gateway for legacy.

It might not be the time for IPv6 only, but the time for IPv4 only is over by a decade. This point of view is stuck in time, which is ironically here

Why is this offtopic? I just solved the IPv4 Internet problem of not have enough addresses.
And why IPv6 is not needed.

Why invent the wheel again when the current wheel needs no improvement, just some minor tweaks to get it into the future.

Minor tweaks are not different to reinventing it at all, as they require
all clients and servers to be changed. That will not happen fast and the
implementations will be incompatible.

I understand that many do not understand this. IPv6 will never take over, as the costs are too high and IPv4 simply works. And will keep working the next 50 years. By then IPv6 will have died.

You can not force people/companies into something that costs a lot while there is no ROI.
That is the problem of IPv6, it makes no sense, it’s complicated and IPv4 just works.

Several large ISPs provide IPv6 to their customers to reduce load on NAT
machines. There was a talk at a RIPE conference about the costs of
implementing or not implementing IPv6, for this company it was cheaper
to implement IPv6.

Would you invest in something new that has 0% impact. No and neither do ISP’s and companies.

It seems you have no experience with ISPs that do CGNAT. Otherwise you
might have noticed that they are overloaded in the afternoon.

As such IPv6 is dead end unless they switch off IPv4 instantly…do you really think they will? Answer: NO!

The internet will not move to IPv6 as long as IPv4 works. It’s that simple. Deal with it.
Then why you complain that hard? It must be a serious issue for you that
the reality does not comply to your predictions.

Please answer me this question? It could simply request (on the same port) are you NTP or NTPS server, then answer and make the connection, while the port is irrelevant.

You don’t seem to know the portmap or the tcpmux protocols. They
implement such a server, but both client and server need to support it,
which isn’t the case for NTP/NTPS.

Is this so hard to understand? Ports need to be free, DNS records should show the port. Yet they don’t.

The rest of the world doesn’t care if an old man from Belgium complains
about IPv6 being so, so bad and wanting to reimplement DNS instead,
which will take another 20+ years to have all machines upgraded. Other
legacy-loving people will also refuse and tell that the new DNS is
really, really bad.

MagicNTP:

With the changes you are proposing, regardless of whether one agrees with them or not, you are barking up the wrong tree in this forum. You need to go to the IETF with your ideas, those are the ones that could make the changes that you desire happen.

The point is simple…companies invest only in stuff that helps them forward. IPv6 brings nothing to them.
I do not care if they see it my way or not. At the moment IPv6 brings nothing, can’t even work without IPv6.

On top, IPv6 only websites make no money.

So why would anybody move to IPv6?

Get real, tell me how many companies profit from IPv6 over IPv4…I can tell you 0.0%

Wanting something is something different then how it works…and IPv4 work, IPv6 doesn’t.

Ask companies, I can tell you now, nobody cares about IPv6…they just add it, hope it’s a bonus.

Get real!

Bas:

what is the point of having 2 internet’s where IPv4 just works and IPv6 doesn’t.

If that is truly your firm conviction, why not start a new thread where you strongly advocate for phasing out all 2,250 IPv6-enabled servers in the NTP pool instead?

It would certainly simplify quite a bit of backend complexity if that direction were taken seriously.

Bas:

I’m still waiting why I’m wrong

Whether you’re right or wrong is completely besides the point. As @marco.davids wrote:

With the changes you are proposing, regardless of whether one agrees with them or not, you are barking up the wrong tree in this forum. As @avij writes:

You need to go to the IETF with your ideas, those are the ones that could make the changes that you desire happen.

IPv6 will never make it the way it is now, what is the point of having 2 internet’s where IPv4 just works and IPv6 doesn’t.

That is the issue. I keep saying, companies do not switch or spend money on something that have no ROI. You do not get this part do you?

Interesting, that page has a link at the bottom that leads to nowhere.

As every IP has 65534 ports to use.

I know from many servers, they stupidly switch ports, yet accept the requests.

Why is https 443 and http 80? Please explain me that.

Why is email acceperted on ALL ports but switches just because it’s SSL / TLS / 25?

It makes no sense. Why is NTP 123, but NTPS ???

It’s so stupid, and you are in the hart of DNS, why can’t DNS use ports?

Answer me this…as that is a major problem. Not resolved…not even today.

Bas:

Yeah I know…

Do you?

Because it doesn’t feel that way.

This topic is only about one narrow operational aspect of IPv6: adding more AAAA records in the DNS of the NTP pool, alongside the single existing one at 2.pool.ntp.org. Nothing more, nothing less. It’s not about replacing A records, just gradually introducing AAAA records next to them.

This has been explained multiple times already. I’m not sure whether the scope is being misunderstood or ignored, but the result is the same.

I’m starting to get the impression that this is less about the technical proposal itself and more about what feels like a deliberate effort to derail the discussion into unrelated topics.

IPv6 is a dead-end, it will never take over. Not the way it is now. As companies to NOT embrace it.

For them IPv4 works, so they do not spend money on IPv6. It’s money…unless you pay companies to move to IPv6, it will not happen.

Not now, not over 50 years. There is no discussion as long a companies don’t use it.