New Domain Extensions in 2026: What They Offer and How to Choose One
Updated September 29, 2026
A web address can begin explaining a project before anyone opens the page. An ending such as .events, .design, or .art can suggest its subject, while a geographic or internationalized extension can express a connection to a place, community, or language. New domain extensions have expanded the choices available to publishers, businesses, and individuals.
The practical decision involves the complete address and the arrangements behind it. Who may register the name? What will it cost to keep? Can the intended audience read it, and will essential services accept it? Understanding those questions helps distinguish a useful naming choice from an attractive first-year offer.
What a Domain Extension Is
A top-level domain, or TLD, sits immediately below the root of the Domain Name System, usually shortened to DNS. In the illustrative address localization.company, .company is the TLD and localization is the second-level label. Registration does not always take place directly beneath the TLD: in example.co.uk, .uk is the TLD, while co.uk is a public suffix under which names can be registered. The IETF's DNS terminology distinguishes these levels and registration boundaries.
Three roles explain the ordinary registration arrangement. The registry operates an extension and maintains its registration records. A registrar offers registration services to customers, and the registrant is the person or organization holding the registration. Registering a name under .events gives the registrant rights under the relevant registration agreement; it does not make that person the operator of .events.
Registration, DNS hosting, website hosting, and email hosting are separate services, even when one provider sells them together. DNS records connect the name with services such as a website or mail system. A successful registration alone does not create a working website or mailbox, as ICANN's explanation of the domain industry makes clear.
Delegation is another distinct step. For a TLD, the DNS root publishes references to the name servers responsible for that extension. Its registry may then offer registrations broadly, impose eligibility rules, withhold particular names, or operate the space for a specific organization. Delegation establishes a place in the DNS, while registry policies and launch arrangements determine registration availability.
Why They Are Still Called “New”
In this article, “new gTLDs” means the generic extensions introduced through the large-scale program that began with ICANN's 2012 application round. The word identifies a program category; many of these extensions have now been operating for more than a decade. Smaller rounds opened in 2000 and 2003 had already produced additions such as .biz, .info, .cat, and .travel.
On October 23, 2013, ICANN announced that the first four extensions from the 2012 round had been delegated. They were .شبكة, .онлайн, .сайт, and .游戏, using Arabic, Cyrillic, and Chinese writing. Other extensions followed their own delegation and registration schedules, with different rules about who could use them.
The 2012 round received 1,930 applications for approximately 1,400 unique strings, meaning proposed TLD labels. ICANN's statistics as of August 31, 2026 record 1,241 cumulative delegations. That figure is not an active-extension count: ICANN does not subtract later contract terminations or removals from the root. Dividing delegations by applications would describe an application-level outcome, not the approval rate for distinct proposed strings, because multiple applicants sometimes sought the same string.
What the Market Figures Show
The Domain Name Industry Brief for Q2 2026, sponsored by Verisign, reported 52.9 million new-gTLD registrations at June 30, out of 401.6 million registrations across its all-TLD category. That was approximately 13.2 percent. The .com total was 166.6 million, while new-gTLD registrations had increased 34.0 percent over the previous year.
These figures establish a substantial market segment. They count registrations, which may support websites, email, redirects, defensive holdings, or future projects. They do not count distinct businesses, regular visitors, or successful publications.
The same report gave its most recent combined renewal estimates as 31.0 percent for new gTLDs and 67.2 percent for legacy gTLDs excluding .com and .net. These are aggregate estimates of registration renewals, not measurements of active website use. DNIB's methodology says estimates outside .com and .net use the previous quarter's final renewal percentages or the latest available information; coverage, rounding, and later revisions also affect the data.
Renewal and active use answer different questions. A retained registration may have no public website, and a discontinued registration may have served a temporary purpose. The category also includes extensions with very different audiences and registration policies, so its combined percentage cannot establish the prospects of a particular .art, .bank, or community domain.
The Choices the Expansion Added
Descriptive Addresses
Word pairs such as localization.company, museum.art, and festival.events illustrate how the words on either side of the dot can describe a subject. They are naming illustrations, not offers of available registrations. A coherent complete address may suit a project better than a longer name chosen solely to obtain a familiar ending.
The useful test is how the intended audience understands the whole address. Ask a few prospective readers what they expect it to contain, whether they can repeat it after hearing it, and whether its spelling needs explanation. These exercises assess comprehension and recall; they do not establish that a domain will increase sales, credibility, or search traffic.
Places and Communities
Extensions such as .africa, .berlin, .london, .nyc, .paris, .scot, and .tokyo can express a geographic or community connection. Their names do not reveal their complete eligibility rules. Some accept a broad range of applicants, while others require a continuing connection or a particular use.
For example, the .tokyo registry says registration is open worldwide without a local-address requirement. The .scot registration policy requires an ongoing connection to the worldwide Scottish community through language, culture, tourism, business, or another beneficial activity, together with a declaration of intended use. A community connection can therefore matter throughout the registration, rather than only when the initial application is submitted.
Brand Extensions
Some organizations operate their own .Brand extensions. Specification 13 of ICANN's Registry Agreement restricts registrants and control of DNS records to the operator, its defined affiliates, and qualifying trademark licensees. Individual registry policies can be narrower. Ordinary customers or commercial partners do not automatically qualify.
The practical attraction is coordinated control over naming and administration. A company can organize official services, product information, or campaigns within a space governed by its own policies and ICANN agreement. Google's publication at blog.google provides a visible example of an operating brand extension.
This differs from exclusive use of a generic term for its general meaning. The 2026 Applicant Guidebook says closed-generic applications will not be approved until the required public-interest methodology and criteria exist. A dictionary word can still function as a particular brand; spelling alone does not resolve that classification. Extensions such as .apple, .bmw, .google, and .amazon illustrate brand control rather than ordinary retail registration choices.
Professional and Specially Governed Spaces
An extension can carry obligations beyond paying a registrar. Endings such as .bank, .insurance, .law, and .pharmacy have specialized eligibility or operating rules. A name that sounds appropriate for a profession is therefore not necessarily available to everyone working near that field.
The .bank implementation guide describes verification and continuing security requirements, including controls for DNS, web connections, and email. Unresolved compliance failures can lead to suspension under the registry's enforcement policy. Before choosing a restricted extension, establish both that you qualify and that your providers can maintain its requirements. Those specific safeguards do not guarantee that every transaction or item of content is safe.
More Languages and Writing Systems
Internationalized Domain Names, or IDNs, existed before the 2012 round. ICANN's first non-Latin country-code extensions entered the production root in May 2010. The later generic expansion added endings such as .شبكة, .дети, .みんな, .世界, and .网络, extending multilingual choices at the top level.
Internationalization also includes Latin letters with accents and other diacritics. A non-ASCII label that meets IDNA's rules has a Unicode form, called a U-label, and a corresponding DNS-compatible ASCII form, called an A-label. Under the IDNA framework, the conversion works label by label; A-labels begin with xn--. For example, .شبكة corresponds to xn--ngbc5azd. These are two representations of the same label, not separate names to buy.
For the 2026 round, ICANN's Root Zone Label Generation Rules cover 27 scripts or writing systems. That describes rules for proposed top-level strings, not permission to register every word or Unicode character. Registry IDN tables and policies separately determine which spellings and combinations are allowed beneath an extension.
The round also permits applications for eligible variant strings under its variant evaluation rules. A variant is a distinct label with a relationship established by the applicable rules. It is not an automatic translation, DNS alias, or approved extension, and some variants are blocked rather than available.
Search, Geography, and Trust
Search Rankings
A descriptive ending should earn its place through its usefulness to people. Google's current SEO Starter Guide says keywords in a domain name alone have little ranking effect and that, apart from country targeting, TLD choice does not matter to Google Search. Its ranking systems guide describes words in domains as one of many relevance factors and explains how its exact-match-domain system limits excessive credit. Neither statement establishes a special bonus for the word after the dot.
Geographic new gTLDs also differ from country-code targeting. Google treats city and regional generic extensions as generic, so .london does not supply the country signal associated with .uk. Some country-code extensions, including .ai and .io, are themselves treated as generic by Google. These search classifications do not change their status in the DNS; publishers still need content and appropriate regional signals that identify their intended audience.
A TLD also supplies no inherent search engine. DNS retrieves records associated with names; it does not create a content index of every website beneath an extension. A registry can separately provide a directory, and a search engine can offer filtering features, but those are additional services. This distinction follows from the DNS architecture, rather than from the descriptive meaning of an ending.
Trust and Abuse
ICANN's January 2024 overview summarized earlier competition, consumer choice, and consumer trust research. It described much greater choice, a smaller increase in competition, and limited overall change in trust. The underlying 2018 review found that familiarity favored legacy endings and that some TLDs had disproportionate levels of DNS abuse. These are historical findings, not a new survey of trust or abuse in 2026.
Since April 5, 2024, amendments to the applicable gTLD registry and registrar agreements have required appropriate mitigation of DNS abuse supported by actionable evidence. The defined category includes malware, botnets, phishing, pharming, and spam used to deliver those harms. These obligations do not make ICANN a general regulator of website content. Readers still need to examine the complete address, the organization, and the service they are using.
Choosing a Name for an Actual Project
A new project and an established website face different decisions. Consider a hypothetical designer launching a first portfolio: a .design address might express the work clearly, provided the complete name is readable, affordable, and compatible with essential services. There is no existing address to migrate, so the choice can concentrate on the audience and the project's expected future.
An established arts organization might find a community extension equally appealing, but it must also consider returning visitors, printed materials, page links, and email. A change that improves the name on a poster may require substantial work elsewhere. The naming benefit should justify that transition, or the organization can continue using its existing address.
Begin with a shortlist of complete names. Read each aloud, consider how it appears in an email address, and check whether its meaning would still fit if the project expanded. A narrow subject ending may suit a focused publication very well; a broader name may give a changing organization more room. This is a judgment about the intended use, not a rule that one extension class is universally better.
Understanding the Price
The exact name's continuing cost matters more than an extension's advertised starting price. ICANN's renewal guidance warns that introductory prices can be lower than subsequent renewals. Obtain the registration, renewal, transfer, and restoration prices for each candidate, including applicable taxes and optional recurring services.
Premium pricing needs a separate question. A registry-designated premium name may carry higher registration, renewal, or transfer fees. An existing registrant's resale asking price is a different charge, and a resold name may also retain premium renewal terms. Namecheap's explanation of these two sales models illustrates why a large purchase price tells you little about the next annual bill.
A hypothetical comparison makes the arithmetic concrete. If Name A costs USD 5 initially and USD 60 at renewal, five years cost USD 245. If Name B costs USD 30 initially and USD 30 at renewal, the same period costs USD 150. These invented figures count the first year plus four renewals, assume unchanged fees, and exclude tax and other charges. Apply the calculation to the actual quotes you receive.
Future renewal prices are not necessarily fixed. Section 2.10 of ICANN's Base Registry Agreement permits registry renewal-price increases subject to notice and pricing provisions, generally including 180 days' notice to contracted registrars with specified exceptions. These are wholesale rules; registrars set retail terms. Check the agreement applicable to the extension and the registrar's terms rather than treating today's quote as a lifetime guarantee.
Keeping Control of the Name
Before paying, establish what rights the offer provides. For an ordinary registration, confirm that you or your organization will be the Registered Name Holder. ICANN warns that an agency or developer using its own details may become the registrant instead. Domain registrations run for renewable terms, so payment does not secure a name forever.
Some specialized offerings use a different arrangement. The .realtor license agreement says the operator remains the registrant and grants the customer a license to use the name. In such a case, examine the license's renewal, transfer, termination, and recovery provisions. Access to a dashboard alone does not answer who holds the registration or what happens when the relationship ends.
Keep authorized access to the registrar account and enable multifactor authentication where available. Record how access will be recovered if the responsible person leaves, and maintain current contact details. ICANN's account-security guidance treats account protection and recovery as part of managing a domain.
Use automatic renewal where appropriate, maintain valid payment details, and keep an independent expiration reminder. Confirm that renewal actually succeeded. ICANN's expiration guidance explains that expiration can interrupt websites and email and may ultimately lead to loss of the registration. A secondary contact outside the affected domain also helps avoid depending entirely on mail that an outage could disable.
Availability and Third-Party Rights
An available name is not necessarily free of trademark conflicts. Check relevant trademark records, existing commercial uses, and the intended use of the name before registration or acquisition. Registering a domain does not itself establish trademark rights, and a database search alone cannot establish that no conflicting rights exist.
Under ICANN's Uniform Domain Name Dispute Resolution Policy, a complainant must establish all three required elements: identity or confusing similarity to its mark, lack of the registrant's rights or legitimate interests, and both bad-faith registration and bad-faith use. A successful complaint can result in cancellation or transfer. The separate Uniform Rapid Suspension procedure provides suspension for clear cases meeting its requirements and a clear-and-convincing evidence standard; it does not transfer the name to the complainant.
Testing the Address Before Launch
Forms, Stored Records, and Email
Universal Acceptance is the goal that valid domain names and email addresses work correctly across Internet-enabled systems. ICANN's UA guidance covers acceptance, validation, processing, storage, and display. A site opening successfully in a browser does not establish that a signup form, customer database, or mail service handles its address correctly.
Several problems need to be distinguished. An ordinary ASCII address under a newer or longer ending can be rejected by an outdated validation rule. An internationalized domain needs correct handling of its Unicode and encoded forms. Non-ASCII characters before the @ introduce another requirement: internationalized email support, including the SMTPUTF8 extension. Punycode handles domain labels, not the mailbox name before the @; an ASCII mailbox using an encoded IDN domain does not require SMTPUTF8 solely because of that domain.
Test the workflows you will actually depend on. Submit controlled addresses through registration and recovery forms, save and reopen them in customer records, and complete confirmation and password-reset messages. Check replies, imports, exports, and forwarding if those are part of the service. Developers should test browser and server validation and replace stale extension lists or arbitrary suffix-length limits. ICANN's UA readiness resources provide fuller testing guidance.
HTTPS and Redirects
Test each web hostname visitors will use, including the bare domain and www address where applicable. Check HTTPS, certificate coverage and renewal arrangements, redirects, forms, and sign-in. A working homepage is only one part of a working service.
Google Registry's .app and .dev extensions are included in the HSTS preload list. Browsers enforcing that list upgrade HTTP requests to HTTPS for names beneath them. Working HTTPS and a valid certificate are therefore needed even for a hostname used only to redirect visitors elsewhere; HSTS does not configure the server or issue its certificate.
HTTPS protects the connection, but Chromium's security explanation cautions against treating it as proof that a website is trustworthy. The operator and content still need to be evaluated. A technical requirement attached to an extension should be understood precisely, rather than turned into a general safety claim.
Moving an Existing Website
A domain change should begin with an inventory of dependencies. Identify important pages, downloads, email addresses, account-recovery contacts, integrations, and printed references. Prepare the destination before announcing it, and decide how each existing address will continue to work.
Google's site-migration guidance recommends permanent redirects from old URLs to their corresponding new pages, normally using HTTP 301 or 308. Sending every old page to the new homepage can discard the context readers expected. Update internal links, canonical URLs, regional annotations where used, and the sitemap; use Search Console's Change of Address process for an applicable domain move.
Keep control of the old domain and maintain redirects for as long as practical, generally at least a year under Google's guidance. Monitor indexing and traffic as the move is processed, since search visibility can fluctuate. These steps support migration but do not guarantee unchanged rankings or a particular recovery date.
Email requires its own transition plan. Web redirects do not forward messages sent to an old email address. Keep needed mailboxes or forwarding arrangements working, test delivery, and update outside accounts that use the old address. Retire the old domain only after deciding how to handle the remaining dependencies.
Where the 2026 Application Round Stands
ICANN's new application window ran from April 30 through August 12, 2026. On September 22, ICANN confirmed that 1,616 paid applications would proceed, from 1,663 submitted applications. These are applications, not a count of approved extensions or distinct names that registrants can already buy.
That announcement said Reveal Day was expected no later than October 14, absent extraordinary circumstances. ICANN planned to publish public application information through its Application Publication and Statistics system. The announcement described an expectation, not a confirmed launch date for new extensions; readers following the round should consult the current program announcements.
The pre-evaluation process includes administrative checks before publication and a period when eligible applicants can select a previously designated replacement string. A replacement substitutes for a proposal rather than adding an extra approved TLD. Evaluation, objections or contention where applicable, contracting, technical onboarding, and delegation still separate an application from an operating extension.
Applying to operate a TLD is also a different financial undertaking from registering a domain. The 2026 Guidebook gives a standard evaluation fee of USD 227,000, with support provisions, specified variant arrangements, and possible additional fees. It is not the total cost of running a registry. Buyers choosing an address today should evaluate extensions and exact names already offered under current registration rules.
A Final Check Before Registering
Use IANA's current alphabetical TLD list to check delegation and its Root Zone Database to identify the manager and record. The database retains some entries marked “Not assigned,” so appearing in that database alone does not establish current delegation. Neither source confirms that your exact name is available or that you qualify to use it.
Use these questions to compare your shortlisted names. Resolve any unanswered points before registering or committing to a migration:
Fit: Does the complete name communicate the project clearly to its intended audience?
Availability: Is this an available registration, an existing holder's resale offer, or a licensed-use arrangement?
Eligibility: Can you satisfy the registry's naming, use, and continuing technical requirements?
Cost: Have you checked the exact name's renewal and premium terms as well as its initial price?
Control: Who holds the registration, who can recover access or renew it, and what options exist for moving it to another provider?
Rights: Have you considered trademark conflicts and the proposed use?
Operation: Have the necessary web, form, database, and email workflows been tested?
Continuity: If an address is changing, are old links, correspondence, and account dependencies covered?
New extensions offer more ways to make an address fit a project. Their value emerges when the name, audience, costs, rules, and operational arrangements work together. A strong choice is one you can explain clearly and maintain reliably as the site develops.
Further Reading
Ten Essential Starting Points
For a shorter route through the subject, begin with these 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.