On August 11, 2026, the RFC Editor published RFC 10001, "Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments," by Momoka Yamamoto of the WIDE Project and Tobias Fiebig of the Max Planck Institute for Informatics. It replaces RFC 3901, the September 2004 document that had defined BCP 91 for almost twenty-two years. Under the old text, IPv6 was optional for DNS. Under the new one, every zone MUST be served by at least two authoritative servers reachable over IPv6, on top of two reachable over IPv4.
It also tells recursive resolvers to be dual-stack unless they use one of a few sanctioned workarounds, bans authoritative servers from listening on IPv4-embedded IPv6 addresses, and treats NAT64 address synthesis as a legitimate way for an IPv6-only resolver to reach an IPv4-only authority. The gap it is aimed at comes from a 2023 measurement it cites: "a little less than 40% of zones are not resolvable via IPv6."
The 2004 rule assumed IPv4 would always be there
RFC 3901, by Alain Durand and Johan Ihren, had two operative sentences: "every recursive name server SHOULD be either IPv4-only or dual stack" and "every DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server." Read those again. An IPv6-only resolver was discouraged, and a zone with zero IPv6-reachable servers was fully compliant. In 2004, guaranteeing IPv4 as the common denominator was how you kept the name space whole.
The denominator has moved. Google's measurement of users reaching it over IPv6 crossed 50% for the first time on March 28, 2026 (50.1%, up from 46.33% a year earlier, per The Register); APNIC Labs' more conservative method puts global capability around 42 to 43%. Mobile networks increasingly run IPv6-only with NAT64 for the remainder, and RFC 6540 has required IPv6 on every IP-capable node since 2012.
The failure the document is built around has a name, name space partitioning. A resolver follows referrals down from the root; if one hands it a name server set reachable only over an address family the resolver does not have, resolution stops there. Dual-stack resolvers hide this by silently using the other family. An IPv6-only resolver sees a timeout, and the misconfiguration behind it may have gone unnoticed for years.
Two servers per family, and none of them on translated addresses
Section 4.1 is where the SHOULDs became MUSTs. A zone MUST be served by at least two authoritative servers over IPv4 and at least two over IPv6; a dual-stack server counts once per family, so two dual-stack machines satisfy the rule and one does not. The delegation for each family MUST NOT depend on the other: parent zone, the zones of name servers that live outside the delegation (sibling domain names, in the RFC's words), and glue all have to resolve within IPv6 alone and within IPv4 alone. Both transports MUST serve equivalent data.
Then the address rule: authoritative servers "MUST NOT use IPv4-embedded addresses [RFC6052] (including IPv4-Mapped IPv6 addresses and deprecated IPv4-compatible addresses [RFC4291]) for receiving queries." An AAAA record of 64:ff9b::c000:235 is not a destination. It is an instruction to a translator, and it only works from networks whose NAT64 uses that exact prefix. Publish one as glue and your zone is reachable over IPv6 from your own network and almost nowhere else.
The fragmentation guidance is new too. Servers SHOULD follow RFC 9715 to avoid fragmented UDP, DNS-over-TCP MUST be available as the fallback, and the document blesses the DNS Flag Day 2020 value of 1232 bytes for EDNS buffers, since 1232 plus headers fits inside the 1280-byte IPv6 minimum MTU. Servers MAY also clamp the TCP MSS to 1388 or 1220 bytes rather than wait on path MTU discovery.
One line in the IANA considerations deserves attention: the document asks IANA to consider requiring both IPv4 and IPv6 addresses for TLD name servers. IANA's current rules ask for two NS records in two separate origin ASNs, answering on UDP and TCP; they mention AAAA glue but do not require IPv6. Nearly every TLD is already IPv6-reachable; the point is precedent for the registries below.
Resolvers get three ways out of dual-stack, and one trap
Every recursive resolver SHOULD be dual-stack. A resolver MAY be IPv6-only if it uses a transition mechanism to reach IPv4-only authorities or forwards the queries that fail to a dual-stack resolver; it MAY be IPv4-only under the same forwarding condition; and one that knows the network's PREF64, from static configuration or the RFC 8781 router advertisement option, MAY synthesize IPv6 addresses for authoritative servers that only have A records. That last MAY is what Unbound has shipped since 1.18.0 in August 2023 as do-nat64: yes with a default nat64-prefix of 64:ff9b::/96; the idea reached the IETF as draft-momoka-v6ops-ipv6-only-resolver.
The trap is in the security considerations. Two single-stack resolvers, one per family, each forwarding what it cannot resolve to the other, will bounce a query for a zone that resolves over neither family forever. Hence a MUST NOT: never forward to a resolver that forwards back to you.
Stub resolvers get a short, practical section: follow RFC 6724 for address selection, avoid resolver addresses you can recognize as IPv4-embedded, and, because glibc keeps only three nameserver lines, operators handing out more than three addresses SHOULD supply either all from one family or exactly two from one and one from the other. Whatever a client keeps, it keeps something that works.
Where the 40% figure comes from
The measurement the RFC leans on is "How Ready Is DNS for an IPv6-Only World?" by Florian Streibelt, Patrick Sattler, Franziska Lichtblau, Carlos Gañán, Anja Feldmann, Oliver Gasser, and Fiebig, presented at PAM 2023 (preprint on arXiv). From Farsight's passive DNS data, January 2015 to August 2022, the authors replayed the delegation chain of every zone they saw, 368 million by the end, once with IPv4 only and once with IPv6 only. In January 2015, 11.4% of zones were IPv6-resolvable. By August 2022 it was 55.1%. Nearly all ICANN TLDs were fine throughout; the gap is below them.
Their active scan of the Alexa Top 1M in October 2022 (476,242 zones) makes the number concrete: 66.14% resolved over both families, 33.42% over IPv4 only, 0.43% not at all, and 16 zones over IPv6 only. Yamamoto's own experiment, described on the APNIC blog in February 2023, got the same shape from the resolver side: an IPv4-only iterative resolver answered 99.5% of the Tranco top 100,000; an IPv6-only one, 71.7%.
Two details from the paper explain why the fix is within reach. Among zones that show some IPv6 intent yet still fail, the most common cause is an out-of-bailiwick name server whose own zone does not resolve over IPv6; another substantial share have glue for A but not AAAA. Dependencies, not missing servers. And the problem is concentrated: over 97.5% of non-IPv6-resolvable zones sit on the top 10% of name server sets, and when one provider added correct glue in January 2017 it repaired IPv6 resolution for 45.6 million domains, 20.3% of the dataset, in a month. Ten operators could have fixed another 24.8% at the time of the study.
What does an IPv6-only client actually experience? Usually nothing, which is the problem: phones on IPv6-only mobile networks talk to the operator's DNS64 resolver, which is dual-stack and hides the partition. It bites when the resolver itself is IPv6-only, a recursive on an IPv6-only VPS say, where a third of popular zones fail with a timeout that looks nothing like "the zone has no AAAA glue."
What IPv4-embedded addresses look like in your logs
The transition mechanisms the RFC blesses leave fingerprints. An IPv4-embedded IPv6 address, per RFC 6052, is a prefix of 32 to 96 bits with an IPv4 address packed into the rest. With the well-known prefix 64:ff9b::/96 the last 32 bits are the IPv4 address, so 192.0.2.33 becomes 64:ff9b::c000:221. Operators may use their own prefix instead (RFC 8215 reserves 64:ff9b:1::/48 for local use), and for anything shorter than /96 the layout wraps around a mandatory zero octet at bits 64 to 71.
Three variants show up in practice. The first is not NAT64 at all: a service listening on a single dual-stack socket logs IPv4 clients as IPv4-mapped addresses, ::ffff:203.0.113.7, which is why Node.js and nginx (with ipv6only=off) logs are full of them. The second is 64:ff9b:: or an operator's PREF64 as a destination in outbound flows on IPv6-only hosts, an Unbound with NAT64 enabled for instance. The third is what the IPv4 side sees: nothing embedded, only the translator's pool, so an IPv6-only ISP's resolvers reach an authoritative server as a handful of NAT64 addresses, the many-behind-few pattern of CGNAT.
For geolocation, only the embedded IPv4 carries information. Our API resolves IPv4-mapped input directly: a lookup of ::ffff:808:808 returns the location and company of 8.8.8.8, Google in Mountain View. Addresses under a NAT64 prefix are local artifacts (the well-known prefix is on the reserved list, and RFC 6052 forbids advertising anything more specific than 64:ff9b::/96 in BGP), so no database can say where one "is." Strip the prefix and look up the low 32 bits:
python3 -c 'import ipaddress; a = ipaddress.ip_address("64:ff9b::c000:221"); print(ipaddress.ip_address(int(a) & 0xffffffff))'
192.0.2.33Five commands to test your own zone over IPv6
The RFC's validation checklist maps onto dig almost line for line. Run these from a host with working IPv6, substituting your zone, its name servers, and your TLD's servers for the .com ones. The -6 flag forces IPv6 transport for every query, +trace included, so a stall in the first command lands on the hop that only speaks IPv4:
dig -6 +trace example.com SOA
dig +short NS example.com # then dig +short AAAA each name: you need at least two
dig -6 +norecurse @a.gtld-servers.net example.com NS # AAAA glue in ADDITIONAL for in-bailiwick NS
dig -6 +tcp @ns1.example.com example.com SOA # TCP over IPv6 must work (RFC 7766)
dig -6 +dnssec +bufsize=1232 @ns1.example.com example.com DNSKEY # fits, or sets TC; never fragmentsFor a full report, Zonemaster runs its delegation tests over both transports, and the PAM 2023 authors' repository at github.com/mutax/dns-v6-readyness links to their raw active-measurement data (the command-line checker it promised was never published). If you run a resolver, the honest test is the one Yamamoto ran: turn IPv4 off and feed it the zones your users care about. Expect about a third to fail.
Whichever side of a translator you sit on, the addresses in your logs still need decoding before they mean anything. Ipregistry returns location, ASN, and connection type for the IPv4 or IPv6 address you hand it, IPv4-mapped input included, and you can try it with 100,000 free lookups to get started.
Keep users in the loop Ship release notes that get read. Try Noticeable