Question: No IPv6 responds from server wurzn.hagezi.org - normal behavior or some issues?

[pictosun]

Hi there,

looks like there is no IPv6 DNS answers from wurzn.hagezi.org.

Any idea why?

[DNSBunker]

IPv6 works.
@hagezi consider using stale ttl of 3600s and client timeout of 250 instead of 0!

86400 and 0 are not suitable for public dns with very frequent requests.

[hagezi]

I can't reproduce this. If you query AAAA, you get a response with the IPv6 address. If you mean the DNS servers displayed at dnscheck.tools, only the DNS servers used internally by Technitium are displayed there. Wurz and Juuri prefer resolution via IPv4 against the root servers. However, this does not change the IPv6 resolution of domains, which works.

[pictosun]

See here.
Same with browserleaks.com/dns check.

The other time it worked without any issues and I got an IPv4 and IPv6 address.

[DNSBunker]

@pictosun like @hagezi said, this does not mean you don't get AAAA records.
These tools are checking if the resolver uses ipv6 to ask a Nameserver for records. This is not mandatory and you can ignore this fancy red text.

[pictosun]

Thanks - haven't seen his response before sending my post.

Appreciate your direct help and response.

[hagezi]

I already explained that you're comparing apples and oranges. The client can connect to the DNS via IPv4 and IPv6 and can resolve both A and AAAA domains. Regardless of whether only IPv4 is used internally for resolution against the root servers. This is exactly what Browserleaks and dnscheck.tools show, the DNS servers that are used internally for resolution.

[DNSBunker]

@pictosun since his project is fresh, he might test some stuff in the backend to ensure the best enduser experience. The dns software used, does not fully support ipv6 yet, that's why you get these results. It don't mean anything for you. All records are delivered like a dns server which uses full stack ipv4/6 support :)

[hagezi]

Domains like plex.direct subdomains fail to resolve when querying IPv6-only root servers without timely IPv4 fallback, resulting in SERVFAIL errors due to IPv6 timeouts exhausting retry limits.

DNS resolvers like Unbound prioritize IPv6 root servers (all 13 support IPv6) when prefer-ip6: yes or default preference applies, querying them sequentially until success or timeout. If IPv6 connectivity issues or unreachable IPv6 paths occur (common without full IPv6 upstream), retries consume the max-sent-count (default 32), preventing IPv4 fallback and triggering SERVFAIL before IPv4 root servers are attempted. Plex.direct exacerbates this as its dynamic, server-ID-based subdomains rely on specific authoritative servers reachable only via reliable paths.

[hagezi]

@pictosun Updated the Unbound config to the version used and added a corresponding note in the Readme.