CloudFlare now opens their time service,
time.cloudflare.com, without leap smearing.
It also referenced Network Time Security (NTS), a proposed TLS layer for NTPv4 protocol.
CloudFlare now opens their time service,
Hmm, someone added them to the Pool.
The IPv4 IPs are in the TH zone and the IPv6 IPs are in the US zone.
Can y’all and Cloudflare work on that? Does the Pool software support adding anycast IPs to scores of different country zones?
(Were they even added with permission?)
All four IPs probably point to shared infrastructure; it might be better to have only one IPv4 IP and one IPv6 IP in the pool.
I compared their time on two of my servers and I was seeing a constant offset of ~2ms compared to my other sources…
This, despite only a 0.867 ms ping time, traveling from Houston, TX to Monroe, LA on Level-3 (without having to change networks, obviously)…
I forgot location from my other server, ping time was about 27ms, same ~2ms offset…
Anyone else have any numbers to report?
Largely good news for me so far, including in Dallas.
Oddly, my ntpd clients use a poll interval of no more than 64 seconds for time.cloudflare.com.
The ping time from my location (Germany, ~40miles from Hannover) is about 7.6ms with a consant offset of ~1ms.
NTP delay is ~ 7ms
And yes, the poll isn’t going over 64
220.127.116.11 10.48.8.4 3 u 31 64 377 7.556 0.981 1.919
@mlichvar figured out what’s going on with the poll interval.
In its responses, Cloudflare is setting the poll field to 0. This seems to cause ntpd clients to set the poll interval as close to 2⁰ seconds as
minpoll allows it to.
(ntpd servers echo back whatever poll value the client sent in its query.)
He said that the RFC doesn’t specify what the response’s poll value should be, so what Cloudflare’s doing is legal.
He told Cloudflare about the issue.
server 2606:4700:f1::123, stratum 3, offset 0.000139, delay 0.02728
server 2606:4700:f1::1, stratum 3, offset 0.000009, delay 0.02734
server 18.104.22.168, stratum 3, offset 0.000264, delay 0.02760
server 22.214.171.124, stratum 3, offset -0.000010, delay 0.02794
24 Jun 09:13:47 ntpdate: adjust time server 2606:4700:f1::123 offset 0.00 0139 sec
server 2606:4700:f1::123, stratum 3, offset 0.001710, delay 0.03903
server 2606:4700:f1::1, stratum 3, offset 0.001594, delay 0.03889
server 126.96.36.199, stratum 3, offset -0.003170, delay 0.03923
server 188.8.131.52, stratum 3, offset -0.003142, delay 0.03995
24 Jun 09:58:01 ntpdate: adjust time server 2606:4700:f1::1 offset 0.001594 sec
server 2606:4700:f1::1, stratum 3, offset -0.004195, delay 0.02679
server 2606:4700:f1::123, stratum 3, offset -0.004477, delay 0.02739
server 184.108.40.206, stratum 3, offset -0.004502, delay 0.02716
server 220.127.116.11, stratum 3, offset -0.004467, delay 0.02713
24 Jun 10:00:10 ntpdate: adjust time server 2606:4700:f1::1 offset -0.004195 sec
server 2606:4700:f1::1, stratum 3, offset -0.004521, delay 0.02701
server 2606:4700:f1::123, stratum 3, offset -0.004786, delay 0.02748
server 18.104.22.168, stratum 3, offset -0.004602, delay 0.02679
server 22.214.171.124, stratum 3, offset -0.004527, delay 0.02666
24 Jun 10:01:53 ntpdate: adjust time server 126.96.36.199 offset -0.004527 sec
The larger difference on the two Hong Kong servers is probably because they are OpenVZ while the other two are KVM, and I don’t know where that host syncs to. tick.nj.logiplex.net is realtime scheduled.
No, and they’ve been disabled again (some hours ago) at the request of Cloudflare. (You can thank the users doing this sort of thing when you have to go through some verification step to add a server …).
Oh. I hope they’re added back with permission.
Personally, I think that the Cloudflare servers should be kept as monitoring only just like the time servers of most large networks like Apple, Google, Microsoft, etc.
If Cloudflare wanted to put them in the Pool, why not?
By the way, at least one of Apple’s IPs is in the pool for real:
I suppose that it’s fine if they wanted them in the pool but at the moment it appears that they do not
Now that 188.8.131.52 and 184.108.40.206 (and their IPv6 counterparts) are in the pool again, and with a lot of zones binding. So it is intended and authorized this time?
Hi @alica, I’ve not been involved but from what I can see on the management pages I would be reasonably confident that they are legit.