6 Things You Need to Know About ICANN's DNS + Alternative Naming System Integration Report

For years, Web3 naming systems and the traditional DNS have run on parallel tracks where a blockchain-based name and a domain name could coexist without ever being formally connected. That's starting to change. As more Web3-native gTLDs apply for ICANN accreditation, and as more everyday users expect a single identity that works across both worlds, the question of how a DNS name and its Web3 counterpart can safely be treated as "the same name" is something ICANN is now trying to formally answer.

That's exactly the job ICANN handed to its Technical Study Group (TSG) on the Integration of Global DNS gTLDs with Alternative Naming Systems. The group, made up of registry operators and technical experts, has just released its first draft report. The short version of its answer: yes, DNS names and alternative-naming-system names can be safely linked under a specific set of conditions.

The report is out for its first round of public comment through September 21, 2026, and there's already a lot of speculation about what it means for Web3 domains. We read it in full so we could bring some clarity instead of noise.

1. It's a technical report, not an enforced mandate… yet

The TSG exists to answer one question: is there a safe way to connect the DNS to alternative naming systems? Its report lays out the group's recommendations for how registry operators can do that securely without risking the stability of DNS. But this is the initial version of the report, and it's got a way to go.

After its current public comment period, the report goes back to the TSG for discussion and edits. It will then be released again for an additional round of public comment before being submitted to ICANN. Even then, its future as official policy is uncertain.

The benefit of this process is that users, registry operators, and the broader domain industry all have the opportunity to raise questions, flag concerns, and shape recommendations before the final report lands on ICANN’s desk.

2. Integrations qualify for an Registry Services Evaluation Policy (RSEP) review

The report is clear that this kind of integration counts as a "registry service" under ICANN's existing Registry Services Evaluation Policy (RSEP). Practically, that means any registry wanting to offer DNS + alternative naming system integration has to submit its integration architecture for review. ICANN will evaluate it for security, stability, and market competition concerns. It’s the same level of scrutiny applied to any other change to how a registry operates. 

What are the implications of an RSEP? For registry operators, an RSEP is an additional hurdle to clear before they can offer a true DNS to alternative naming system integration. Integrations will be evaluated on the stability of the alternative namespaces, the technical integration, and even whether the registry has a fall-back plan for sunsetting operations, among other things. 

There are many reasons why an RSEP for an integration would be rejected, but one of the biggest red flags is an unstable integration that puts DNS at risk. For registry operators, a rejected RSEP can lead to a drawn out process. Redesigns and potential public comment periods directly affect target launch dates; a TLD cannot be launched with a Web3 integration if its RSEP is rejected.

3. The core idea is "string + controller" registry models

Strip away the technical language and the report's whole framework rests on one idea. Two things always have to be true for a DNS name and its counterpart in another naming system, such as a blockchain-based one:

1. The name has to be the same string in both systems
2. The name has to be controlled by the same entity in both systems

The report calls this "string+controller integration," and nearly every requirement in the document exists to make that guarantee airtight.

What does this mean in practice? Domain.locker on DNS has to exactly match its corresponding name. domain.name.locker on the alternative naming system, for example, would not be considered the same. Additionally, both domain.locker on DNS and domain.locker on the alternative naming system need to be controlled by the same person or entity.

The goal behind a registry string+controller integration is to reduce confusion on DNS, even when connecting to naming systems that have no obligations to ICANN. The lens of this report is to protect the security, stability, and resiliency of DNS. Allowing identical names with different owners to connect to DNS puts that at risk.

4. DNS and blockchain systems don't handle the technical concept of "ownership" the same way

Traditional DNS assumes one clear owner of record for a name. If you’ve ever had a domain ownership dispute or have been locked out of a registrar account, you’re familiar with how buttoned up ICANN domain ownership policy is. Most blockchain-based naming systems don't work that way. Users generally choose to stay anonymous, which is a feature of Web3, not a bug.

To bridge the gap, the report introduces the idea of a "Unified Source of Truth" (USoT). In the simplest terms, this means that records of ownership may be pulled from different systems, but the name’s data has to stay in-sync. The challenge for blockchain naming systems is the reconciliation between on and off chain records. DNS updates almost instantly with ownership data and lifecycle events. Blockchains can, in the worst case scenario, take up to hours for data to update. USoT ensures that despite this, ownership and domain lifecycle event data is never in conflict between naming systems.

This is a key technical recommendation for registry operators. ICANN-accredited registry operators must abide by its Base Registry Agreement. The agreement explicitly states that ICANN can audit for operational compliance. This includes maintaining accurate, secure records of ownership. Even if the TSG’s report doesn’t become policy, maintaining up-to-date records between systems is necessary for avoiding messy ownership disputes. Ultimately, this could be seen as a risk to the security of DNS, putting a registry’s accreditation on the line.

5. Existing alternative names don't need to register on DNS, but if they are registered, they must still prove ownership

Here's an important distinction the report draws: if an existing Web3 naming system wants to bridge into this kind of integration, its names don't have to be registered on the DNS. But they do have to be withheld there, or essentially reserved so no one else can come along and register the matching DNS name.

This distinction is particularly important for existing blockchain naming systems. To actually bridge a Web3-based name to its DNS counterpart, you have to prove single ownership of both names. Proving ownership on the DNS side means providing personal registrant details, including name, email, and address. Generally speaking, this isn’t something Web3 natives want to do simply to be on DNS. Registering a Web3-based name typically doesn’t require that level of information. Withholding is the compromise: it blocks anyone else from claiming the DNS name, so an existing Web3 domain holder keeps control of their identity without being forced to hand over personal information. But if a Web3 domain holder wants DNS integration, ICANN ownership rules still apply. Identifiable information must be provided to prove the name is under control of a single entity. 

6. There's plenty of room for interpretation, especially for existing Web3 namespaces

This is worth sitting with: the report is built almost entirely around registry-level integration, and its worked examples mostly assume clean namespaces rather than established naming systems with existing registrations. It also explicitly focuses on the technical health of integrations in relation to DNS, not how existing namespaces should manage migrations, data collection, or operations.

That leaves plenty of still unanswered questions for existing Web3 domains. As an ICANN accredited domain, these are the questions that immediately come to our attention:

• What data do they need to collect for DNS registration?
• How should data be collected?
• Should data collection be mandatory, or should it be optional?
• What does the path to registration look like?
• Do users get to choose a registrar, or will one be chosen for them?
• What happens to names that have no expiration date on the Web3 side?
• How much should users pay for the DNS registration, if anything?
• Will names continue to be sold through Web3-based name providers, or will they exclusively be sold through an ICANN registrar moving forward?
• What happens to the names that aren’t registered with the winning TLD applicant?

Those aren’t necessarily policy questions that ICANN can solve. They’re business questions that could be influenced by existing policy. 

The bottom line 

The report gives a thorough technical answer to whether DNS names and alt-naming-system names can safely share the same owner, and it says yes, with the right controls. What it doesn't fully resolve is how that framework accommodates naming systems and communities that already exist today, built around different norms than an ICANN registry operator.

The current public comment period is coming to an end soon. There will be another chance to review and comment, but providing feedback now ensures that your voice will be heard in full. The community is an essential part of the process.