Summary

  • ICANN’s Technical Study Group describes what can happen when a DNS registration expires while the registrant wants to retain the matching name elsewhere: DNS resolution is withheld, but the alternative name may remain active. The choice depends on policy in that system and on the registrant’s decision.
  • That branch turns a slogan about the “same string” and “same controller” into an operating obligation. A registry service needs to identify who may change each state, what evidence shows the systems have converged, and what happens when they have not.

Expiry is a governance event

Consider a registrant who allows example.tld to expire in the DNS but chooses to keep example.tld in an alternative naming system. This is a scenario in the Technical Study Group’s draft report, not a report of a live incident. The DNS name is withheld from the global DNS. The alternative name can remain active if its own rules permit that outcome and the registrant wants to maintain it.

The alternative is more consequential than a simple deletion. If the registrant does not wish to keep the alternative name, the report describes disabling the names across the systems, deallocating them, and removing them from enrollment. Only after that sequence does the name become available again. Expiry therefore does not answer whether the name survives. It starts a sequence of choices about what survives, which party can make the choice, and when another party may acquire the string.

That is where an integration promise becomes a governance question. A matching label is easy to observe. A controller is harder: identity can change through renewal, registrar practice, internal transfer, suspension, or a system-specific enforcement action. The same-string/same-controller rule has to hold across those transitions, not merely at the point when an application first checks the records.

A technical baseline is not a service approval

ICANN convened the TSG after registry operators and potential applicants asked about offering a registry service that associates a global DNS gTLD with the same string in an alternative naming system. The group examined whether the arrangement could be operated securely and stably and what technical requirements might support it. The initial report is dated 10 August 2026 and marked as a draft.

The report does not approve an integration or endorse one architecture. It says same-string/same-controller operation may be possible with suitable controls, while explicitly leaving room for other approaches. ICANN’s public-comment page makes the institutional boundary clear: each registry operator must proceed individually through the Registry Services Evaluation Policy (RSEP). The TSG report is intended to inform future evaluation and contract language; a draft final report and proposed registry-agreement amendments are expected in a later public-comment proceeding. The live page lists 16 November 2026 as the date the report is due.

That separation matters. A common technical study can reduce repeated analysis, but it cannot show that every operator has the same systems, counterparties, controls, or ability to observe state. The service application is where a general invariant must become a testable promise for a particular registry and its partners.

Two operating models, one proof problem

The TSG discusses a traditional shared registration system (SRS) as one possible control surface. When changes to both names pass through the registry’s SRS, the registry may be able to coordinate publication and hold the evidence linking the DNS and alternative records. A single domain object with one registrant is comparatively legible. Even then, the report cautions that a shared SRS alone does not prove that the controller is the same. The service needs enough information, or a reliable contractual and technical assurance, to establish that link.

A distributed design may instead use a Unified Source of Truth (USoT) across systems. That can accommodate records stored outside the registry, but it shifts the proof burden. The service must show how the source establishes the controller, how every participant receives a change, and what state is considered authoritative while an update is in flight. “The systems are connected” is not an answer to a question about who can safely act during a delay.

The report’s internal-transfer example makes the issue concrete. A registrar may change the registrant entirely within its own business systems, without notifying the registry. The registry then cannot observe the new controller directly; the integration depends on contractual compliance unless a persistent identity link or other evidence is available. Where DNS and alternative names are separate objects with separate controllers, the report says a registry procedure that transfers both objects with one command is one possible way to preserve the invariant.

The distinction between operational states also matters. The report says suspension should apply in all naming systems simultaneously. It treats certain external deactivation events, such as abuse or a court order, differently from a registrar’s clientHold, which should not automatically disable the alternative name. Those are deliberate semantics, not interchangeable “sync” actions. A service that labels them all as a generic pause makes it harder for registrars, registrants, and users to predict what remains reachable.

The review record points toward observable conditions

The public submissions illustrate where a broad technical principle becomes difficult to administer. Unregistry’s comment hosted by ICANN supports the report’s basic conclusion but focuses on the thinner user-side requirements, including visibility into integration state and behavior during a synchronization failure. That is one submitter’s view, not a consensus finding.

The Government of India submission asks that broad requirements become measurable and verifiable before an RSEP approval. Its proposed tests include defined transaction states, controls for unresolved updates, fail-safe behavior, a tested shutdown plan, safeguards around expiry and reallocation, and independent security testing. Again, these are recommendations in one comment; they are not adopted ICANN requirements.

The Intellectual Property Constituency’s comment points to rights-protection questions left for wider policy discussion. That boundary should remain visible. A technical control can prove that two records are coordinated without deciding who should have a right to a name, whether a collision remedy is adequate, or where a user can seek redress.

An application should therefore let a reviewer answer practical questions without exposing a registrant’s private data: Which actor may initiate a renewal, transfer, suspension, or removal? What event authorizes it? What does each system acknowledge? How long can a partial result persist? What stops a second registrant from receiving a name while its prior counterpart remains active? What is the correction path when the information is disputed?

A transition record is part of the service

The missing artifact is not another label or a second copy of the registration. It is a service-level record of the transition. For each material change, an operator could retain the initiating authority, policy version, prior and intended state, affected systems, transaction identifier, acknowledgments, time or sequence information, retry and containment rules, and a notice or review path. The public signal can be much smaller than the audit record: a user needs to know whether the integrated name is active, withheld, suspended, or unresolved; an auditor may need the evidence showing why.

This record is a recommendation for future service design, not a requirement the TSG has already adopted. It matters because each actor sees a different slice of the transaction. A registrar may know the customer relationship; a registry may control DNS publication; an alternative-system operator may control the counterpart’s execution. The registrant bears the practical cost if those slices stop agreeing. A contract that names responsibilities but leaves the evidence unobservable will be difficult to enforce after an incident.

Expiry is a useful test because it forces the service to say what it means by “same controller” after a right in one system ends. If an alternative name can remain active, that persistence needs to be deliberate, communicated, and linked to a clear rule about later deallocation. If every counterpart must be disabled, the service must show how that action completes across systems and how it behaves when one system is unavailable.

ICANN’s RSEP policy and implementation notes already center an operator-specific service description and the effects on external users. The question now is whether the next review cycle will convert the TSG’s common technical baseline into service terms that can be tested before launch and audited when conditions change. Until then, “same string, same controller” is a starting condition. Governance begins when the service explains how it proves the condition through time.

Sources