New Web Domains: How New Domain Extensions Are Changing the Internet
New domain extensions have changed the Internet, but not in quite the way many people expected when hundreds of them began appearing more than a decade ago. They have expanded the vocabulary of web addresses, created new options for brands, places, professions, and communities, and increased the range of generic domain endings available in many writing systems. They have not made .com obsolete, given new gTLDs an automatic search advantage, or made extension-wide search an inherent feature of the domain system.
The useful question in 2026 is no longer whether new domain extensions matter. It is where their impact can be measured, which ones are realistic choices for a particular registrant, and when a less familiar ending is a better choice than a conventional one.
What Is a New Generic Top-Level Domain?
A top-level domain, or TLD, is the final part of a domain name, beginning after the last dot. In localization.company, for example, .company is the TLD and localization.company is the registered domain name.
Registering a domain name and operating a TLD are very different. A person or business may be able to register a name under an existing extension through a registrar. Operating a new gTLD such as .events ordinarily requires a legal entity to apply, pass evaluation, enter a registry agreement with ICANN, and maintain the technical and business operation. For the 2026 round, the base evaluation fee was USD 227,000 for each application, before possible conditional fees. Registering example.events does not give its owner control of .events.
The term “new gTLD” applies to extensions introduced through ICANN's New gTLD Program. ICANN had already added smaller groups of gTLDs through application rounds opened in 2000 and 2003, but the modern large-scale expansion began with the 2012 application round. The first four extensions from that round were added to the DNS root on October 23, 2013. All four used Arabic, Chinese, or Cyrillic script. Delegations and registration phases then followed individual registry schedules. Some extensions opened broadly, while others remained restricted or brand-controlled.
The 2012 round received 1,930 applications covering 1,400 unique strings. As of August 31, 2026, ICANN's 2012-round statistics recorded 1,241 cumulative delegations. The application and delegation figures do not form a simple success rate because several applicants sometimes sought the same string and only one identical TLD can be delegated. ICANN also notes that its cumulative total is not reduced when a registry agreement later ends or a TLD is removed from the root, so it is not a count of currently active extensions.
Delegation does not necessarily mean that anyone can register a name. It means that the extension has been entered into the authoritative DNS root. The registry may open it broadly, impose eligibility or use rules, reserve premium names, or keep the extension for its own organization.
Status of the 2026 Round on September 15, 2026
ICANN accepted applications for its 2026 round from April 30 through August 12, 2026. On August 13, it reported more than 1,600 primary applications. ICANN cautioned that the final total could not be confirmed until the required evaluation fees had been received. As of September 15, the 2026 program announcements did not include a final total, the applied-for strings, or a firm Reveal Day date.
The round has entered pre-evaluation. Under ICANN's published applicant journey, the next formal step is the Administrative Check, which verifies payments and prepares initial contention sets. On Reveal Day, ICANN will publish the public portions of applications that pass this check, along with the primary, variant, and replacement strings submitted in those applications. A replacement string is a backup that an applicant may later substitute for its original string; it is not an additional approved TLD. ICANN said Reveal Day was expected no later than nine weeks after the window closed, absent extraordinary circumstances.
Applications must then move through further processes that may include a replacement period, public comments and objections, evaluation, contention resolution, contracting, onboarding, technical testing, and delegation. ICANN's lifecycle estimates describe relatively straightforward applications; objections, contention, extended evaluation, or other complications can lengthen the process. The 2026 round therefore does not give domain buyers hundreds of immediate new choices. It begins a process that may produce new extensions over the coming years.
What the Expansion Actually Changed
Adoption Is Significant but Uneven
New gTLDs became a substantial minority of the domain market. At the end of June 2026, the Domain Name Industry Brief counted 52.9 million registrations in new gTLDs out of 401.6 million registrations across all TLDs, or about 13.2 percent. .com alone had 166.6 million registrations. These are registration counts, not counts of active websites, businesses, or regular users.
The same report estimated a combined renewal rate of 31.0 percent for new gTLDs, compared with 67.2 percent for legacy gTLDs other than .com and .net. A renewal rate measures how many expiring registrations are kept, so this gap shows why a raw total should not be treated as proof that every registration represents durable use. New gTLDs have established a real market segment, but their low aggregate renewal rate shows that registration totals are not the same as durable use.
ICANN's 2024 summary of its competition, consumer choice, and consumer trust review characterized the earlier round as producing a large increase in choice, a smaller but meaningful increase in competition, and little overall change in consumer trust. The underlying review found that familiarity still favored legacy endings and that some TLDs, rather than the entire category, had disproportionate levels of DNS abuse. Since April 5, 2024, ICANN's registry and registrar agreements have required action against well-evidenced DNS abuse. These system-level findings do not establish the quality or safety of any particular site.
Web Addresses Can Carry More Meaning
A well-chosen extension can make the complete address describe its subject. Names such as localization.company, museum.art, or festival.events can communicate an idea before anyone visits the site. This can be useful when the matching .com is unavailable or when the complete phrase is easier to remember than a longer conventional address.
That meaning is a communication advantage, not proof of quality. An open extension does not verify the accuracy, legitimacy, or security of every site registered beneath it. Users still judge the complete name, the organization behind it, and the site itself.
Brands Can Control the Space After the Dot
Some companies obtained their own .Brand extensions. Under Specification 13 of ICANN's Registry Agreement, only the registry operator, its affiliates, or qualifying trademark licensees may be registrants in a .Brand TLD. This gives the organization control of the names used beneath the extension and may support official services, short campaign addresses, product naming, redirects, or a more tightly governed namespace.
A .Brand application is not a route to private control of a generic market term. ICANN's 2026 rules state that applications for exclusive-use, or “closed generic,” strings will not be approved unless and until an evaluation method and public-interest criteria are established. A qualifying brand TLD and a generic word operated for public registrations are therefore different models.
Brand ownership at the top level is fundamentally different from buying an ordinary domain. Extensions such as .apple, .bmw, and .google appear in the IANA Root Zone Database, but they are not general alternatives that anyone can purchase from a registrar.
Places and Communities Gained New Naming Spaces
Extensions such as .africa, .berlin, .london, .nyc, .paris, .scot, and .tokyo can connect an address with a place or community. Their policies differ, and some require a local or community connection.
A geographic-looking new gTLD is not the same as a country-code TLD such as .ch, .de, or .uk. Google treats new city and regional extensions as generic top-level domains, so the suffix does not provide automatic country targeting. The intended audience must instead be established through the site's content and appropriate language and regional signals.
The Expansion Added More Internationalized Domains
Internationalized Domain Names existed before the 2012 new gTLD round, including country-code domains in non-Latin scripts. The round expanded the generic namespace with extensions such as .شبكة, .дети, .みんな, .世界, and .网络. The form people read is a Unicode “U-label,” while the DNS uses an ASCII “A-label” created with Punycode and beginning xn--. For example, .شبكة is represented internally as xn--ngbc5azd.
This substantially widened the range of languages and writing systems available at the top level of a generic domain. The 2026 application framework supports IDN applications under rules covering 27 scripts or writing systems, as well as applications for certain variant strings. Variants are alternate labels calculated under the root-zone rules and evaluated through the application process; they are not automatic copies or already approved extensions. A delegated non-Latin TLD also does not guarantee that every desired second-level word is permitted, because registry language tables, variant rules, and registration policies differ.
A continuing practical problem is Universal Acceptance. Some forms, email systems, and applications do not recognize every valid new or internationalized address. ICANN describes Universal Acceptance as the goal that all valid domain names and email addresses should work across Internet-enabled systems. Anyone relying on an unusual or non-Latin address should test the complete path from typing and linking to account creation and email delivery.
What New Extensions Did Not Change
A Keyword in the Extension Does Not Create an SEO Bonus
A relevant extension may help a person understand or remember an address, but it should not be purchased as a shortcut to higher search rankings. In 2015, Google said that new gTLDs are treated like established generic domains and that a keyword in the TLD provides neither an advantage nor a disadvantage in search. Google's current ranking systems guide separately says that words in a domain name as a whole are one of many relevance factors and that its exact-match-domain system limits excessive credit. That broader point does not give the word after the final dot special ranking weight. A site on a new gTLD is evaluated under the same search systems as a site on another generic extension.
The same caution applies to city extensions. An address ending in .london may signal a place to readers, but Google treats it as a generic TLD. It does not operate like a .uk country signal or create an automatic ranking bonus for London-related searches.
A TLD Is Not a Search Engine
A domain extension creates a naming space. It does not index or search the sites registered beneath it. A registry or another organization may separately build a directory or specialized search service, and a conventional search engine can offer ways to limit results to a domain or top-level domain. Neither function is supplied automatically by the extension itself.
A Low First-Year Price Does Not Mean a Cheap Domain
Some registrars promote selected domains at very low introductory prices. The important figure is the continuing cost. Renewal fees may be much higher than the first-year offer, and a desirable word may be classified as a premium name with different registration and renewal pricing.
ICANN advises registrants to check renewal terms before buying because registrars set their own prices and promotional first-year fees may be lower than later renewals. Compare the expected cost over several years, not only the price in the advertisement. A quoted renewal fee is not guaranteed for the life of the registration. The standard Base Registry Agreement permits registry-level renewal-price increases subject to notice rules, while registrars determine the retail price.
A Current Sampling of Domain Endings
Every extension in the following sample appeared in IANA's active root list on September 15, 2026. This is not a complete availability list, and delegation does not establish that an extension is open to everyone or that a particular second-level name can be registered.
Broadly offered, subject to registrar support and name availability: .academy, .agency, .app, .art, .blog, .club, .design, .events, .gallery, .online, .photography, .shop, .store, .tech, .video, and .wine.
Geographic and community-associated, with policies that vary: .africa, .bayern, .berlin, .london, .nyc, .paris, .scot, and .tokyo.
Professional or specially governed: .bank, .insurance, .law, .pharmacy, and .realtor. Eligibility may be only the first check. Some registries enforce naming, use, and security requirements throughout the registration. For example, .bank verifies registrants and monitors continuing security requirements, and unresolved noncompliance can lead to suspension.
Brand-controlled: .amazon, .apple, .bmw, and .google. These illustrate corporate control of a top-level namespace rather than public registration choice.
Internationalized, with registry-specific language and registration rules: .شبكة, .дети, .みんな, .世界, and .网络.
Use IANA's current alphabetical TLD list to confirm that an extension is delegated, and the Root Zone Database to identify its manager and delegation record. An entry marked “Not assigned” is not an active TLD. Registry policies determine eligibility and which names may be registered; participating registrars determine whether they offer the TLD and on what retail terms.
How to Choose a Domain Extension in 2026
Begin with the complete address, not the novelty of the ending. A strong domain should be easy for its intended audience to read, say, type, and remember. The words on both sides of the dot should make sense together without needing an explanation.
Before registering, check:
Availability: Is the extension active, and is the name genuinely available?
Registrant control: Will you or your organization be the Registered Name Holder, and do you control the registrar account and recovery contacts? ICANN warns that if an agency or developer registers a domain using its own details, it may become the official registrant.
Eligibility and continuing obligations: Does the registry restrict who may register, which name may be chosen, how it may be used, or which technical and security controls must remain in place? What happens if eligibility changes or compliance fails?
Continuing price: What will registration, renewal, transfer, and possible restoration cost over several years, and how much can those prices change?
Premium status: Is the chosen word priced differently from an ordinary name, including at renewal?
Audience recognition: Will the people you need to reach understand and trust the complete address?
Technical compatibility: Do forms, email providers, analytics tools, and other essential services accept the address?
Third-party rights: Search relevant trademark records and assess confusing similarity before registering. A successful UDRP complaint can result in cancellation or transfer of a domain, while the URS can suspend a domain in a clear-cut infringement case.
Provider and extension stability: How mature is the extension, how widely do registrars support it, and what alternatives do you have if its pricing, policies, or service change?
Continuity: If the domain will replace an existing address, can old page URLs be redirected and old email addresses kept working during the transition without breaking links or correspondence?
The Present Position
New domain extensions have expanded the Internet's naming system rather than replaced its older conventions. The registration data and ICANN's review support a measured conclusion: the program produced much greater choice and some additional competition, while new gTLDs remained a minority of the market. They differed widely in registration scale and restrictions, familiarity continued to favor legacy endings, and observed abuse was concentrated disproportionately in some TLDs. Not every delegated extension is public, a descriptive ending does not guarantee trust, an introductory bargain may be followed by a higher renewal price, and Google gives no special ranking weight to a keyword simply because it appears after the final dot.
The 2026 application round may expand the list again, but applications are not approvals. A proposed extension from this round will reach the root only after the relevant application succeeds, contracting and technical steps are completed, and delegation occurs. For a registrant, a new extension is a defensible choice when the complete address fits the site's identity, audience, and long-term purpose and its costs, eligibility rules, compatibility, and continuity risks are acceptable.
Further Reading
Ten Essential Starting Points
For a shorter route through the subject, begin with these ten resources.
The Internet Domain Name System Explained for Non-Experts — An accessible introduction to how names, resolvers, authoritative servers, and the root fit together. It is explanatory rather than a technical standard.
RFC 1034: Domain Names—Concepts and Facilities — The foundational description of the DNS architecture, delegation, zones, resolvers, and caching. It should be read with its later updates rather than treated as the complete modern specification.
RFC 1035: Domain Names—Implementation and Specification — The companion standard covering DNS messages, resource records, name servers, resolvers, and the original wire protocol.
RFC 9499: DNS Terminology — The best current reference for DNS vocabulary. Published in 2024, it superseded RFC 8499 and reconciles terminology that changed over several decades.
IANA Domain Name Services — The central starting point for the root zone, top-level-domain records, reserved domains, IDN practices, and root DNSSEC material.
IANA Root Zone Database — The authoritative directory of delegated top-level domains, their types, registry managers, name servers, and administrative records.
The Domain Name Registration Process — A clear explanation of the different roles played by registrants, registrars, resellers, registry operators, and ICANN.
ICANN Registration Data Lookup — The practical place to retrieve publicly available registration data and identify the registrar responsible for a domain.
New gTLD Program: 2026 Round — The official current hub for the 2026 application round, including dates, applicant material, program stages, and updates.
About ICANN and Its Multistakeholder Model — An introduction to ICANN’s limited coordinating role and the community structure through which generic-domain policy is developed.
DNS Foundations and Technical Standards
RFC 1034: Domain Names—Concepts and Facilities — Paul Mockapetris’s foundational account of the distributed naming architecture. The document remains indispensable, but its record lists numerous later RFCs that update particular parts of it.
RFC 1035: Domain Names—Implementation and Specification — Defines the original DNS message format, standard resource records, master files, name-server behavior, and resolver behavior. Its RFC Editor page also identifies the many subsequent updates.
RFC 9499: DNS Terminology — A current glossary for terms such as authoritative server, recursive resolver, forwarding, bailiwick, delegation, and negative caching. It is particularly useful when older and newer documents use the same word differently.
RFC 2181: Clarifications to the DNS Specification — Resolves important ambiguities involving data ranking, TTLs, zone authority, CNAME records, and what characters the DNS protocol itself permits in names.
RFC 6891: Extension Mechanisms for DNS (EDNS(0)) — Explains the backward-compatible mechanism that lets DNS advertise larger message sizes and additional capabilities. DNSSEC and many modern extensions depend on EDNS.
RFC 7766: DNS Transport over TCP—Implementation Requirements — Corrects the common misconception that DNS is simply a UDP protocol. It sets requirements and guidance for reliable DNS operation over TCP.
IETF Domain Name System Operations Working Group — The home of current DNS operational work in the IETF. Drafts listed here are works in progress and do not become standards merely by appearing on the working-group page.
The Internet Domain Name System Explained for Non-Experts — A readable bridge between a general web audience and the RFCs, especially useful for understanding why the DNS is distributed rather than a single global directory.
The Root Zone, IANA, and the Public DNS Namespace
IANA Domain Name Services — An overview of IANA’s domain-name functions, including root-zone coordination, the .INT and .ARPA registries, reserved names, IDN practices, and root DNSSEC operations.
Root Zone Management — Explains what the DNS root zone contains and what IANA does when recording and maintaining top-level-domain delegations.
Root Zone Database — The live delegation record for generic, country-code, sponsored, infrastructure, test, and internationalized top-level domains. It identifies who manages a TLD; it is not a retail domain-availability checker.
Root Zone Files and Downloads — Provides the root hints file, the complete root zone, and DNSSEC trust-anchor material. These files serve different operational purposes and should not be treated as interchangeable.
IANA Root Name Servers — Lists the 13 named root authorities and their operators. The 13 names do not mean that only 13 physical machines serve the root.
Root-Servers.org — The root-server operators’ live map and operational directory. It shows how the 13 logical root-server identities are delivered through a much larger global anycast deployment operated by 12 independent organizations.
IANA-Managed Reserved Domains — The authoritative reference for names reserved for documentation, testing, and special purposes, including example domains that can safely appear in published examples.
RFC 6761: Special-Use Domain Names — Defines what special-use designation means and establishes the IANA registry for names whose handling differs from ordinary public DNS names.
RFC 2826: IAB Technical Comment on the Unique DNS Root — Sets out the technical rationale for a single globally coherent public DNS namespace and explains why conflicting roots can give the same name different meanings.
Registering, Renewing, Transferring, and Protecting a Domain
The Domain Name Registration Process — Distinguishes the registry, registrar, reseller, and registrant roles. This is a useful corrective to the loose habit of calling every company that sells domains “the registry.”
Information for Domain Name Registrants — ICANN’s practical portal for domain holders, with links on registration, renewal, transfer, contact data, account protection, and complaint routes.
ICANN-Accredited Registrars — The current directory of companies accredited to register names in one or more generic top-level domains. Accreditation does not by itself compare prices, support quality, or reseller practices.
Domain Name Renewals and Expiration — Explains renewal reminders, expiration, restoration, deletion, and transfer issues. Registry and registrar grace periods can be complex, so domain holders should also check their own registration agreement.
ICANN Transfer Policy — The formal policy governing transfers between ICANN-accredited registrars. It is the correct source when a registrar’s help article and the governing rule appear to differ.
FAQs for Registrants: Transferring Your Domain Name — A plain-language guide to authorization codes, transfer locks, timing, denials, and the circumstances in which a recently registered or recently changed name may not move immediately.
EPP Status Codes — Decodes statuses such as clientTransferProhibited, redemptionPeriod, pendingDelete, and serverHold, with guidance on what each status may require a registrant to do.
About Locked Domains — Explains registrar locks and why a transfer-prohibited status can be a security protection rather than evidence that a domain is broken.
Securely Managing Your Domain Name — Collects guidance on account security, hijacking, renewal, nameserver dependencies, and the operational risks that arise when control of a registration account is lost.
About Lost Domain Names — A practical starting point when a name has expired, been transferred without authorization, or is no longer under the expected account. It also makes clear the limits of ICANN’s contractual authority.
Registration Data, RDAP, and Public Lookup
ICANN Registration Data Lookup — Searches publicly available domain-registration data and normally directs queries to the relevant authoritative RDAP service.
Registration Data Access Protocol (RDAP) — Explains the standardized, internationalization-friendly successor to WHOIS. Since January 2025, RDAP has been the definitive registration-data service for the gTLD system, subject to limited contractual exceptions.
RDAP Internet Standard, STD 95 — Brings together the core RFCs for RDAP’s HTTP use, security services, query format, JSON responses, and authoritative-service discovery.
ICANN Registration Data Policy — The policy governing collection, transfer, publication, and handling of gTLD registration data. It became effective on August 21, 2025.
Registration Data Request Service — Describes the system through which eligible requesters can submit standardized requests for nonpublic gTLD registration data to participating registrars. A request is not a guarantee of disclosure.
Applying for and Operating a New gTLD
New gTLD Program: 2026 Round — The current program home page, with official timing, announcements, the Applicant Guidebook, and links to the stages of the application process.
2026 Round Applicant Guidebook — The principal rulebook for eligibility, application types, evaluation, objections, contention, contracting, fees, and delegation. The final edition was published in December 2025.
2026 Round Resources — A consolidated directory of official videos, FAQs, guides, training, program documents, applicant-support material, and TLD Application Management System resources.
2026 Round Applicant Journey — Presents the process from preparation and submission through evaluation, community input, contention resolution, contracting, and possible delegation.
Prepare to Apply for a New gTLD — A practical pre-application checklist covering legal-entity eligibility, application types, string selection, blocked or reserved names, name-collision review, and service-provider planning.
gTLD Evaluation Fee FAQs — The current source for the base evaluation fee, payment timing, possible conditional fees, support discounts, refund windows, and volume-related adjustments.
Registry Service Provider Handbook — Explains how technical registry service providers are evaluated for the 2026 round and what capabilities they must demonstrate.
Applicant Support Program — Describes the financial and nonfinancial support framework intended for qualified applicants that otherwise face substantial resource constraints.
2026 Round Base Registry Agreement — The expected contract between ICANN and a successful new-gTLD registry operator. It reveals the continuing obligations that begin after an application succeeds.
The 2012 New gTLD Round — The official historical archive for the previous round. Its application materials are not the rules for 2026, but its outcomes and case studies provide essential institutional context.
New gTLD Case Studies — Registry-focused accounts of how selected TLDs were conceived and used after the 2012 round. They are educational profiles, not independent assessments of commercial success.
Country-Code Top-Level Domains
RFC 1591: Domain Name System Structure and Delegation — The influential 1994 statement describing TLD managers as trustees with a duty to serve their communities. ccTLD policy also depends on later ICANN processes, the local manager, and applicable law.
Qualifying Top-Level-Domain Strings — Explains how ISO 3166-1 codes, exceptional reservations, IDN Fast Track strings, infrastructure names, and approved generic strings can become eligible for the root.
Delegating or Transferring a ccTLD — IANA’s guide to the evidence, consultation, technical competence, and local support considered in a country-code delegation or transfer request.
Country Code Names Supporting Organization — The ICANN community for ccTLD managers and the policy-development body for a limited range of global ccTLD issues. Individual ccTLD registration rules remain locally determined.
CENTR TLD Market Report — Public statistics and trend analysis with a particular focus on European country-code domains. Its methodology and coverage should be considered when comparing it with global gTLD totals.
WIPO ccTLD Database — A country-by-country directory linking to registry sites, registration agreements, lookup services, and alternative dispute-resolution procedures. It is valuable precisely because ccTLD rules are not uniform.
Internationalized Domain Names and Universal Acceptance
Internationalized Domain Names — ICANN’s overview of domain names that use scripts beyond basic ASCII, including program work on top-level IDNs, variants, and label-generation rules.
IANA Repository of IDN Practices — A large collection of registry-submitted IDN tables showing the code points permitted for particular languages or scripts under particular TLDs.
ICANN IDN Implementation Guidelines — Operational guidance for TLD registries offering internationalized registrations, including requirements concerning script mixing, variants, tables, and user expectations.
RFC 5890: IDNA Definitions and Document Framework — The conceptual entry point to IDNA2008, explaining the vocabulary, architecture, and relationship among the standards that allow Unicode labels to work with the ASCII DNS.
RFC 5891: IDNA Protocol — Defines the registration and lookup protocol for internationalized labels. The companion documents RFC 5892 and RFC 5893 cover permissible Unicode code points and right-to-left scripts.
ICANN IDN Resources — A broad archive of annual reports, technical references, security analysis, board resolutions, and Root Zone Label Generation Rules material.
Universal Acceptance — Explains the requirement that applications correctly accept, validate, store, process, and display all valid domain names and email addresses, including new long TLDs and IDNs.
Universal Acceptance Steering Group Document Hub — Practical reports, developer guidance, readiness studies, and material on Email Address Internationalization. UASG is an implementation and advocacy community rather than an internet standards body.
Universal Acceptance Training — Courses and curricula for developers, system administrators, policymakers, governments, and other organizations working to make software UA-ready.
DNSSEC, DNS Privacy, Abuse, and Operational Security
RFC 4033: DNS Security Introduction and Requirements — The accessible entry point to the core DNSSEC standards. DNSSEC authenticates DNS data and protects its integrity; it does not encrypt ordinary DNS queries or website traffic.
IANA DNSSEC Information — The central resource for root-zone signing policies, audit material, trusted community representatives, ceremonies, and rollover information.
DNSSEC Trust Anchors and Rollovers — Publishes the official root trust anchors and the operational timeline for key changes. This is the authoritative page for resolver operators preparing for a root KSK rollover.
Root KSK Ceremonies — Documents the public, witnessed ceremonies through which the root Key Signing Key is used to sign operational keys and perform related cryptographic work.
Preparing for the 2026 Root KSK Rollover — Current operational guidance for the October 11, 2026 transition to KSK-2024, including the key tag that validating-resolver operators should verify.
RFC 7858: DNS over TLS — Specifies DNS carried over Transport Layer Security. It provides confidentiality for a DNS transport path but does not make a chosen resolver inherently trustworthy.
RFC 8484: DNS Queries over HTTPS — Defines DNS over HTTPS, placing DNS queries and responses inside HTTPS exchanges. Its deployment can improve transport privacy while also changing who can observe and operate resolution.
RFC 9250: DNS over QUIC — Defines a confidential DNS transport using QUIC, with different performance and connection properties from DNS over TLS and DNS over HTTPS.
RFC 9156: DNS Query Name Minimisation — Describes how recursive resolvers can avoid sending the full requested name to every server encountered during resolution, reducing unnecessary disclosure.
ICANN DNS Abuse Mitigation Program — Collects contractual requirements, compliance guidance, reporting, studies, and educational material concerning malware, botnets, phishing, pharming, and spam used to deliver those forms of abuse.
ICANN Compliance Trends on DNS Abuse — Monthly and rolling reports on complaints, investigations, notifications, and actions under the DNS-abuse obligations effective since April 2024. Complaint counts are not the same as validated abuse incidents.
Submitting a Complaint to ICANN Contractual Compliance — Explains when ICANN can review a registrar’s or registry operator’s handling of an actionable abuse report. The harmful domain generally must first be reported to the responsible contracted party.
ICANN Name Collision Resources — Explains what happens when a name intended for a private or different namespace unexpectedly resolves in the public DNS, an especially important issue when evaluating proposed TLD strings.
Rights Protection and Domain-Name Disputes
ICANN Uniform Domain-Name Dispute-Resolution Policy Overview — Introduces the administrative process used for many trademark-based disputes in the generic domain space. It does not decide every ownership, contract, defamation, or unfair-competition dispute involving a domain.
Uniform Domain-Name Dispute-Resolution Policy — The policy text incorporated into the relevant registration agreements, including the three elements a complainant must establish.
Rules for the UDRP — Sets the procedural framework for complaints, responses, panel appointments, communications, decisions, and implementation.
Approved UDRP Dispute-Resolution Providers — The official list of organizations authorized to administer UDRP proceedings.
WIPO Domain Name Dispute Resources — A substantial toolkit containing filing guidance, FAQs, case-search tools, legal indexes, model pleadings, and procedural material.
WIPO Overview 3.1 — WIPO’s current synthesis of consensus panel views on recurring substantive and procedural UDRP questions. It is highly influential but does not create binding precedent or replace the facts of an individual case.
Search WIPO Cases and Panel Decisions — Search tools for decisions, case numbers, domain names, legal topics, and panelists. Individual decisions should be read in context rather than reduced to a single quoted sentence.
Uniform Rapid Suspension — A faster, narrower mechanism for clear-cut trademark-abuse cases in covered TLDs. Its ordinary remedy is suspension rather than transfer of the name.
Trademark Clearinghouse — Explains the centralized verification system used to support Sunrise registration periods and Trademark Claims services in the new-gTLD program.
Internet Governance and Participation
About ICANN and Its Multistakeholder Model — Explains ICANN’s mission, coordinating responsibilities, organizational structure, and model of participation. ICANN does not regulate all internet content or all aspects of the domain-name market.
ICANN Bylaws — The governing document that defines ICANN’s mission, commitments, supporting organizations, advisory committees, board powers, accountability mechanisms, and community processes.
Generic Names Supporting Organization — The principal policy-development body for generic top-level domains, bringing contracted parties, businesses, intellectual-property interests, civil society, and noncommercial users into a formal process.
Governmental Advisory Committee — The forum through which national governments and intergovernmental organizations provide public-policy advice to ICANN.
At-Large Community — The structure intended to represent the interests of individual internet users within ICANN, including participation through regional organizations and At-Large Structures.
Root Server System Advisory Committee — Publishes advice on the operation, administration, security, integrity, and evolution of the public root-server system.
Security and Stability Advisory Committee — Produces technical advice and reports on risks affecting the security, stability, and integrity of the internet’s naming and address-allocation systems.
ICANN Public Comment — Lists open and completed proceedings through which documents and policy proposals receive formal community input. A submitted comment becomes part of the record but is not a vote.
ICANN Public Meetings — Agendas, schedules, recordings, transcripts, and participation information for ICANN’s public meetings, many of which can be followed remotely.
Data and Industry Measurement
Domain Name Industry Brief — Current quarterly totals and trend analysis for gTLDs and ccTLDs. The reports measure registrations, not the number of active or independently operated websites.
ICANN Open Data — Downloadable datasets, charts, and APIs relating to the domain-name system and ICANN operations. Dataset definitions and update dates matter when making comparisons.
Centralized Zone Data Service — The portal through which interested parties can request access to zone files supplied by participating gTLD registries. Access requires an account and acceptance by the relevant registry under standardized terms.
2012 New gTLD Program Statistics — Historical application figures broken down by region, application type, and string similarity. They describe the 2012 round and should not be projected automatically onto 2026.
Diagnostic and Operational Tools
DNS-OARC — A nonprofit operational and research community that publishes workshop material, tools, measurements, and post-incident analysis concerning the DNS.
DNSViz — A visual diagnostic tool for tracing DNS resolution and the DNSSEC chain of trust. It is especially useful for finding broken signatures, missing links, and delegation mistakes.
Zonemaster — An open-source testing service developed by AFNIC and the Swedish Internet Foundation that checks delegation, nameserver, consistency, connectivity, and DNSSEC conditions.
Public Suffix List — A community-maintained list used by browsers and other software to identify boundaries such as .com, .co.uk, and certain private suffixes. It is operationally important but is not the IANA root-zone database.
IANA Domain Name System Parameters — The live protocol registries for DNS resource-record types, response codes, classes, EDNS options, and other assigned values.
Standards and Historical Archives
RFC Editor Search — Searches the permanent RFC series by number, title, author, status, and date. Check an RFC’s status and update history before presenting an older document as the current rule.
IETF Datatracker — Follows working groups, Internet-Drafts, agendas, discussions, and document histories. Internet-Drafts are temporary works in progress unless and until they are approved and published as RFCs.
IANA Protocol Registries — The index of technical registries maintained under IETF policies, including the DNS parameter registries used by protocol implementers.
The History of IANA — An Internet Society timeline placing DNS coordination, Jon Postel’s work, ICANN’s creation, and the 2016 stewardship transition in historical sequence.
Legal Matters
This page was created independently of the individuals and organizations discussed, none of whom had editorial control over its contents. It contains no affiliate links, sponsored content, paid placements, or compensated endorsements. Neither the author nor this website received any payment, free or discounted product or service, preferential access, travel, hospitality, gift, or other material benefit connected with this page. Unless expressly disclosed otherwise, neither the author nor this website is affiliated with, sponsored by, endorsed by, or officially connected with any individual or organization mentioned. Names and trademarks are used only to identify the subjects discussed. A mention does not, by itself, constitute a recommendation or endorsement.
Please review the website's Privacy Policy, Disclaimer, and Further Terms.