“They didn’t know it was impossible, so they did it.”

(Mark Twain)


”The AnyName concept directly fulfills ICANN’s stated objective for new gTLDs: to enhance innovation and utility within the DNS.”

Browser-Level NX-DOMAIN Forwarding for Audited gTLDs - the “AnyName” Concept

A Controlled Model for Mapping User Intent in Unregistered Domains to Same-TLD Results utilizing RFC 8914

Summary

AnyName Technology — enabling eligible gTLDs to turn NX-domain (“inexistent domain”) responses into signal by interpreting user intent.
This proposal introduces a standards-based mechanism that allows browsers to forward NX-DOMAIN (unregistered domain) requests for audited, trusted TLDs—such as community or brand TLDs—to a registry-designated HTTPS endpoint operated by that gTLD’s registry.
 It reframes NX-domain responses as structured, registry-controlled signals within audited namespaces (e.g., Spec-13 brand or community gTLDs), turning “non-existent” queries into interpretable user intent that can be safely resolved within the same namespace.

Participation should be limited to Spec-13 (brand) and community TLDs, ensuring intra-TLD scope and user-beneficial outcomes.
In controlled namespaces, user visits are typically exposure-based — users reach known domain names through marketing, search, or embedded links. AnyName Technology introduces a complementary behavior: it allows these namespaces to interpret unscripted, user-initiated intent directly through their own naming structure.

Rationale

Historically, NX-DOMAIN traffic was monetized through systems like Verisign’s SiteFinder (.com), Cameroon’s .cm wildcard, and Freenom’s .tk model.
These captured traffic bound for unregistered domains and converted it into advertising revenue—benefiting registries, not users.
The AnyName model explicitly rejects such usage and monetization.
In open gTLDs like .com, the overwhelming vast majority of domain names are rigid identifiers — company names, school names, associations, and countless small businesses like greenhillconsulting.com, smithhenson.com, or joesplumbing.com.
Only a much smaller fraction consists of high-impact generic category domains like flights.com or hotels.com that reflect user intent directly through their keywords. These domains are the rare exceptions within the namespace.
In .com, virtually every meaningful keyword or category term is registered, so they will not return an NXDOMAIN response.

By contrast, in highly controlled namespaces like Spec-13 brand registries, or in domain-eligibility-restricted gTLDs like .airport, this structure is reversed.
There are only a few rigid identifiers (internal divisions, regional branches, or verified sub-brands): a vast unregistered universe of generic, product, or category terms — for example playstation5.amazon, harrypotter.amazon, comedy.netflix, or jazz.spotify — that in controlled registries remains mostly unregistered by design.
In brand ecosystems like Amazon or Spotify, the variety of potential intent expressions is enormous — reaching into the hundreds of thousands, if not millions, of distinct product or content references. No operator could realistically pre-register or maintain such a namespace manually.
These are the environments where turning NXDOMAIN into intent becomes meaningful.

Example mappings include:

  • books.amazon → Amazon’s book section

  • playstation5.amazon → Amazon’s PlayStation 5 product page

  • comedy.netflix → Netflix’s comedy catalog

  • springfield.bmw → BMW dealers in Springfield

  • 740e.bmw → BMW 740e model page

  • amstradam.airport → correction to amsterdam.airport

All results must remain entirely within the same TLD—no external links, no monetization, no advertising.

This mechanism effectively turns “non-existent” domain signals into structured intent resolved entirely under registry policy control. It can also act as a demand-side discovery layer, revealing how users naturally attempt to express meaning within a namespace.

Mechanism

Extended DNS Errors (RFC 8914):

The AnyName proposal builds on the Extended DNS Errors (EDE) framework defined in RFC 8914, IETF (October 2022).
RFC 8914 standardizes a mechanism for DNS resolvers to include structured error information—an InfoCode and optional ExtraText field—within DNS responses.
EDE was introduced to improve transparency and diagnostic capability in the DNS, allowing resolvers to convey precise failure reasons such as DNSSEC validation issues, filtering, or lack of authority.
See also the 2025 analysis by SIDN Labs — the .nl registry — on the practical implementation of RFC 8914 Extended DNS Errors in modern DNS software and services.
The AnyName model repurposes this capability for controlled NX-DOMAIN signaling within eligible, contractually limited gTLDs (Spec-13 brand or community).

Eligibility is defined directly in each registry’s ICANN Registry Agreement.
Only registries whose contractual commitments (for example, Spec-13 or community gTLDs with public-interest restrictions) authorize intra-TLD NX-DOMAIN forwarding are allowed to emit Extended DNS Error payloads containing registry-designated HTTPS Target URLs.
Browsers interpret those EDE payloads; resolvers simply relay them.
All resolutions remain fully DNSSEC-valid and TLS-protected. The AnyName mechanism never alters DNS data or synthesizes addresses; users are forwarded over standard HTTPS to registry-designated endpoints.

The resolver communicates NXDOMAIN information for eligible gTLDs by including the registry’s designated endpoint in the Extended DNS Error (EDE) field of its response:

Query Name: burningman.airport

Query Type: A

EDE InfoCode: 20 (Not Authoritative)

ExtraText: https://my.airport

Supporting browsers then use that URL to continue resolution, e.g.:

https://my.airport/?origin=burningman

Proposed extension: A future standardized EDE InfoCode 25 — “NXDOMAIN Target URL” — could be defined specifically to mark NXDOMAIN responses that include a registry-designated HTTPS endpoint for contextual handling. For clarity, the mechanism would currently operate using EDE 20 (“Not Authoritative”), and may in the future employ InfoCode 25 if standardized.

Signal Flow Clarification
The AnyName mechanism does not alter resolver behavior or instruct it to perform redirects. The registry remains the originator of the signal: it defines the designated HTTPS endpoint (the Target URL) in its own authoritative DNS response. The resolver merely relays this structured NXDOMAIN response, including the EDE payload, without modification or interpretation.
All other applications or application-layer services that do not recognize this EDE field will simply ignore it and continue standard NXDOMAIN handling. Supporting browsers then forward the user to the designated HTTPS Target URL, performing the request client-side under standard DNSSEC and TLS protections.
In other words, the registry speaks, the resolver passes, and the browser listens.

Governance and Safeguards

Eligibility is determined through each TLD’s Registry Agreement.
Only registries whose contractual commitments (e.g., Spec-13 brand or community public-interest restrictions) explicitly authorize intra-TLD NX-DOMAIN handling may emit an EDE 20 (in the future: 25) payload containing a Target URL. Emitting such a payload without contractual authorization would constitute a breach.

Compliance is verified via independent, periodic NXDOMAIN probe audits conducted by third-party verifiers. These probes confirm that resolver pages display only same-TLD content, contain no advertising, and avoid cross-namespace links.

To prevent any recurrence of the SiteFinder controversy, the model is limited to eligible, contractually restricted gTLDs under verifiable oversight.

Audits focus on output behavior rather than resolver internals: periodic NXDOMAIN sampling validates same-TLD scope, the absence of monetization, and adherence to ICANN contractual limits.

By design, AnyName operates only within audited, policy-restricted namespaces. It explicitly excludes open commercial gTLDs (.com, .net, .org) to prevent abuse, monetization, or data harvesting. Its function is strictly interpretive, not monetized — translating legitimate user intent into compliant responses under registry and ICANN oversight.

Eligibility Summary
Only namespaces that demonstrably serve the end-user’s utility, operate under a single trusted interpreter, and return results solely within their own gTLD are eligible to use AnyName.
This eligibility model protects user intent and preserves the neutrality of resolution.
See full eligibility criteria click → /eligibility

Implementation Note: AI Role Clarification

Resolution mapping will likely utilize AI-based interpretation of user intent rather than static keyword lists, ensuring contextual accuracy and long-term adaptability.

The registry’s AI logic can interpret signals in two complementary ways: (1) immediate resolution to a relevant internal resource, or (2) observation of recurring “desire paths” revealing areas where users seek structure — insights that inform naming and registration strategy.

Outcome

Internet users can now express intent directly by typing intuitive domain names within trusted namespaces.
Participating TLDs can interpret that intent contextually and respond intelligently within their own namespace.

All interactions remain protected by DNSSEC and standard TLS — the model never breaks SSL/TLS or synthesizes DNS records.

  • Passengers may type burningman.airport, sicily.airport, or disneyworld.airport, and the .airport registry can respond with verified airport domains serving those destinations.

  • Shoppers may type cookware.amazon or playstation5.amazon, and Amazon can direct them to the correct internal product pages.

This turns the DNS into a user-facing semantic interface—a controlled, standards-based framework where audited TLDs interpret intent safely, without monetization, and within their own namespace.

The result is an educated, intent-driven interaction layer native to each gTLD: predictable, policy-bound, and fully compatible with existing ICANN safeguards.

Directly fulfilling ICANN’s stated objective for new gTLDs to enhance innovation and utility within the DNS.

A real-world use case example: a live .airport gTLD mockup

For the 2026 gTLD round application for .airport (see dotairport.org) we have created a live .airport simulation mockup. It is simulated in the second level of the .makeup gTLD.

Try it out at burningman.airport.makeup or at sicily.airport.makeup or hethrow.airport.makeup (a typo of Heathrow) or try any typo like “Gattwik” (Gatwick) or destination like “Disneyworld” or “Coachella” or territory like “Thailand”, “Florida” or “Poland”. The mockup is AI-powered. This is just a demonstration model - please do not expect absolute perfection. It is based on an OpenAI-driven interpreter that maps intuitive inputs to verified airport results.


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