Summary

  • ICANN opened comments from 10 August to 21 September 2026 on an initial Technical Study Group report about integrating global DNS gTLDs with the same strings in alternative naming systems.
  • The report’s core rule is “string+controller integration”: the string and controller must remain the same across every integrated system, backed either by a shared registration system or a distributed but unified source of truth.
  • The report expressly does not endorse integration. Individual registry operators would still need approval through RSEP or the 2026-round process, and proposed contract language will receive a later public comment.
  • A material policy question remains outside the technical report: importing an alternative system with existing names may require the corresponding DNS names to be withheld, changing who can receive them before any DNS activation occurs.

A public comment on a threshold, not a launch

On 11 August, ICANN announced that it wanted public input on an initial report from its Technical Study Group on gTLD integrations with alternative naming systems. The proceeding opened a day earlier and closes at 23:59 UTC on 21 September. The request follows inquiries, dating from 2022, from existing registry operators and potential applicants in the 2026 new-gTLD round that want to associate a global DNS string with the same string in another naming system.

The distinction in that sentence is the whole story. ICANN is not proposing that every blockchain name, wallet identifier, application handle or private namespace enter the DNS. The TSG’s charter is narrower. It examines a registry service in which a gTLD operator uses the same string in the DNS and one or more alternative systems under the same institutional control.

Nor has ICANN approved that service. The public-comment page calls the report an initial report. The report calls itself a draft. It was commissioned to answer a threshold question for the Registry Services Evaluation Policy: can this limited class of integration be operated without creating unacceptable security or stability risk, and under what technical requirements?

The group’s answer is cautiously positive. It believes that a same-name, same-controller model is unlikely to create significant security or stability problems under RSEP if the operational controls are real. It also says that this conclusion is not an endorsement of the mechanism, of other mechanisms, or of integration as an idea. That caveat prevents a feasibility finding from being reported as institutional consent.

The invariant is not blockchain; it is control

The report calls its model “string+controller integration.” A name is integrated only if the same string in every system is always controlled by the same party, or withheld exclusively for that party. If that condition cannot be maintained, the namespaces are not candidates for this model.

That rule reaches below the top-level label. When a subordinate name is allocated in one integrated system, the corresponding name must be allocated to the same controller or withheld in the others. Transfers, suspension, deactivation and other lifecycle events cannot be allowed to create divergent control. For internationalised names, variant and Label Generation Rule processing must happen before integration, because different normalisation rules could otherwise make “same” an unreliable claim.

The report offers two broad operating designs. The simpler design treats the registry’s Shared Registration System as the enrollment controller and adds alternative systems behind it. In that model, registration data and ICANN policies travel through a familiar registry-registrar chain. EPP and RDAP would need extensions so operators and users could see and manipulate the extra state.

The distributed design does not require one master database. It requires a unified source of truth as a logical property: no participating system can validly change a name in a way that breaks the same-string, same-controller relationship. A wallet, durable identifier or cryptographic proof might help establish control. Settlement may be slower than an ordinary DNS update. But the registry applicant must demonstrate that participants cannot break the integration without the controller’s instruction or approval.

This is an important restraint. The presence of a blockchain does not decentralise accountability by itself. The report keeps one legal entity—the registry operator—responsible for performance even when several technical operators hold different pieces of the state. Infrastructure may be distributed; responsibility may not be shed across vendors or protocols.

The first policy collision is already visible

The technical model produces an immediate consequence. Suppose an alternative naming system already contains names before its TLD is integrated with the global DNS. To preserve the invariant, those names must be enrolled and at least withheld from allocation in the DNS, even if they are never activated there. The report identifies this as a technical implication with possible policy consequences, then places those consequences outside its scope.

That is the hinge between coordination and rulemaking. Withholding prevents two incompatible controllers from receiving what users may perceive as the same name. It protects uniqueness across the proposed integrated service. But it also changes the DNS allocation surface. A prior alt-name may remove a DNS name from availability, and a DNS registration may constrain the alternative system. The questions then become distributive: which prior claim counts, what notice is required, how conflicts are cured, whether defensive withholding carries a fee, and what appeal exists when the systems disagree.

A technical group can specify the condition that prevents collision. It cannot, by that specification alone, authorise every allocation consequence. ICANN’s Bylaws limit its work to coordination that is reasonably necessary for the openness, interoperability, resilience, security or stability of the DNS. The report itself notes that ICANN is not responsible for every naming system connected to the Internet and need not expand beyond the point where those systems impinge on the global naming system.

Lu Heng’s thin-coordination test makes the boundary easier to see. Uniqueness, accurate proof of control, auditable state and continuity can belong in a common layer. Commercial entitlement, priority between pre-existing claimants and the acceptable use of a name do not become common-layer powers merely because a technical integration makes them visible. The technical invariant may justify a narrow refusal to create conflicting control. Broader policy still needs an identified decision-maker, affected-principal input, reasons and review.

Approval remains an individual, contractual act

The proceeding does not create a general licence. ICANN says each registry operator seeking this service must proceed individually through RSEP, or through the applicable new-gTLD application process. RSEP evaluates potential security, stability and competition concerns. The TSG report is meant to prevent every applicant from paying to re-litigate the same baseline technical questions, not to remove applicant-specific scrutiny.

There is also no final contract language yet. ICANN org is following the study so it can draft registry-agreement amendments. The public-comment page says a draft final report will later be published together with proposed contractual language in another proceeding. The TSG charter anticipates a second comment period and finalisation in January 2027. Until those steps occur, readers cannot know the exact compliance duties, evidence standards, cure periods or enforcement consequences that would attach to an approved service.

Exit is just as important as entry. The report recommends a mandatory turn-down plan because an integration may prove commercially or operationally unviable. It also observes that alternative-name integration appears to fall outside the critical registry functions protected by the Emergency Back-End Registry Operator programme. If a registry fails badly enough to enter EBERO, the DNS may continue while the integrated alternative service does not.

That is not a footnote. A service marketed as one name across systems can split at the moment of institutional failure. Applicants therefore need to explain what users retain, what is disabled, how stale alternative records are handled and which system remains authoritative. “Same name” is a continuing operational promise, not a launch-day label.

What the consultation can legitimately settle

The immediate public question is whether the proposed technical requirements are sufficient. Comments can test controller proofs, synchronisation, distributed settlement, IDN handling, RDAP visibility, transfer mechanics, suspension, EBERO and turn-down. They can identify designs that appear compliant on paper but allow a participant to create divergent control in practice.

The next public question must be broader. Contract language will turn technical conditions into enforceable duties. That stage should separate four acts that are easy to blur: a TSG finding that a design can be safe; ICANN approval of one registry service; contractual authority to monitor and enforce that service; and policy choices about names or claimants displaced by integration.

The initial report is valuable precisely because it makes the first act concrete. It replaces vague talk of “bridging DNS and blockchain” with an operational invariant, a responsible legal entity and a shutdown problem. Its legitimacy depends on preserving the limit it states. Technical feasibility can open a door to evaluation. It cannot decide, by itself, who owns the threshold.

Sources