The Current State of Wildcard Prohibition
This page summarizes the existing technical and policy framework that prohibits registry-level wildcarding for non-existent second-level domains in gTLDs.
It describes the status quo in the global DNS before the introduction of AnyName.
For eligible gTLDs, AnyName seeks an exception from these prohibitions.
SECTION 1 – ICANN CONTRACTUAL PROHIBITION
ICANN’s gTLD Base Registry Agreement (2013 and later) explicitly forbids wildcard resource records or synthesized responses for non-existent second-level domains.
Specification 6 – Registry Interoperability and Continuity:
“The use of DNS wildcard Resource Records as described in RFC 1034 and RFC 4592 or any other method or technology for synthesizing DNS Resource Records or using redirection within the DNS by the Registry is prohibited. When queried for such domain names the authoritative name servers must return a ‘Name Error’ response (NXDOMAIN).”
Source: https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html
Supplement: icann.org/resources/pages/wildcard-prohibition-2014-01-29-en
All new gTLDs since 2013 are contractually bound by this clause.
Temporary, tightly scoped exception: during the 2014 Name Collision Controlled Interruption program, ICANN permitted short-term wildcarding only for diagnostic signaling. The prohibition otherwise remains absolute. (See icannwiki.org/Wildcarding.)
SECTION 2 – ICANN SSAC SECURITY ADVISORIES
ICANN’s Security and Stability Advisory Committee (SSAC) has repeatedly warned that wildcarding at TLD level endangers DNS stability and predictability.
SAC 006 – “Redirection in the COM and NET Domains” (2004)
icann.org/groups/ssac/report-redirection-com-net-09jul04-en
Documents the operational failures caused by SiteFinder and recommends against similar use in any TLD.
SAC 015 – “Why Top Level Domains Should Not Use Wildcard Resource Records” (2006)
icann.org/groups/ssac/documents/sac-015-en
Concludes that such services “create a reasonable risk of meaningful adverse effects on security and stability.”
SAC 041 – “Recommendation to Prohibit Use of Redirection and Synthesized Responses by New TLDs” (2009)
icann.org/groups/ssac/documents/sac-041-en
Formally recommends that ICANN prohibit these practices for all new TLDs.
These advisories form the direct basis for the contractual ban included in Specification 6.
SECTION 3 – IETF AND IAB TECHNICAL POSITION
The Internet Engineering Task Force (IETF) and the Internet Architecture Board (IAB) treat registry-level wildcarding as harmful to DNS architecture.
RFC 4592 – “The Role of Wildcards in the Domain Name System” (2006)
rfc-editor.org/rfc/rfc4592
Defines wildcard behavior and warns that inserting wildcard NS records or equivalent constructs in zones outside the operator’s direct control is harmful and discouraged.
IAB Statement – “Architectural Concerns on the Use of DNS Wildcards” (2003)
datatracker.ietf.org/doc/statement-iab-2003-09-20-dns-wildcards
Declares that wildcarding in public TLD zones violates architectural assumptions of the DNS and should not be practiced.
RFC 4185 and related drafts similarly discourage top-level aliasing mechanisms such as DNAME due to synchronization and delegation risks.
These technical foundations explain the later policy and contractual prohibitions adopted by ICANN.
SECTION 4 – CA/B FORUM CONSTRAINTS
The CA/Browser Forum Baseline Requirements for public TLS certificates make registry-level wildcarding incompatible with secure validation.
Certificate Authorities must verify control of each domain, and a TLD that resolves every query would invalidate this control model.
Baseline Requirements v2.0 § 3.2.2.4:
“If a Wildcard Domain Name is to be included in a Certificate, the CA MUST remove the asterisk from the left-most portion of the FQDN for validation.”
cabforum.org/baseline-requirements-documents/
Supporting ballots: Ballot 96 (2013) – Wildcard Certificates and New gTLDs; Ballot SC45 (2021) – Domain Validation Policy Changes.
These measures ensure that no valid certificate can cover all names under a TLD, reinforcing the practical ban.
SECTION 5 – HISTORICAL BACKGROUND (2003 SITEFINDER)
In 2003, VeriSign implemented “SiteFinder” by inserting a wildcard A record into the .com and .net zones.
The result disrupted email delivery, spam filters, and applications that depended on NXDOMAIN responses.
ICANN intervened on 19 September 2003 and ordered the service suspended.
icann.org/announcements/advisory-19sep03.htm
The incident led directly to the IAB statement, the SSAC advisories, and the formal contractual prohibition still in force today.
SECTION 6 – STATUS AND FUTURE DIRECTION
Current status of the DNS:
• ICANN registry agreements require NXDOMAIN for non-existent second-level domains.
• SSAC and IAB advise that wildcarding is harmful to stability.
• IETF standards discourage wildcards in public zones.
• CA/B Forum rules render registry-level wildcarding incompatible with modern TLS.
AnyName seeks an exception from these prohibitions for eligible gTLDs.
For more information please send an email to alexander.schubert@anyname.technology or call +1(202)888-2029