Summary

  • RFC 10001 replaces the old IPv4-protection rule in RFC 3901 with symmetric operational guidance: a zone needs at least two IPv4-reachable and two IPv6-reachable authoritative servers, independent delegation paths for each family and equivalent DNS data over both transports.
  • “The name resolves” is not a global fact. It is a claim about one resolver, address family, full referral chain, listener and network path at one time. Dual-stack fallback can hide a broken family; only separate running tests and a chain-level evidence ledger expose the partition.

The incident ticket says the domain is up. The authoritative service is answering, the records are signed, and an ordinary monitoring resolver returns the expected address. Yet users on an IPv6-only access network see timeouts. They are not receiving a different DNS answer. They cannot reach the authority that would produce any answer.

The defect may be one missing AAAA record for a name server, missing IPv6 glue at the parent, a sibling name-server domain whose own delegation fails over IPv6, a listed address with no DNS listener, or a network path that silently discards a large packet. A dual-stack resolver simply tries the working IPv4 path. Its success conceals the other family's break and converts an address-family partition into a reassuring green metric.

RFC 10001, published in August 2026 as Best Current Practice 91, names that failure precisely. The DNS namespace is effectively partitioned when a resolver follows referrals to an authoritative server set that is reachable only over an address family the resolver cannot use. The zone still exists in the hierarchy. Reachability to its authority has split.

A delegation is a graph, not a row of records

An iterative resolver does not jump directly from a user-visible name to its final zone. It begins at the root, follows parent referrals, obtains addresses for authoritative name-server names and crosses every dependency required to contact the child authority. Each edge can have a different owner and failure mode.

For an in-domain name server, the parent must supply the necessary glue. The child must publish consistent address data when the delegation is revalidated. If the NS name belongs to a sibling domain, that sibling's own zone must be resolvable over the same family. Every parent above the child, up to the root, must also be reachable. The presence of one AAAA record somewhere in the graph proves none of those other edges.

Nor does an address record prove service. RFC 10001 notes that the same apparent configuration failure occurs when the A or AAAA address exists but the server does not answer DNS over that family. Record inspection and network observation are therefore different evidence.

This is the operational authority boundary. A parent controls its referral and glue. A child controls its authoritative data and listeners. A sibling operator controls a dependency introduced by the chosen NS name. Network operators control routing, filtering, translation and packet delivery. A resolver controls selection, retry and forwarding. No single actor can infer the whole path from its own table.

RFC 3901 protected one side of an early transition

RFC 3901 was published in 2004, when IPv6 DNS service was still experimental enough that the urgent concern was not breaking the namespace already available to IPv4-only hosts. It recommended at least one IPv4-reachable authoritative server and ruled out IPv6-only recursive operation unless it forwarded to a dual-stack resolver.

RFC 10001 obsoletes that asymmetric rule. It recognizes an Internet made of IPv4-only, dual-stack and IPv6-only networks and makes continuity a two-family obligation. At least two IPv4-reachable and two IPv6-reachable authoritative servers MUST serve a zone. One server reachable over both families counts once for each. The IPv4 delegation path must not depend on IPv6; the IPv6 path must not depend on IPv4. All NS names should carry both A and AAAA records, and both transports must serve equivalent DNS data.

The word “equivalent” matters. Passing two reachability probes while serving different zones or serial states would replace transport partition with data partition. Availability, content identity and authority must be tested separately.

Redundancy has to survive the family boundary

Two server names do not necessarily create two failures domains. They may terminate on one platform, one anycast deployment, one routing policy or one parent-side glue process. RFC 10001 retains the older RFC 2182 logic that authoritative service should be topologically and operationally diverse, then adds explicit reachability counts for each family.

A useful inventory therefore does not stop at NS count. For each server name, it should map operator, network, route, address family, glue owner, authoritative listener, TCP capability and monitoring vantage. The test is whether two independent usable paths remain, not whether four address records exist.

The cited 2023 study, How Ready Is DNS for an IPv6-Only World?, explains why the graph view changes conclusions. It found that a name-server AAAA record alone did not establish IPv6-only resolvability because the full delegation could still break. It also found substantial concentration among the operators behind broken delegations. Those measurements are historical evidence, not an August 2026 census, but the control lesson survives: one provider-side glue correction can change reachability for many dependent zones, and one provider-side defect can hide behind millions of apparently healthy records.

Packet delivery can partition a correct delegation

Even a perfect delegation graph can fail on the path. Large DNSSEC responses can exceed the effective path MTU. With UDP, fragmentation or silent discards can turn a valid answer into a timeout. With TCP, an advertised maximum segment size can still produce packets larger than the actual path carries when PMTU signals are blocked or wrong.

RFC 10001 builds on RFC 9715 and recommends avoiding fragmentation. It discusses an upper DNS-over-UDP response bound of 1400 octets and the more conservative 1232-octet practice that stays within IPv6's 1280-octet minimum packet size after headers. For TCP, it offers analogous sender MSS choices of 1388 or 1220 octets. RFC 9210 supplies the non-negotiable fallback: authoritative DNS must support TCP instead of relying on fragmented UDP.

These numbers are not a substitute for path evidence. A NAT64 or another transition mechanism can alter effective PMTU. Firewalls can drop ICMP or ICMPv6 feedback. Reducing UDP size can push more work into TCP. RFC 10001 cites observed TCP fallback in the 3–5% range and tells operators to monitor their own load. The engineering trade is explicit: spend capacity to reduce silent reachability loss, then measure where the cost moved.

A forwarding workaround can become a loop

The document says recursive resolvers should normally be dual-stack, while permitting a single-stack resolver to reach the other family through translation or by forwarding failed work to a dual-stack resolver. That preserves local deployment choice without pretending the missing authority became reachable by itself.

The forwarding graph needs the same rigor as the delegation graph. An IPv4-only resolver and an IPv6-only resolver must not forward unsatisfied queries to each other. If neither family can resolve a particular zone, the query can circulate indefinitely. The rule is simple: forward to a resolver that can complete both families, never to one that routes the work back.

NAT64 adds another evidence boundary. A synthesized IPv6 destination is not an independent native IPv6 path; it depends on the translation system and the prefix used for synthesis. RFC 10001 points to RFC 9872 for secure PREF64 discovery. Record the discovered prefix, its source, the translator path and the native destination. Otherwise “IPv6 DNS worked” can mean only that an undisclosed IPv4 dependency worked behind translation.

Stub resolvers create one more compression point. Operating systems and libraries may retain only a small number of supplied recursive-server addresses and may ignore additional ones unpredictably. The network can advertise a carefully diversified set; the client may keep a different subset. Configuration intent is not client state.

Build a family-continuity ledger

For each important zone, run independent IPv4-only and IPv6-only iterative tests from relevant network regions. Preserve every referral and its responder; NS, A, AAAA and glue data; sibling dependencies; the authoritative address contacted; UDP and TCP outcome; EDNS size; response size; timeout stage; DNSSEC result; and the returned RRset fingerprint. Bind those traces to time, resolver implementation, software version and vantage point.

Then retain the application outcome. A resolver answer is not proof that the application selected the address, connected or completed its service action. Equally, a successful application connection does not reconstruct which DNS path supplied it. Authority, delivery and use are three ledgers.

The IANA technical requirements for authoritative name servers are an operational procedure for delegated top-level domains, not evidence that RFC 10001 automatically changed every registry or registrar rule. The RFC declares no IANA action; it says IANA should consider updating its requirements through the applicable review process. Recommendation, procedure and observed enforcement must remain separate fields.

Heng Lu's Running-Code Primacy gives this article its evidentiary rule: publication cannot substitute for a path that actually resolves. His Minimum Initial Specification, Localized Future Decision and Voluntary Adoption identifies the legitimate common core—interoperability, safety and locally verifiable rules—while leaving implementation and later adoption with operators. RFC 10001 is most defensible when read that narrowly: protect namespace continuity and prove it in running systems.

The zone was online. That sentence was incomplete. The correct claim names the family, the chain, the path and the time.