Summary

  • RFC 10001 requires at least two IPv4-reachable and two IPv6-reachable authoritative name servers for a zone. One dual-stack server can count once in each family, so four receipts do not necessarily mean four physical machines.
  • NS, A, AAAA and glue records describe intended delegation. A reachability receipt additionally shows that the full chain works without the other address family, the selected server receives and answers the query, TCP fallback is available and both transports expose equivalent DNS data.
  • Tobias Fiebig coauthored the August 2026 Best Current Practice with Momoka Yamamoto. Their collective work is operationally useful because it gives teams a narrow common contract without pretending that publication, routing, transport and end-user resolution are the same state.

Imagine the acceptance review for a DNS-provider migration. The new zone lists two authoritative names. Each name has an A and an AAAA record. The parent has glue. A laptop on the office network resolves the zone immediately. The migration dashboard therefore displays four green checks and calls the service dual stack.

That dashboard may have counted records, not service.

The laptop can reach both address families and its recursive resolver can fall back from one to the other. If the IPv6 listener is closed, the IPv6 route is missing or an out-of-domain name-server dependency breaks on IPv6, the same lookup may still succeed over IPv4. The user sees an answer. The broken family disappears inside resilience.

RFC 10001, published in August 2026 as an IETF Best Current Practice, is designed around that mismatch. It was written by Momoka Yamamoto and Tobias Fiebig and obsoletes RFC 3901. Its practical contribution is not the phrase “support IPv6.” It defines what support must mean at the operating boundary.

An IPv4-reachable name server, in the RFC's terminology, receives and answers DNS queries over IPv4. The corresponding IPv6 definition uses IPv6. Neither definition says that an address record exists. Neither says that the returned data is correct. Reachability and content are deliberately separate.

That is why the requirement can be read as four receipts. A zone must be served by at least two authoritative DNS servers over IPv4 and at least two over IPv6. A server reachable through both families counts once in each set. Two well-operated dual-stack servers can therefore satisfy the count, while four addresses attached to one unreachable process cannot.

The distinction prevents a misleading mental picture. Four receipts are four server-and-family claims, not necessarily four racks, providers or organisations. Physical and administrative diversity are additional questions. If the same two dual-stack servers share one route, one load balancer, one software deployment and one change window, a single failure can erase all four receipts together.

Publication is only the first handoff

DNS delegation spans several owners. The child zone publishes NS records. The addresses for those names may live in the child, a sibling or another zone. The parent may need glue to break a circular dependency. Routing must carry packets to the advertised address. A server must listen on UDP and TCP. It must then return authoritative data consistent with what the other family serves.

Each step can be correct while the next is wrong.

An NS record proves that a name has been selected for authority. An A or AAAA record associates an address with that name. Glue lets a resolver cross a delegation boundary when it cannot first resolve the name server inside the delegated namespace. None of those records proves that a packet reaches a DNS process and receives a usable answer.

RFC 10001 makes family independence explicit. The IPv4 delegation path must not rely on IPv6 being available. The IPv6 path must not rely on IPv4. Parent resolution, sibling names and glue belong inside that test. A probe that begins on a dual-stack machine and silently crosses to the other family does not establish either condition.

The 2023 paper How Ready is DNS for an IPv6-Only World? supplies the empirical background. Fiebig is one of seven authors. The researchers showed why the presence of AAAA records is insufficient: the full delegation chain must be resolvable through IPv6. Missing glue, an unreachable out-of-domain dependency or a broken parent can stop the chain even when the final name-server name has an IPv6 address.

The paper's figures are historical, not a current scorecard. In its stated datasets, 44.9% of observed zones were not IPv6-resolvable in August 2022. Ten DNS operators accounted for 24.8% of the zones in the dataset that still did not resolve over IPv6. One provider's addition of IPv6 glue in January 2017 changed the result for more than 45.6 million zones. Those numbers describe the study's period, sources and method; they do not prove today's global rate.

Their lasting value is structural. A small number of providers can determine whether many zones have a complete family-specific delegation path. A provider migration, glue correction or common configuration defect can therefore change visibility far beyond one name.

A response is not yet the whole receipt

Once a probe reaches an authoritative address, it still has to test the service that operators intend to promise. Small DNS answers often fit in UDP without stress. DNSSEC responses and other large answers can encounter effective path-MTU limits, fragmentation or on-path discard. A green result for one small query says little about that boundary.

RFC 10001 points to RFC 9715 for avoiding fragmentation over UDP and requires DNS-over-TCP as a fallback rather than depending on fragmented UDP. RFC 9210 supplies the operational TCP requirement. The newer BCP also offers sender-MSS guidance, while recognising that effective paths and transition mechanisms can change the available margin.

A defensible receipt therefore records the transport. Did UDP return a valid answer? Did a deliberately truncated or large-response case complete over TCP? Was the test run through the same address family and relevant path? Did the response arrive within the resolver's time budget? A port scan or completed TCP handshake does not answer those questions.

Content supplies another boundary. RFC 10001 says IPv4 and IPv6 transports must serve equivalent DNS data. Two responsive listeners can still expose different versions of a zone during a staged deployment. A changed SOA serial, an absent DNSKEY or a divergent delegation can make clients see different authority depending on their path.

Equivalence does not require that every packet be byte-identical. DNS answers can vary legitimately because of ordering, signatures, anycast selection and response policy. The operator needs a declared comparison method: which authoritative facts must match, what variation is permitted, how serials and DNSSEC state are interpreted, and which difference blocks acceptance.

The receipt needs a subject, a vantage and a time

“IPv6 works” is not a reproducible observation. A useful record says which name server, which address, which queried zone, which protocol, which vantage point and which time produced the result. It preserves the parent and glue path used, the returned authority, the response code, whether TCP was exercised and how data equivalence was evaluated.

The vantage point matters because reachability is relational. A server can answer from the provider's own network while a route leak, filter or peering gap prevents another network from reaching it. One IPv6-only probe proves the path from that probe. It does not represent every geography or autonomous system.

This does not make measurement futile. It makes its claim bounded. Operators can choose independent vantage points that correspond to important user populations and failure domains. They can compare internal probes with external resolvers and can retain packet-level or transaction evidence long enough to explain a failed acceptance check.

The four-receipt table should also name ownership. The zone team owns child-side records. The parent or registry owns delegation and glue publication. The authoritative provider owns listeners, zone loading and much of the service capacity. Network teams own routes, filters and MTU behaviour. Monitoring owns the probes and their provenance. Someone with business authority decides whether a missing receipt blocks launch.

Without those owners, a red cell becomes an argument. The provider shows an AAAA record, the network team shows a route, and the zone owner shows a successful laptop query. All three can be true while an IPv6-only resolver still fails.

Fiebig's contribution is a method of looking

TU Wien's official profile says Tobias Fiebig became University Professor of Computer Networks on 1 March 2026 and leads its Internet Infrastructures research group. It describes work across Internet measurement, security, protocol development, DNS, SMTP, BGP and the organisational conditions for reliable operation.

That biography helps explain the form of RFC 10001, but it does not transfer operational authority to him. The BCP is collective IETF work with Momoka Yamamoto. The 2023 measurement paper has seven authors. Publication proves documented contribution and community review, not control over a provider, a registry or a production zone.

The recurring method is nevertheless visible: do not infer running behaviour from the existence of a configuration object. Measure the complete dependency chain, state the vantage and preserve the failure boundary. That method aligns with Heng Lu's Running-Code Primacy. The record matters, but the running response remains the stronger operational test.

Minimum Initial Specification supplies the complementary discipline. A common standard should specify the smallest cross-party conditions needed for interoperability and continuity. RFC 10001 does that by defining family-specific reachability, delegation independence, data equivalence and transport requirements. It does not force one provider, topology, monitoring product or business acceptance policy.

Local choice remains possible because the shared boundary is clear. An operator may use two dual-stack servers or a larger set. It may combine providers or use one. It may deploy anycast and several monitoring systems. What it may not do is call a record count the same thing as observed reachability.

What the four rows should contain

The simplest operational artefact is a matrix with at least four rows: server A over IPv4, server B over IPv4, server A over IPv6 and server B over IPv6. A larger deployment adds rows rather than compressing them into one status.

Each row should carry the NS name and tested address, the source of the address and glue, the family-only delegation result, the route and vantage, UDP response, TCP fallback, authoritative-data comparison, timestamp, change identifier and accountable owner. If a shared component makes two rows fail together, the matrix should say so.

The table is not a new protocol and it is not universal proof. It is a compact way to keep different claims from borrowing one another's evidence. It lets a reviewer ask whether the zone has four current receipts and whether those receipts are independent enough for the service's risk.

A provider migration can then have a precise completion rule. Parent and child data are published. TTLs have passed as planned. Every required server-and-family row succeeds from the agreed vantage set. TCP and large-response cases work. Equivalent authority is visible. Old dependencies are removed only after the new evidence persists through the chosen observation window.

The same structure improves incident review. If IPv6-only resolution fails, the team can locate the first broken handoff rather than saying “DNS was down.” Was the AAAA absent? Was glue stale? Did routing fail? Was UDP accepted but TCP blocked? Did one server load an older zone? Did a recursive forwarder hide the original error or loop to another single-stack resolver?

RFC 10001 warns about that last case. A single-stack recursive resolver can rely on a transition mechanism or forward failures to a dual-stack resolver. Two resolvers that lack opposite families must not forward unresolved queries to one another, because a name unavailable through both paths can circulate indefinitely. A fallback arrangement is itself a dependency with an owner and a test.

The operational conclusion is narrow. Four green records are not four reachability receipts. Four successful family-specific probes are not proof for every user. Four receipts today are not permanent. But a dated, owned and reproducible matrix is strong enough to support a change decision and honest enough to show what remains unknown.

Sources