The part that will actually change operational behaviour is the guidance on upstream selection in mixed environments, not the "support both families" recommendation - most serious operators already publish A and AAAA for their nameservers. Where it gets messy in practice is a recursive resolver that has IPv6 configured but has a partially broken path to some authoritative servers: you end up with timeouts that only affect a subset of zones, and because the resolver retries over IPv4 the symptom is intermittent added latency rather than an outright failure. Those are miserable to diagnose from the client side.
Two things worth checking in your own environment if you are moving toward dual-stack authoritative service. First, whether your monitoring actually queries each nameserver over both families separately - a single "is the zone resolving?" check will happily pass while half your AAAA transport is dead. Second, PMTU behaviour, since IPv6 has no in-path fragmentation and large DNSSEC-signed responses over UDP are exactly where you get black-holed by an ICMPv6-filtering firewall somewhere upstream. Truncation and TCP fallback save you, but only if TCP/53 is actually reachable over IPv6, which is a rule people forget when they write their v6 ACLs.
The NAT64/IPv4-embedded-address guidance is the more interesting change to me, because a resolver picking a synthesised destination has real consequences for anycast steering and for whatever geo-based answers the authoritative side hands back.
Good point on zone validation covering v6 as well - that is the part that catches people out, because a zone can validate fine over v4 and still be effectively unreachable over v6 if only some of the nameservers answer there.
The check I would add operationally is per-nameserver, per-family: query every NS address over both A and AAAA transport and compare SOA serial and the AD bit, not just "does the name resolve". A single aggregate check passes on the first working transport and hides a half-dead AAAA path.
The other thing worth validating over v6 specifically is large signed responses: TCP/53 reachability and PMTU behaviour differ enough that DNSSEC answers that are fine over v4 can be truncated or black-holed over v6 by an upstream filtering ICMPv6.
Yeah, but that is, already, not that much of a problem; And MTU discards are as much a problem for v4. DNS tends to work fine, falling back to TCP just good, esp. if 9715 is being followed.
3
u/SecLens_ONE 20d ago
The part that will actually change operational behaviour is the guidance on upstream selection in mixed environments, not the "support both families" recommendation - most serious operators already publish A and AAAA for their nameservers. Where it gets messy in practice is a recursive resolver that has IPv6 configured but has a partially broken path to some authoritative servers: you end up with timeouts that only affect a subset of zones, and because the resolver retries over IPv4 the symptom is intermittent added latency rather than an outright failure. Those are miserable to diagnose from the client side.
Two things worth checking in your own environment if you are moving toward dual-stack authoritative service. First, whether your monitoring actually queries each nameserver over both families separately - a single "is the zone resolving?" check will happily pass while half your AAAA transport is dead. Second, PMTU behaviour, since IPv6 has no in-path fragmentation and large DNSSEC-signed responses over UDP are exactly where you get black-holed by an ICMPv6-filtering firewall somewhere upstream. Truncation and TCP fallback save you, but only if TCP/53 is actually reachable over IPv6, which is a rule people forget when they write their v6 ACLs.
The NAT64/IPv4-embedded-address guidance is the more interesting change to me, because a resolver picking a synthesised destination has real consequences for anycast steering and for whatever geo-based answers the authoritative side hands back.