Hello there,
I am having some problems with 1.1.1.1 and resolving PTR records below 8.5.4.1.1.0.0.2.ip6.arpa
Example:
$ dig @2606:4700:4700::1111 -x 2001:1458:d00:18::1c2 +short
$ dig @1.1.1.1 -x 2001:1458:d00:18::1c2 +short
$ dig -x 2001:1458:d00:18::1c2 +short
aiadm04.cern.ch.
I’m hitting the following Cloudflare endpoints if that may help:
$ dig @2606:4700:4700::1111 CH TXT id.server +short
"FRA"
$ dig @1.1.1.1 CH TXT id.server +short
"GVA"
Note: I tried to use the purge-cache feature for the reverse zone… but it didn’t really help
This is causing some problems to some of our clients (specifically kerberos libraries)
Thanks for your help !
1 Like
cs-cf
April 20, 2020, 3:02pm
2
Opened an internal ticket… looks like there might be some issues with delegation and/or DNSSEC which are causing the failure but our team will take a look.
https://dnsviz.net/d/2.c.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.1.0.0.0.0.d.0.8.5.4.1.1.0.0.2.ip6.arpa/dnssec/
2 Likes
alexx
April 23, 2020, 9:45am
3
Hi @cs-cf , do you have an update on this?
Hi, the zone has a resolution loop in it so it’s not always going to resolve correctly:
$ kdig @tinnie.arin.net. 8.5.4.1.1.0.0.2.ip6.arpa NS
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 47661
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 2; ADDITIONAL: 2
;; QUESTION SECTION:
;; 8.5.4.1.1.0.0.2.ip6.arpa. IN NS
;; AUTHORITY SECTION:
8.5.4.1.1.0.0.2.ip6.arpa. 172800 IN NS ext-dns-2.cern.ch.
8.5.4.1.1.0.0.2.ip6.arpa. 172800 IN NS ns.ripe.net.
;; ADDITIONAL SECTION:
ns.ripe.net. 3600 IN AAAA 2001:67c:e0::6
ns.ripe.net. 3600 IN A 193.0.9.6
When asked it returns a referral to itself but with a different address:
$ kdig @ns.ripe.net 8.5.4.1.1.0.0.2.ip6.arpa NS
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 57741
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 2; ADDITIONAL: 0
;; QUESTION SECTION:
;; 8.5.4.1.1.0.0.2.ip6.arpa. IN NS
;; AUTHORITY SECTION:
8.5.4.1.1.0.0.2.ip6.arpa. 172800 IN NS ns.ripe.net.
8.5.4.1.1.0.0.2.ip6.arpa. 172800 IN NS ext-dns-2.cern.ch.
The resolver will sometimes try one or another, so if you’re unlucky it will try to resolve ns.ripe.net again and realize there’s no way forward. I’ll try to add a workaround if possibl. If you have a contact for the zone owner who could get this fixed that would be excellent.
1 Like
Hi !
Thanks for the explanation, I’ve contacted the zone owner, hopefully they’ll get this fixed soon
Thank you for your help, I’ll update the thread when it has been fixed.
Hello,
We’ve contacted the zone owner and they managed to get their configuration fixed and as far as I can tell, resolution of this ip6.arpa zone now works as expected.
Thank you for your help in troubleshooting the issue !
I can confirm this is fixed now. Thanks a lot!
