Enabling NX Resolution for Eligible gTLDs – Minimal DNS Policy Adjustments Required

Below are the specific, named policy artifacts that must be updated, created, or clarified by each governing body.

The current status quo

The current DNS policy framework correctly prohibits wildcarding in open TLDs to protect stability and prevent abuse (see all ICANN, IETF & CA/B provisions that prohibit wildcarding here). For eligible, tightly controlled gTLDs (primarily Spec-13 brand TLDs), AnyName requires only narrow, targeted policy updates to enable safe, user-benefiting NX resolution.

Proposed Policy Framework for Community Consideration (strawman proposal)

Eligible TLDs must meet all of the following conditions:

  1. A single trusted controller is authorized by the registrant base to resolve nonexistent domain names.

  2. Registrant eligibility is strict and verified.

  3. Domain label eligibility is restricted and predictable.

  4. User Intent Fulfillment: The resolution of a non-existent domain name must be a good-faith attempt to directly fulfill the user's most likely intent based on the domain label itself. The response must be:

    • contextually relevant,

    • transparent,

    • and must not Hijack intent (e.g., redirect a product query to an unrelated search page or advertiser).

  5. No third-party monetization of queries for nonexistent domains is permitted; all outputs must clearly serve user benefit.

  6. The operation is subject to independent audit, revocation, and emergency stop capability.

This model is intended primarily for Spec-13 brand gTLDs. We need to prevent a repeat of the SiteFinder episode, where user intent has been hijacked for the purpose of traffic monetization by third parties.

These changes are non-disruptive, backward-compatible, and fully auditable.


ICANN – Required Actions

  1. Base Registry Agreement – Specification 6, Section 2.1.1
    Action: Amend
    Change: Add exception:
    “Except for TLDs granted NX Resolution eligibility under Specification 14, the use of DNS wildcard Resource Records… is prohibited.”

  2. Add a new registry agreement clause (or Specification 14) allowing NX Resolution only for TLDs that meet both of the following:

    • A single trusted controller is authorized by the registrant base to resolve nonexistent domain names.

    • Strict registrant mandate — eligibility is verified, and the registry acts as the sole interpreter of intent.

  3. Require operators to apply for NX Resolution eligibility during registry agreement review or amendment.

  4. Registry Operator Application Process (Section 1.2.1)
    Action: Update
    Change: Add:
    “Operators may apply for NX Resolution under Specification 14.”

  5. New: Specification 14 – Reserved-Label Proof
    Action: Create
    Rule:
    “Notwithstanding RFC 2606 and RFC 6761, which reserve the label ‘example’ for documentation and prohibit its registration in the global DNS, ICANN hereby exempts NX-eligible gTLDs from this restriction solely for the purpose of Reserved-Label Proof. The label ‘example’ may be registered in NX-eligible gTLDs only when used in conjunction with a fourth-level NX sub-zone (e.g., nxresolve.example.gTLD). No other use of example.gTLD or any third-level domain (such as www.example.gTLD) is permitted. This exemption does not require changes to IETF RFCs — it is a policy-level override within ICANN’s authority over gTLD registry agreements.”
    Note to IETF:
    Our framework fully respects RFC 6761.
    example.gTLD and *.example.gTLD remain NXDOMAIN.
    We only use the string "example" in the fourth-level label (*.nxresolve.example.gTLD) as a static policy marker. This maintains the RFC's core purpose.

  6. New: Specification 14 – IANA NX-Eligibility Registry Mandate
    Action: Create
    Rule:
    “ICANN shall instruct IANA to publish and maintain a public, machine-readable NX-Eligibility Registry (via RDAP or dedicated list) listing all gTLDs approved under this Specification. The registry must include a field nxResolutionEligible: true/false and be updated immediately upon ICANN approval or revocation. This list is the authoritative source for Eligibility CAs to verify current eligibility before issuing NX-Eligibility Certificates.”

ICANN GNSO Policy Change Work plan (if we start December 1st with the issues report)

  1. Submit IRR (Alexander Schubert + 2 GNSO Council allies) by 1 Dec 2025 — 1 day.

  2. Preliminary Issue Report + 21-day comment (ICANN staff fast-track) by 22 Dec 2025 — 3 weeks.

  3. Final Issue Report + Council vote to launch PDP by 15 Jan 2026 — 3.5 weeks.

  4. Charter approved + WG kick-off (virtual) by 15 Feb 2026 — 4 weeks.

  5. Initial Report + 30-day comment by 15 May 2026 — 3 months.

  6. Final Report + Council supermajority vote by 15 Aug 2026 — 3 months.

  7. Board adoption by 1 Mar 2027 — 6.5 months.

    Total: 15 months (Dec 2025 → Mar 2027).


ICANN Pilot Exemption Process (Spec-13 gTLDs – NX Resolution Testing)

Eligibility

  • Must be a Spec-13 brand TLD (single registrant).

  • Proposal limited to controlled DNAME + 4th-level gate (nxresolve.nxresolve.tld - NOT using the reserved “example.tld” gate).

  • Zero monetization, full audit trail, 90-day max pilot.

  1. Submission (email) To: newgtld@icann.org Subject: CoC Exemption Request – NX Resolution Pilot [.tld] Attach:

    • 1-page PDF:

      • TLD + brand owner consent

      • Technical diagram (DNAME flow)

      • Weekly reporting template

    • Signed letter from registry operator.

  2. ICANN Review (4–6 weeks)

    • Day 1–3: Acknowledgment + public comment opened (21 days).

    • Week 4: Staff analysis (stability, security, consumer impact).

    • Week 5–6: Approval or revision request.

  3. Outcome

    • Waiver granted → live pilot starts within 7 days.

    • Results auto-feed into GNSO Issue Report Request (IRR).

IANA – Required Actions

  1. Publish a public, machine-readable NX-Eligibility Registry (via RDAP or dedicated list) listing all approved TLDs.
    The registry must include a field nxResolutionEligible: true/false and be updated immediately upon ICANN approval or revocation. This list is the authoritative source for Eligibility CAs to verify current eligibility before issuing NX-Eligibility Certificates. IANA shall publish this registry in RDAP and optionally in a dedicated JSON endpoint for real-time CA queries.


CA/B Forum – Required Actions

  1. Adopt a new ballot permitting CAs to issue:

    • Wildcard certificates for sub-zones (e.g., *gTLD)

    • On-demand certificates for nonexistent second-level labels — only when the parent TLD presents a valid IANA-signed eligibility credential.


IETF – Required Actions

  1. Publish an Informational RFC recognizing contained, policy-gated DNAME use in private namespaces as architecturally safe when:

    • Non-HTTP protocols return NXDOMAIN

    • Eligibility is cryptographically verified

    • A kill-switch is enforced


Purpose of the Fourth-Level Gate (nxresolve.example.gTLD)

This is not a technical requirement of AnyName’s DNS logic. It is a policy enforcement tool that gives Certificate Authorities (CAs) two independent, real-time signals to verify that a gTLD is still authorized to resolve non-existent second-level domains.

Two Independent Signals — Both Must Be Positive

Signal 1 – NX-Eligibility Certificate

Controlled by: CA/B-accredited Eligibility CA
What it proves: The gTLD is currently listed in IANA’s NX-Eligibility Registry. The Eligibility CA checks the IANA list before issuing (or renewing) the certificate (e.g. every 24h). If ICANN removes the gTLD from the IANA list, the Eligibility CA stops issuing — the certificate expires and cannot be renewed. This is the primary kill-switch: The CAs won’t be permitted anymore to issue (short-lived) 2nd level wildcard or on-the-fly TSL certificates anymore.

Signal 2 – Fourth-Level Request Gate

Controlled by: Registry DNS
What it proves: The original user request arrived via the fourth-level gate nxresolve.example.gTLD. Only eligble gTLDs (e.g. with the Spec-14 exemption) can register and use example.gTLD. If a gTLD loses its exemption, nxresolve.example.gTLD has to stop resolving — the gate disappears.

How the Two Signals Work Together

  1. User types samsunglaptops.amazon.

  2. Amazon’s authoritative server applies DNAME → samsunglaptops.nxresolve.example.amazon.

  3. The request arrives at the fourth-level gate (nxresolve.example.amazon).

  4. DNS returns IP of edge server — browser reconnects via HTTPS (rebound).

  5. Edge server receives the request and contacts the CA to issue (or renew) a certificate for samsunglaptops.amazon.

  6. The CA checks both signals:

    • Signal 1: Is there a valid NX-Eligibility Certificate from the accredited Eligibility CA?

    • Signal 2: Did the original request come through nxresolve.example.gTLD?

  7. Only if BOTH signals are positive does the CA issue the certificate.

  8. If either signal fails, the CA denies issuing the certificate — NX resolution stops instantly.

Why This Design

  • Signal 1 (certificate) is the policy gate — ICANN/IANA control via the Eligibility CA.

  • Signal 2 (fourth-level gate) is the technical gate — only eligible (e.g., Spec-14) gTLDs can use example.gTLD.

  • Together, they create a zero-trust, double-lock system that would be hard to bypass for a rogue registry.

CA/B Forum Instruction to CAs

“CAs SHALL issue wildcard or on-demand certificates for non-existent second-level labels in a gTLD only if both signals are positive:

  1. The registry presents a valid NX-Eligibility Certificate issued by a CA/B-accredited Eligibility CA (proving current IANA listing)

  2. and The original user request arrived via the fourth-level gatenxresolve.example.gTLD.

If either signal fails, issuance MUST be denied.”

This is not a rewrite of DNS. This is a safe, ethical exception — for trusted namespaces only.



For more information please send an email to alexander.schubert@anyname.technology or call +1(202)888-2029