I get the impression that the pool DNS zones are currently “stuck”. Servers with a score less than 10 may still be included in the pool DNS if their score has dropped only recently below 10, and I’d imagine the reverse is also true, ie. newly added servers won’t be included in the pool DNS even if their score increases to over 10.
Evidence: My server 95.111.202.5 is included in the cn DNS even though the last time its score was above 10 was at 2026-04-22 07:10:23 UTC (around 8 hours ago as of now).
I also noticed some strange changes in traffic patterns these recent days, which might be due to the same reason: servers not getting moved in and out of zones as they should be.
E.g., a server in the HK and TW zones that always sees most traffic geolocated to China, but at a reasonable level (> 10Mbit/s), and manageable via the netspeed setting, suddenly saw 5 minute average peaks above 100Mbit/s even at the smallest allowed non-zero netspeed setting in the last few days. Apart from that overloading the single core machine, I had to drastically throttle incoming traffic not use up the remainder of my monthly traffic quota in a few days (and temporarily put the server in monitoring-only whenever things were getting out of hand). Now, it seems back to normal, though, i.e., I will slowly increase the netspeed again from the current setting of 512kbit.
I set the netspeed to a value that usually would kill the server a few minutes ago, and indeed no change whatsoever so far, thus unfortunately not proving you wrong . But there also is a strong diurnal pattern in those zones, with this currently being the quieter part of the day over there. So I’ll set it back down now, and then try again in the morning our time so I can control the traffic in case things start getting out of hand again (though I would still have expected some change at least… ).
Ask is currently still in the process of migrating functionality from Equinix Metal to new infrastructure, hoping to be done with the cluster migrations this week or next. I guess at least some of the various infrastructure-related issues seen these days might be due to those activities.
There is a PR to have that removed. But I’ll also try to see whether I can figure out where this was intended to go, maybe that function can be restored, and the link re-added accordingly.
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
The example server of mine that I linked to in the first message sends normally around 165 GB of NTP traffic each day. Yesterday that total figure was 404 GB. At that rate I’ll burn through my monthly traffic quota very quickly. Normally that server’s netspeed setting is 100 Mbit/s but I decreased it to 512 Kbit/s when I ran into this issue. Sadly that setting has no effect at this moment.
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.
. But there also is a strong diurnal pattern in those zones, with this currently being the quieter part of the day over there. So I’ll set it back down now, and then try again in the morning our time so I can control the traffic in case things start getting out of hand again (though I would still have expected some change at least… 
).
