RFC 10001 makes IPv6 a requirement for authoritative DNS

The IETF published RFC 10001 in August 2026. It is a Best Current Practice, BCP 91, and it replaces RFC 3901 from September 20041. The old IPv4-only minimum went from SHOULD to MUST, and the same requirement now applies to IPv6.

RFC 3901 asked that "every DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server", so the name space wouldn't split2. RFC 10001 asks for the same thing in both directions, twice over, and drops the softer keyword:

To maintain name space continuity, every DNS zone MUST be served by at least two authoritative DNS servers providing services via IPv6.3

The IPv4 requirement is the same sentence with the address family swapped. Two of each, both families, for every zone. Both of those paragraphs carry a further sentence: the delegation itself, meaning the parent, the glue and any sibling domain your NS names live in, "MUST NOT rely on" the other family being available.

Do nameservers need IPv6 records now?

Yes, if you want to follow current best practice. RFC 10001 requires at least two IPv6-reachable nameservers for every zone, alongside the two IPv4-reachable ones that were never in question.

The practical risk of ignoring it is not a fine or a rejected delegation. It is a resolver on an IPv6-mostly network that cannot reach your nameservers, cannot find your MX record, and never tells you.

What does RFC 10001 actually require?

Five things, and only the first one is widely known.

1. Two reachable nameservers per address family. Not two nameservers with IPv6 somewhere in the mix. Section 4.1 spells out the arithmetic: "to prevent DNS name space partitioning, at least two IPv4-reachable and two IPv6-reachable name servers MUST be configured for a zone. A single name server that is reachable over both IPv4 and IPv6 counts once per address family."4 Two dual-stacked servers satisfy the whole requirement. Four IPv4-only servers satisfy half of it.
2. Every NS name should have both records. This one is RECOMMENDED rather than MUST5, and it is the one that quietly costs you speed. If ns1.example.com has an A record and no AAAA, an IPv6-only resolver that picks it asks for the AAAA, gets NODATA, and has to go and look up the address of a different nameserver instead. Nothing breaks. The RFC says such a name "may add overhead to the resolution process": a wasted query for a record that does not exist, before the resolver goes and asks for a different nameserver's address.
3. Both transports serve the same data. "Both IPv4 and IPv6 transports MUST serve equivalent DNS data to ensure a consistent resolution experience across different network types."6 Split-horizon setups that answer differently depending on how the query arrived are out.
4. No IPv4-embedded addresses on authoritative servers. An authoritative server "MUST NOT use IPv4-embedded addresses (including IPv4-Mapped IPv6 addresses and deprecated IPv4-compatible addresses) for receiving queries"7. No ::ffff:1.2.3.4, and no NAT64-synthesised address standing in for real IPv6 connectivity. Translation is not adoption.
5. Don't fragment, and answer over TCP. Fragmented UDP is fragile, and NAT64 can shrink the effective path MTU without warning. So fragmentation "SHOULD be avoided by following guidance on maximum DNS payload sizes" in RFC 9715, and DNS-over-TCP "MUST be available as a fallback option"8. If your firewall drops TCP/53 because someone decided DNS is a UDP protocol, that decision is now a defect.

Does anyone actually enforce a MUST in a BCP?

No, and pretending otherwise is how standards documents lose credibility.

A BCP is not a protocol change. No registry will reject your delegation tomorrow for missing AAAA records, no resolver will refuse to talk to you, and nothing in your zone stops working the day this RFC is published. The document says as much about who does the checking. "To prevent name space partitioning, zone validation processes SHOULD ensure that" four conditions hold. First on the list: "there are at least two IPv4 address records and two IPv6 address records available for the name servers of any child delegation within the zone"9. That is aimed at whoever validates the parent zone, which in practice means registries and TLD operators. It asks them to check your delegation, and it asks with a SHOULD.

Our take: treat the MUST as a description of where the enforcement is already happening, not a rule waiting to be applied. The enforcement is the resolver on the far side that can only speak IPv6. It doesn't read RFCs, it doesn't send you a notice, and it fails silently. The RFC is describing an outage mode that already exists and is getting more common.

How common is IPv6-only DNS resolution, really?

Common enough to notice, and measured. Geoff Huston's APNIC work on DNS over IPv6, published March 2026, puts it this way: "The overall result is that we see an overall capability of 75% of users who can use DNS over IPv6." The web-based half of the same measurement is lower and less flattering, "50% to 65% of users demonstrate their capability to resolve a DNS name that requires the use of DNS over IPv6"10.

The zone side of the same problem is in the RFC itself. Citing a 2023 study, it puts the share of zones not resolvable over IPv4 at negligible, "while a little less than 40% of zones are not resolvable via IPv6"11. Just under two in five, unreachable to a resolver that only speaks IPv6.

Capability is not dependency, and the gap between those two numbers is where the honest reading sits. Most of those resolvers are dual-stacked and will fall back to IPv4 all day long. The population that breaks on an IPv4-only zone is likely much smaller, and nothing in Huston's numbers counts it directly: mobile networks running IPv6-mostly, data-centre underlays that never got IPv4 space, and networks where IPv4 exists only behind a NAT64 the resolver itself doesn't use. Small, and growing.

Why does this reach my email before it reaches my website?

Because mail is the one service where the sender is a machine that gives up quietly.

A human on a broken network reloads, switches to mobile data, or phones you. A sending mail server does not. It resolves your MX, and if resolution fails, it queues. Then it retries on a schedule you don't control, and after a few days it bounces the message back to a sender who is not you. You find out when a customer mentions, weeks later, that an email never arrived.

Two hops have to survive for that mail to reach you, and both live in DNS:

The first hop is what RFC 10001 is about, and it is the one nobody checks. Your MX record can be perfect. Your SPF, DKIM and DMARC can all be green. If the resolver asking on behalf of the sending server cannot reach a single one of your nameservers, none of those records are ever read.

The second hop is the more familiar one, and it cuts the other way. Publish an AAAA on your MX host and senders that can use IPv6 will start connecting over it. On a self-hosted setup the box that receives is usually the box that sends, so the self-hosting deliverability traps start here: the v6 address missing from SPF, no PTR on it, and mail that authenticates from some networks and fails from others. Publishing AAAA on your mail host commits you to configuring the rest of it. Publishing AAAA on your nameservers commits you to nothing. It is free.

We checked Microsoft on 29 August 2026 and again on 5 September 2026. outlook.com has one MX, outlook-com.olc.protection.outlook.com, and that host has an A record and no AAAA on both dates. The hosts Microsoft 365 tenants receive on are a separate set, and they do not answer alike: microsoft-com.mail.protection.outlook.com came back with both A and AAAA, while adobe-com.mail.protection.outlook.com answered NOERROR with an empty AAAA section from all three resolvers12. So it varies by tenant. We have not found Microsoft documenting what decides it. None of that breaks RFC 10001. The requirement lands on your nameservers, not your mail hosts. Our MX checker shows the A and AAAA of each mail host, so you can see which side yours sits on.

Is my DNS dual-stacked? Here's the one-minute check

Look up your nameservers and ask for both record types. You want an A and a AAAA for every name in the set.

dig +short NS yourdomain.co.za
dig +short A ns1.yourprovider.com
dig +short AAAA ns1.yourprovider.com

An empty answer to the AAAA query is the finding. Repeat it for every nameserver in the delegation, then do the same for each host named in your MX records.

That is the first check, not the whole one. RFC 10001 asks for two servers that answer over each family, and for a delegation that resolves over each family, which means both address types in the parent's glue and every zone above yours reachable over IPv6. An AAAA that nothing is listening on passes the dig and fails the requirement. The check that settles it is resolving your domain from a network with no IPv4 at all.

Who is already compliant, and who isn't?

We checked. These are other people's configurations and they can change the week after this is published, so re-run the commands above rather than trusting the table.

Checked 13 August 2026, re-checked 29 August 2026, from 1.1.1.1, 8.8.8.8 and 9.9.9.9. All three agreed both times. Nothing moved between the runs13. Every name answers NOERROR for A. The IPv4-only ones answer NOERROR for AAAA too, with an empty answer section. That is the nameserver saying the record does not exist. A lookup that failed looks different, and would tell you nothing about IPv6 either way. If your domain sits on managed DNS at one of the large providers, you are almost certainly done, and this article is a five-minute confirmation rather than a project.

The two IPv4-only sets in that table answer perfectly over IPv4, which is why nobody has noticed. Nothing here is a security hole, and nothing here shows up as an outage. What you have is a zone that a growing minority of resolvers can only reach through a translation layer, and a fix that belongs to your provider.

What to do: if your nameservers come back IPv4-only, the change is your DNS provider's, not yours. Ask them whether AAAA records on their nameservers are on the roadmap, and cite RFC 10001 rather than a preference. If the answer is no and your domain carries mail you cannot afford to lose, moving DNS hosting is an afternoon: the zone file moves, the mail doesn't, and the only risky moment is the TTL window at the cutover.

Do I need to dual-stack everything else too?

No. The RFC is about DNS, and the requirements thin out fast as you move away from authoritative servers.

Recursive resolvers get a SHOULD: "every recursive DNS resolver SHOULD be dual-stack"14, with explicit permission to be single-stack if they forward what they can't resolve to a dual-stack resolver. That covers most corporate networks as they are already built.

Stub resolvers, meaning your workstations, get the most practical advice in the document, and it has nothing to do with compliance. Some implementations can only hold a few resolver addresses. The RFC names glibc, which takes three. So if you push four or five DNS servers to clients over DHCP and router advertisements, some of them are being silently ignored, and which ones is not deterministic. RFC 10001's guidance kicks in when you hand out more than three. Operators SHOULD ensure one of two things. Either "all supplied recursive server IP addresses are from the same address family, based on knowledge as to clients being IPv4-only or IPv6-mostly", or "exactly two IP addresses are from one address family (IPv4 or IPv6) and exactly one is from the other address family"15.

If you have ever handed a fleet two IPv4 and two IPv6 resolver addresses and then chased an intermittent resolution failure on a handful of machines, that paragraph is the answer.

Our take: act on the nameserver requirement, ignore the rest for now. It costs nothing when your provider already supports it, and the remainder of the document describes DNS operations you are mostly doing already. Check your NS records this week. If they come back clean, close the tab. If they come back IPv4-only, you have found a failure mode that never produces an error message, and those are the ones you have to go looking for.

Everything else on your domain depends on DNS, and almost nobody monitors it. That is the case for taking DNSSEC seriously too. It is also why a nameserver fault gets reported to you as a website problem, or a mail problem, or a customer who says your forms are broken.

What this article was checked against

Every claim above was checked against a primary source. Where the claim is about what the RFC says, the source is the RFC text. The nameserver table is an observation on two dates.

1. RFC 10001 is BCP 91, published August 2026, and its header records Obsoletes: 3901. RFC 3901 is dated September 2004. — RFC 10001 · RFC 3901 ↩
2. The RFC 3901 sentence quoted here, word for word: "every DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server". — RFC 3901 §4 ↩
3. The IPv6 requirement, quoted in full and unaltered, and the sentence that follows it in both the IPv4 and IPv6 paragraphs: the delegation configuration of an NS (parent, sibling domain names, glue) MUST NOT rely on the other address family being available. — RFC 10001 ↩
4. The two-per-family arithmetic and the rule that a dual-stacked server counts once per address family. — RFC 10001 §4.1 ↩
5. "It is RECOMMENDED that all names used in NS RRs have an A and AAAA record set." A recommendation, not a requirement. — RFC 10001 ↩
6. Both transports must serve equivalent data. — RFC 10001 ↩
7. The prohibition on IPv4-embedded addresses for receiving queries, including IPv4-mapped and the deprecated IPv4-compatible forms. — RFC 10001 ↩
8. Fragmentation avoidance per RFC 9715, and DNS-over-TCP as a required fallback rather than fragmented UDP. — RFC 10001 · RFC 9715 ↩
9. The zone-validation guidance, addressed to whoever validates a zone rather than to the zone owner, and carrying SHOULD. — RFC 10001 ↩
10. Both APNIC figures quoted verbatim: the 75% overall capability, and the lower 50% to 65% from the web-based measurement. Geoff Huston, 2 March 2026. — Measuring the use of DNS over IPv6 ↩
11. The share-of-zones figure is the RFC quoting a 2023 study, not a measurement made for the RFC. Treat it as three years old. — RFC 10001 ↩
12. Looked up 29 August 2026 and re-run 5 September 2026 against 1.1.1.1, 8.8.8.8 and 9.9.9.9, all three agreeing: outlook.com had a single MX whose target answered with an A record and no AAAA; the tenant-facing host microsoft-com.mail.protection.outlook.com answered with four A and four AAAA, and adobe-com.mail.protection.outlook.com answered four A and NOERROR with no AAAA. Three hostnames on two dates, not a statement about Microsoft's roadmap, and not a sample big enough to say how the platform behaves in general. — MX checker · dig +short MX outlook.com, then dig AAAA outlook-com.olc.protection.outlook.com, dig AAAA microsoft-com.mail.protection.outlook.com and dig AAAA adobe-com.mail.protection.outlook.com ↩
13. Nameserver AAAA presence, checked 13 August 2026 and re-checked 29 August 2026 against 1.1.1.1, 8.8.8.8 and 9.9.9.9. These are other people's configurations on those two dates and nothing more; re-run the command rather than citing this table. — DNS lookup tool · dig AAAA ns1.example.com @1.1.1.1 ↩
14. Recursive resolvers get SHOULD, with explicit permission to forward what they cannot resolve to a dual-stack resolver. — RFC 10001 ↩
15. The three-address limit with glibc named, and the two-options guidance that applies when more than three resolver addresses are supplied. — RFC 10001 ↩

Check your nameservers for free.