Namespace
- Version
- v1
- In force since
- Not yet
- Next review
- At adoption
- Snapshot
- None yet
- Adopted by
- Proposed for founding adoption
- Signature
- At adoption
- Log entry
- Not appended yet
- Binding text
- English
Proposed, not in force
Open for comment until 28 October 2026, 00:00 UTC. Nothing here binds anyone until it is adopted.
Scope
This policy says which strings may become GOpenCDR TLDs, and how GOpenCDR stays out of the IANA namespace. It binds Tier 0, every TLD operator and every mirror.
IANA always wins
No GOpenCDR TLD or name may answer in place of a name that exists in the IANA root. Where the two meet, the IANA name wins, at every layer and without exception.
Three independent layers enforce 2.1: the root's verification gate refuses any string delegated in the IANA root, the blocklist refuses it when it is proposed, and the mirror agent withdraws any overlay TLD that appears in the IANA root. The prober alerts on any GOpenCDR answer for a name delegated in the IANA root.
Rule iana.wins. Limits: No setting, scope, motion or emergency can switch a layer off.
A GOpenCDR name or TLD that comes to exist in the IANA root is withdrawn from every zone and every mirror within 1 hourfixed of the IANA delegation, and its label is blocked for good.
A withdrawn name or string is never registered again, by anybody.
Candidate TLD strings
A TLD string has 3 to 63 characters, is not all digits, has no hyphen outside a valid xn-- A-label, and is valid IDNA 2008 when internationalised. In ASCII it is either letters only, or it starts with a letter and contains a digit, such as lab42, a class ICANN can never allocate.
Rule tld.string_rules.
Every candidate string is checked against the IANA root zone, ICANN's applied-for, contended, reserved and withdrawn strings, the IANA special-use registry, OpenNIC, Handshake as 3.4 says, the reserved list of section 4, and the UTS #39 confusable skeletons of all of these. The verdict is signed and kept with the proposal.
Rule tld.collision_checks.
Every collision source is refreshed at least every 24 hoursfixed. A proposal made while a mandatory source has had no good refresh for 48 hoursfixed is held until it has one. A source that has not published its list yet only warns.
OpenNIC's live TLDs are always blocked. A Handshake name with a live delegation and measurable use blocks the same string here; any other Handshake name only warns.
A string ICANN withdraws from its pipeline is released only after a cool-off of 90 daysfixed and a decision of the Community Council.
Reserved strings
A public, versioned reserved list blocks at least: every two-letter ASCII string; ISO 3166 alpha-3 codes and the names of countries and territories; the special-use names of RFC 6761 and RFC 9476; internal; strings with a known collision risk, namely corp, home, mail, lan, intranet, private and localdomain; the names of intergovernmental organisations, the Red Cross and the Olympic movement; and GOpenCDR's own infrastructure names.
Rule reserved.list.
Internationalised strings
An IDN TLD must pass the current Root Zone Label Generation Rules. A TLD accepts internationalised registrations only once it has published its own second-level rules; it blocks variant labels or bundles them to one registrant, and refuses labels that mix scripts.
Rule idn.lgr_required.
Sunset
When one of our TLD strings enters ICANN's application pipeline, the TLD goes into sunset within 7 daysfixed: registrations close, registrants are told, renewals are capped at the expected delegation date, and tooling to move elsewhere is offered.
The migration window lasts until ICANN delegates the string. If the application is withdrawn or rejected, the sunset is lifted and the TLD carries on.
Peers
Names resolve in this order of precedence: IANA, GOpenCDR, OpenNIC, Handshake. The default resolver profile includes OpenNIC; Handshake is an opt-in extended profile.
TLD classes
An untrusted TLD is served only to mirrors and people who opt in, either to that TLD by name after reading its risk statement, or once to every untrusted TLD, current and future. It is never in the default profile.
An additive TLD is a string that also exists in the IANA root. It holds only names the IANA namespace lacks: resolvers ask IANA first and answer from GOpenCDR only where IANA proves the name does not exist, a name is registered only once its absence is proven, and a name that comes to exist in the IANA namespace is withdrawn under 2.3.
An additive TLD needs a joint motion passed by two thirds of the Community Council and two thirds of the Operators Council. The same motion decides whether it is opt-in or served to everyone.