 |
Looks like the failure is limited to when the unbound resolver is locally installed and used. |
 |
We've had some intermittent reports of this but have not been able to nail down a root cause. How is your IPv6 traffic handled? Is it a direct allocation, or via a 646 tunnel broker like HE.net? Do you have any firewall rules on your network that would be preventing ICMP6 and/or PMTU traffic from flowing? |
|
|
It's an IPv6 only host in a datacentre (specifically Hetzner in DE). IPv6 works if the DNS points at a Mikrotik router. As soon as DNS is changed to point at a locally installed copy of the unbound nameserver, we fail. Looking at https://dnssec-analyzer.verisignlabs.com/mirrors.rockylinux.org it seems fastly fails DNSSEC checks. I wonder if resolvers are interpreting this as "DNS name not configured securely, pretend it does not exist". |
|
|
Thanks for the info, that's helpful. Let me reach out to Fastly and see if they have some thoughts here. DNSSEC is an ongoing project for us as an infrastructure team, too, but I'm not able to give an ETA at this time. |
|
|
In theory DNSSEC missing isn't an error, but if DNSSEC is misconfigured then resolution attempts will throw an error. Very odd that a CDN doesn't do DNSSEC. |
|
|
We have also been working on an ipv6 only network and had this problem on all of our rockylinux installations. We were running Nat64 with ipv6 on the inside and only ipv4 on the external network connection. By simply using the "-6" parameter with dnf, we succesfully updated without any further issues. I.E. "dnf -6 update" Hope this helps someone. |
- Anonymous
