FS#79295 - [chrony] "pool 2.arch.pool.ntp.org" does not make sense

Attached to Project: Arch Linux
Opened by Mingye Wang (arthur2e5) - Friday, 04 August 2023, 08:40 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:19 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
The PKGBUILD currently puts "pool 2.arch.pool.ntp.org" in the example files. This should be just "pool arch.pool.ntp.org", because adding a number defeats the whole point of the "pool" directive.

The other substitutions are acceptable.

Steps to reproduce:
Just read https://gitlab.archlinux.org/archlinux/packaging/packages/chrony/-/blob/main/PKGBUILD.
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:19 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/chrony/issues/2
Comment by Toolybird (Toolybird) - Friday, 04 August 2023, 23:35 GMT
They all seem to resolve slightly differently, so there might be a good reason why it was done that way. In fact, 2.arch.pool.ntp.org is the only one that supports IPv6 so I'm guessing that's it.
Comment by Mingye Wang (arthur2e5) - Tuesday, 08 August 2023, 09:44 GMT
  • Field changed: Percent Complete (100% → 0%)
No, this is not how pool.ntp.org works. The pool's DNS server picks a random IP to give you. Whether it supports IPv6 is completely luck-based -- a combination of what's in your carrier's cache and what phase the moon is in when your carrier's NS did the recursion.

You could run `dig @a.root-servers.net hostname AAAA arch.pool.ntp.org` and try to recurse down any of the many nameservers assigned to ntp.org returned. Then hammer the returned nameserver with `dig @199.19.53.1 hostname AAAA {{0..3}.,}arch.pool.ntp.org` to see what resolving each gives. The answer is nothing different.

Comment by loqs (loqs) - Tuesday, 08 August 2023, 15:35 GMT
>You could run `dig @a.root-servers.net hostname AAAA arch.pool.ntp.org` and try to recurse down any of the many nameservers assigned to ntp.org returned. Then hammer the returned nameserver with `dig @199.19.53.1 hostname AAAA {{0..3}.,}arch.pool.ntp.org` to see what resolving each gives. The answer is nothing different.
If instead you use:
$ dig AAAA @1.1.1.1 {{0..3}.,}arch.pool.ntp.org # cloudflare
$ dig AAAA @9.9.9.9 {{0..3}.,}arch.pool.ntp.org # quad9
$ dig AAAA @8.8.8.8 {{0..3}.,}arch.pool.ntp.org # google
Do you not receive 4 AAAA records for 2.arch.pool.ntp.org and 0 AAAA records for 0,1 and 3? I suspect the root server is only providing A records on its IPV4 address and you would need to use its IPV6 address for AAAA records.
Can you obtain an AAAA record from the root server on its IPV4 for any query?

Loading...