The following NTP servers in the Philippines don’t work, even though their scores are higher than 10.
222.127.1.19 ~ 27
When we resolve “pool.ntp.org,” the resolved address is one of the addresses above, so we can’t use “pool.ntp.org” now.
This issue is similar to the one discussed in this thread:
However, the IP addresses are different, so I believe this is a separate problem and created a new topic. I’m sorry if I should have used the old thread.
From here, the details of the issue:
Using ntpdate, these servers don’t respond even with a 10-second timeout.
$ ntpdate -qv -t10 222.127.1.19
28 Jun 12:17:43 ntpdate[30485]: ntpdate 4.2.8p15@1.3728-o Wed Feb 16 17:13:02 UTC 2022 (1)
28 Jun 12:17:53 ntpdate[30485]: no server suitable for synchronization found
This site reported these servers as “Error; Timeout.”
On the other hand, these sites report those servers as OK:
It appears that these servers work for only a limited number of clients, not for everyone.
I think these servers should be deleted soon, otherwise people in the Philippines can’t use pool.ntp.org.
I ran a series of traceroutes and suspect there is intentional blockage by AS4775. The blockage is specific to NTP (UDP port 123) and depends on the NTP request source address.
"In the Philippines, we consistently receive four addresses ranging from “222.127.1.18 to 222.127.1.27” for NTP servers. The current situation indicates that servers with the same administrator, configuration, and location are being selected. As a result, access restrictions imposed by server or network administrators, whether intentional or unintentional, are impacting all servers.
Is it not possible to implement a method that allows for the inclusion of NTP servers from different environments? For instance, could we consider selecting one or two addresses from a higher-level domain, such as “asia.pool.ntp.org,” among the four addresses returned by DNS?"
That is my suggestion also. Addresses from 222.127.1.18 to 222.127.1.27 are all known to be advertised by AS4775, GLOBE-TELECOM-AS Globe Telecoms, PH. This can be quickly and easily programmatically determined.
The pool DNS server could decide to ensure that IPs from at least two or three different ASNs are returned, by expanding the scope of where it will draw IPs from (only) if necessary.
Returning four IPs from a single ASN risks a shared bad fate for all of them.
Based on my understanding, each server.Loc has an API called GetASN(), and comparing ASNs should not be difficult. Another idea is to use distance. If all distances are almost the same, it might be safer to select another server.