How to Avoid Name Space Fragmentation in IPv4/IPv6 Environments
March 13, 2026
By Hugo Salgado and Alejandro Acosta
Introduction
Although the IPv6 protocol has been around for decades, the Internet is still a hybrid ecosystem in which IPv4-only, IPv6-only, and dual-stack networks coexist. This coexistence has originated a critical but often overlooked phenomenon: name space fragmentation, a technical barrier that can make parts of the network invisible to certain users.
What Is Name Space Fragmentation?
Name Space fragmentation occurs when a DNS resolver is unable to complete the resolution process because the authoritative servers for a zone are only reachable through an IP address family not supported by the resolver (IPv4 or IPv6).
(Free access, no subscription required)
Main Causes of Fragmentation
- Misconfiguration: Certain technical errors can break the delegation chain for a specific address family. Examples include no A or AAAA records for name server (NS) names, or missing glue records in the parent zone when the NS server is in the same domain.
- Network conditions: Certain network issues, such as dropping packets due to exceeding the path MTU (PMTU) or failures in IP packet fragmentation (especially in large DNSSEC responses), can prevent the resolver from receiving the information, thus contributing to name space fragmentation.
- Intentional fragmentation: This occurs when an operator consciously decides not to deploy IPv4 or IPv6 for a part of the resolution chain. For example, even though IPv6 adoption is growing, a large number of zones rely exclusively on IPv4.
- No support for TCP: As stated in RFC9210, an authoritative server must support the TCP protocol in addition to the common UDP protocol. This allows any interruption due to a very large response causing MTU interruptions to be served using TCP.
How to avoid this
To maintain the continuity of the name space, sources recommend using administrative policies to ensure that each zone is served by at least two authoritative servers reachable over IPv4 and at least two reachable over IPv6. It is also recommended to prefer dual-stack recursive resolvers to ensure that they can query any server regardless of its protocol.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.