That’s not a problem with IPv6, but with nslookup. DNS servers resolve whatever query they get, no more.
1 Like
Seems like you’re doing something wrong, it works fine for me 
max@test:~$ nslookup ntp.heppen.be
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 2001:41d0:303:1585::718e:a506
Name: ntp.heppen.be
Address: 2a00:7b80:477:21::9dcb:d174
Name: ntp.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
Name: ntp.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
max@test:~$ nslookup ntp.heppen.be 192.168.1.2
Server: 192.168.1.2
Address: 192.168.1.2#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 2001:41d0:303:1585::718e:a506
Name: ntp.heppen.be
Address: 2a00:7b80:477:21::9dcb:d174
Name: ntp.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
Name: ntp.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
Nope, not doing anything wrong.
Just look:
bas@workstation:~$ nslookup ntp.heppen.be
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 2a00:7b80:477:21::9dcb:d174
Name: ntp.heppen.be
Address: 2001:41d0:303:1585::718e:a506
Name: ntp.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
Name: ntp.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
bas@workstation:~$ nslookup ntp.heppen.be 192.168.1.1 <==Fritzbox!!!
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 212.187.8.48
The router is still not IPv6 ready…this is a modern Friztbox 7590, and the Firmware Labor less then a week old.
If I run:
bas@workstation:~$ nslookup ntp.heppen.be 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
Name: ntp.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
Name: ntp.heppen.be
Address: 2a00:7b80:477:21::9dcb:d174
Name: ntp.heppen.be
Address: 2001:41d0:303:1585::718e:a506
Stupid part is, the DNS 1.1.1.1 is the DNS-server the Fritzbox should use.
And yes the Fritzbox is IPv6 enabled but not as primary protocol.
Yet it does not resolve the way it should.
Not my fault. Implemetation of it is not ready or not working as should.
2022…and a modern router does not handle it properly.
I did wrote them about this many times, and gave up.
Rather, be more specific on the query type, such as in:
nslookup -type=AAAA ntp.heppen.be 192.168.1.1
I don’t know how your router works, but you mentioned that it was set up to use the DNS server 1.1.1.1. Perhaps it won’t return the result for the IPv6 address unless it has such a DNS configured as well. For Cloudflare, that would be 2606:4700:4700::1111.
Still, your exercise is not indicative of the state of IPv6, just of the gear you use.
The fact is that both your IPv6 and IPv4 servers have such clients. So I fail to understand your frustration as being objective.
2 Likes
(post deleted by author)
Bas,
Do you have ‘DNS Rebind Protection’-options enabled in your Fritz!Box that are causing this? Try adding ‘ntp.heppen.be’ there.
I too have a Fritz!Box (model 6690 with the latest firmware image 7.39-101543 BETA installed) and ‘nslookup ntp.heppen.be 192.168.1.1’ works just fine here.
No Rebound protection here.
Look what happens, BTW this is FritzOS 07.50 and it fails, as usual:
bas@workstation:~$ nslookup -type=AAA ntp.heppen.be 192.168.1.1
unknown query type: AAA
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 212.187.8.48
bas@workstation:~$ nslookup -type=AAA ntp.heppen.be
unknown query type: AAA
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 77.109.90.72
bas@workstation:~$ nslookup -type=AAAA ntp.heppen.be 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 2001:41d0:303:1585::718e:a506
Name: ntp.heppen.be
Address: 2a00:7b80:477:21::9dcb:d174
Name: ntp.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
Name: ntp.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
bas@workstation:~$ nslookup ntp.heppen.be 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 212.187.8.48
Ipv6 is a mess, it should not happen, period. Sorry but I hate this protocol by now.
Yes I server IPv6 users, but I do not care about Ipv6 anymore as it’s useless and designed by some idiot that has no brains.
Funny is ebahapo is telling me to use AAAA while it’s AAA…that tells it all.
Do you read the output of your command-line tools? nslookup is telling you that the record type AAA is unknown.
A good craftsman never blames his tools… or those trying to help. 
4 Likes
I don’t want to further the big debate, just a question: is this likely to happen at any time in the near future? We were planning to deploy 10 NTP pool servers in the next few months. However, now that the price of IPv4 addresses has surpassed $50 each on the open market, we’re using public IPv4 only for critical services, and an NTP pool server doesn’t qualify as “critical”. I’m also not willing to spend an additional $500 just to provide free services. So if we do this, it’ll be IPv6 only.
With IPv6 being so limited in the pool, it doesn’t seem like it’s worthwhile for us to bother right now. When would be a good time to check back and see if this policy changes? Second half of 2023 or more likely 2024? Thanks!
1 Like
FYI, I have a US Pool server. Its IPv4 IP is set to 250 Mbps and its IPv6 IP is set to 1000 Mbps. In the last week, it got 232 million IPv6 queries and 1.674 billion IPv4 queries.
Different countries and continents will have different numbers.
My IPv6 servers receive less traffic, but they’re not useless.
Some OSes ship a default configuration with e.g. “pool 2.<vendor>.pool.ntp.org”, so they can treat IPv4 and IPv6 equally.
Hi Marco,
I did that, it makes no difference:
bas@workstation:~$ nslookup ntp.heppen.be
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 77.109.90.72
bas@workstation:~$ nslookup ntp.heppen.be 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 5.196.189.119
bas@workstation:~$ nslookup ntp.heppen.be 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: ntp.heppen.be
Address: 5.196.189.119
Name: ntp.heppen.be
Address: 89.207.129.63
Name: ntp.heppen.be
Address: 77.109.90.72
Name: ntp.heppen.be
Address: 212.187.8.48
Name: ntp.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
Name: ntp.heppen.be
Address: 2001:41d0:303:1585::718e:a506
Name: ntp.heppen.be
Address: 2a00:7b80:477:21::9dcb:d174
Name: ntp.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
It simply doesn’t resolve IPv6 by default, and you can’t change it one bit.
bas@workstation:~$ nslookup ntp1.heppen.be 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: ntp1.heppen.be
Address: 77.109.90.72
bas@workstation:~$ nslookup ntp1.heppen.be 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: ntp1.heppen.be
Address: 77.109.90.72
Name: ntp1.heppen.be
Address: 2a02:578:440e:0:aaa1:59ff:fe3d:5b53
Unless you ask a server that has no IPv4 resolving, then it does deliver nothing:
bas@workstation:~$ nslookup ntp5.heppen.be 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
*** Can't find ntp5.heppen.be: No answer
I use FritzOS 07.50, and have a native IPv6 connection and all DNS servers are tested from ISP(automatic) or set manual from 1.1.1.1 (and IPv6 counterparts), it does not resolve IPv6.
IPv6 is supported by the pool, as I provide a few IPv6 servers also.
The thing is, the majority of clients use IPv4 by default.
That is not a problem of the pool, as it does supply IPv6, but it doesn’t work for everybody when reolving like my examples show. My modem should be state of the art, IPv6 enabled, yet it doesn’t reolve IPv6 properly.
Sure it will change somewhere, but nobody can tell.
It would be interesting to know if it is your modem that is doing this, or the resolver that it is talking to (because after all your Fritz!Box is only some sort of DNS forwarder)
You can figure out what the resolvers are in your Fritz!Box dashboard under ‘internet’ (http://fritz.box/#netMoni). You can also query the IP-addresses shown there directly, bypassing your modem, to figure out if the problem is with your resolver instead of your modem.
What happens when you try this?
nslookup example.nl
nslookup example.nl 1.1.1.1
That’s good to know. I might try adding another test pool server in IPv6-only mode to see if it adds anything to the pool or just ends up without significant utilization. I’m really interested to see the metrics.
That is very much a pool problem. Windows has used IPv6 by default for 16 years, Apple has required all app developers to support IPv6 only networks since 2016. T-Mobile switched to an IPv6 only mobile network a few years ago. Only users that configure more than 2 pool servers will have any chance to use IPv6.
But it doesn’t break when DNS returns both A and AAAA records I’m assuming. If it did, you wouldn’t be able to reach Google or most other large internet services.
–
For what it’s worth, I checked with our networking people this morning. We had some systems with time synchronization problems because they could only use 2.pool.ntp.org and ended up synchronizing to only one NTP server. So we put the pool on the HBP list (Horribly Broken - Prohibit). We’ve been blocking *.pool.ntp.org at the DNS and firewall and redirecting to time.cloudflare.com instead to fix the time sync problems we were experiencing.
1 Like
If they run Chrony or ntpd, configuring “pool 2.pool.ntp.org” will choose multiple servers. But that’s a big “if”. 
(I don’t want to derail this thread, but I wish I knew how BusyBox ntpd worked, for example…)
1 Like
https://git.busybox.net/busybox/tree/networking/ntpd.c
//config:config FEATURE_NTPD_CONF
//config: bool "Make ntpd understand /etc/ntp.conf"
//config: default y
//config: depends on NTPD
//config: help
//config: Make ntpd look in /etc/ntp.conf for peers. Only "server address"
//config: is supported.
It looks like that BusyBox do not support pool directive. But I have no idea if BusyBox utilizes multiple server when it resolves single server line with multiple IP address reply.
It’s very possible (though not certain) the time sync problem was an issue with embedded IoT sytems, many of which need IPv6 for direct internet connectivity. I’m still trying to track down the details from someone who did the actual debugging. It was a few years ago, and was a huge issue given the size of the remediation budget for the time sync issue.
That would be interesting to know. It would make sense if it took one IP from each of the 4 pool addresses, and ended up with just one IPv6 from 2.pool.ntp.org, which is not good. pool.ntp.org is IPv4 only, so the issue would have been discovered immediately. That’s actually the reason the pool ended up on the “horribly broken” list. Not because of lack of IPv6 compatibility, but because the 4 hostnames return inconsistent and unexpected results. Dropping the AAA record on 2.pool would be better, though overall not good.
BTW, we do have IPv4 connectivity, but only over a tunnel to our 464XLAT gateway, and it’s mostly for legacy clients and websites that still need IPv4. Ports 123 and 4460 aren’t open on the gateway.
Dag Marco,
Internet, IPv4
verbonden sinds 01-12-2022, 14:11 uur, edpnet
IPv4-adres: 77.109.90.72
Internet, IPv6
verbonden sinds 01-12-2022, 14:11 uur, edpnet
IPv6-adres: 2a02:578:8401:dc00:464e:6dff:fefa:37bf/64, Geldigheid: 3079/3079s
IPv6-prefix: 2a02:578:440e::/48, Geldigheid: 2438496/451296s
Gebruikte DNS-servers
1.1.1.1
8.8.8.8
2606:4700:4700::1111 (momenteel gebruikt voor standaard aanvragen)
2001:4860:4860::8888
Dat zijn de gegevens in het modem.
bas@workstation:~$ nslookup example.nl
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: example.nl
Address: 94.198.159.35
Name: example.nl
Address: 2a00:d78:0:712:94:198:159:35
bas@workstation:~$ nslookup example.nl 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: example.nl
Address: 94.198.159.35
Name: example.nl
Address: 2a00:d78:0:712:94:198:159:35
bas@workstation:~$ nslookup example.nl 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: example.nl
Address: 94.198.159.35
Name: example.nl
Address: 2a00:d78:0:712:94:198:159:35
Waarom doet je test het wel, maar mijn eigen DNS niet?
bas@workstation:~$ nslookup ntp5.heppen.be
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: ntp5.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
bas@workstation:~$ nslookup ntp5.heppen.be 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
*** Can't find ntp5.heppen.be: No answer
Dat bedoel ik, waarom is IPv6 zo moeilijk? Dit is maar een stomme DNS aanvraag.
Blijkbaar kan die remote wel resolven, maar in het eigen netwerk niet, ondanks dat de DNS het juist moet geven.
Bij IPv4 queries is er geen enkel probleem, enkel bij IPv6.
Could you enable some debugging, please? Similarly as I did:
pi@raspberrypi:~ $ nslookup - 192.168.1.1
> set debug
> ntp5.heppen.be.
Server: 192.168.1.1
Address: 192.168.1.1#53
------------
QUESTIONS:
ntp5.heppen.be, type = A, class = IN
ANSWERS:
AUTHORITY RECORDS:
-> heppen.be
origin = ns.heppen.be
mail addr = hostmaster.ns.heppen.be
serial = 2022120901
refresh = 10800
retry = 3600
expire = 604800
minimum = 3600
ttl = 3351
ADDITIONAL RECORDS:
------------
Non-authoritative answer:
------------
QUESTIONS:
ntp5.heppen.be, type = AAAA, class = IN
ANSWERS:
-> ntp5.heppen.be
has AAAA address 2a02:578:440e:0:5f05:fa04:1720:d90f
ttl = 3351
AUTHORITY RECORDS:
ADDITIONAL RECORDS:
------------
Name: ntp5.heppen.be
Address: 2a02:578:440e:0:5f05:fa04:1720:d90f
>
pi@raspberrypi:~ $
1 Like