Summary

  • ICANN’s initial report studies one narrow design: the same string in a gTLD and one or more alternative naming systems, under the same controller and coordinated by the registry operator.
  • The draft recommends a mandatory turn-down plan and says this integration appears outside the five critical functions that an Emergency Back-end Registry Operator preserves.
  • The report is open for Public Comment until 21 September 2026. It is not final policy, an approved registry service or evidence that any operator has failed.

An exit plan is easiest to admire before an exit begins.

ICANN’s Technical Study Group has produced a detailed initial report on integrating a gTLD with alternative naming systems. Its chosen mechanism is deliberately bounded. The string must be the same in the global Domain Name System and the other system. The same party must control it. The registry operator coordinates that relationship, even where technical work is delegated.

The report’s most consequential recommendation appears near the failure case. A proposed registry service should state what capabilities it enables and how those capabilities can be switched off if the integration is no longer viable. Until real operating experience exists, the report recommends making that “turn-down plan” mandatory during evaluation.

That is a strong precondition. It is not yet an outcome record.

One name, several states

The design is not merely a pointer from DNS to another service. It joins administrative states across naming systems. The report distinguishes names that are available, enrolled, allocated, withheld, active, deactivated, suspended or disabled. Once a name is allocated in one system, the corresponding name cannot casually remain open for allocation to another controller elsewhere.

This is why “same string” is not enough. Two identical labels under different controllers are a collision in authority even if both systems work exactly as programmed. A registry therefore has to coordinate the controller as well as the characters.

The draft also separates policy control from technical subcontracting. A registry operator may use a Registry Service Provider or delegate components, but responsibility for registry policy remains with the operator. In the distributed model, several parties may run components while the service still has to preserve one coherent source of authority.

The state vocabulary exposes the exit problem. Turning off an interface does not by itself say whether an alternative name was deactivated, withheld for the current registrant, made available, left allocated, or stranded with an old controller. Nor does removal from one user interface prove that caches, ledgers, contracts and subordinate services now reflect the same result.

EBERO protects a different perimeter

ICANN’s Emergency Back-end Registry Operator programme is designed for a registry at risk of failing five critical functions: DNS resolution, the Shared Registration System, registration-data directory services, data escrow and maintenance of a properly DNSSEC-signed zone.

The TSG report says alternative-name integration appears to sit outside that enumerated perimeter. Its conclusion is cautious but important: the integration likely cannot survive EBERO operation, which is another reason an applicant should arrive with a turn-down plan.

This does not mean EBERO is incomplete. It means the emergency perimeter was defined for particular DNS registry functions. A new registry service can create an additional continuity dependency without becoming one of those functions. Governance fails if a purchaser, registrant or reviewer assumes that “registry continuity” automatically covers every service attached to a registry.

The distinction also prevents borrowed assurance. An EBERO provider’s readiness to operate DNS and registration functions does not establish that it can operate, unwind or reconcile an external naming system. The draft report does not ask EBERO providers to inherit that work. It anticipates that the integration will need to stop.

A plan describes; a receipt demonstrates

A turn-down plan can name triggers, sequence and owners. It can still remain untested, depend on a supplier that is unavailable during failure, omit a name state, or assume that a registrant will perform a final action after losing interest. The active IETF DNSOP draft on domain-name integration makes that last risk concrete: lifecycle and synchronization failures can leave a former registrant controlling the integrated identity after the DNS name has changed hands.

That Internet-Draft is work in progress, not an ICANN rule. Its analytical point nevertheless fits the TSG model. Control validation at enrollment does not prove continuing alignment at expiration, transfer, suspension or service shutdown. A clean entry cannot substitute for a clean exit.

ICANN’s Registry Services Evaluation Policy supplies the decision route. Registry operators use RSEP to add, modify or remove a service, and ICANN evaluates possible security, stability and competition issues. The initial report argues that its minimum requirements cannot be weakened just to make the service commercially viable; a weakened design would be a different service needing its own evaluation.

The same discipline should apply to turn-down evidence. If an applicant cannot demonstrate the promised state transitions in a controlled rehearsal, the answer is not to redefine “off” until the test passes. The unresolved exception belongs in the decision record.

The process remains open

The 10 August publication is an initial report. The first Public Comment window closes on 21 September. The charter anticipates review of comments, a second draft and consultation in October, further edits and a final report in January 2027. Those are planned stages, not completed decisions.

The report neither endorses alternative naming systems in general nor rejects other integration designs. It says the bounded same-string, same-controller model is unlikely to create significant security or stability issues only if appropriate operational controls are present. It does not say risk is zero.

No reviewed source establishes an approved integration, a registry failure, an EBERO activation involving such a service or a real case of controllers diverging. The gap identified here is prospective: a governance design can require evidence before operational history makes the missing evidence expensive.

Sources