Welcome to new-web-domains.com, a personal, noncommercial site examining domain names and the changing architecture of the internet. It brings together independent news, commentary, and practical notes on new top-level domains, internet governance, online identity, and the evolving web.
Written in Palo Alto by Ardan Michael Blum.
August 17, 2026
An expired domain does not necessarily return to the market as a blank slate. After it is deleted and registered by a new owner, it may still receive old traffic and email, remain linked from other websites, and carry reputation signals associated with its previous use.
In an August 14 article for IT Pro, Emma Woollacott examines Infoblox research into criminals acquiring some of these domains for scams, illegal streaming, online gambling, and malware infrastructure.
Infoblox says it observed an average of approximately 50,400 expired domains being re-registered each day across generic top-level domains during the first half of 2026. That figure rose to about 65,000 when the country-code domains available in its data were included. Roughly one fifth of the registrations it analyzed had therefore existed before. These are measurements from Infoblox’s own dataset, not an official worldwide count.
Read: “Expired domains are a goldmine for hackers”.
Note: This is an independent interpretation and summary of the article; readers should consult the original for the author’s complete findings and methodology.
August 13, 2026
At the registry level, technically yes—but only if “the same domain” means more than the same letters.
It is easy to reproduce a domain-shaped name in two naming systems. The difficult part is preventing that name from becoming two separate identities controlled by different parties.
On August 10, 2026, an ICANN-convened Technical Study Group published an initial draft report offering a preliminary answer. A generic top-level domain could be integrated with an alternative naming system, the group concludes, provided that the same string always remains under the control of the same party and strict operational requirements are met.
This is not approval for any registry to offer the service. The report is a draft, and its first public-comment period remains open until September 21, 2026, at 23:59 UTC. Individual registry services would still have to undergo the applicable ICANN evaluation and receive the necessary contractual authorization.
The global Domain Name System is the system behind conventional domains used for websites, email, and other Internet services. An alternative naming system could be a blockchain registry, a distributed ledger, or an application-specific namespace.
These systems do not necessarily answer the same kinds of questions. The DNS might associate a name with a website or mail server, while an alternative system might associate the matching name with a wallet address, account, or content identifier.
Nor do they necessarily use the same resolution technology. For blockchain naming systems specifically, ICANN’s technical introduction says resolution is not standardized: implementations may use web APIs, bespoke protocols, or browser plugins.
Consequently, matching spelling does not make two names equivalent. Nor does it make the alternative name resolve through the public DNS or work automatically on a user’s device. Depending on the system, a bridge, dedicated application support, browser plugin, or resolver configuration may still be required.
The draft calls its model “string+controller integration.”
Suppose the registry operator of a hypothetical .example top-level domain integrates its DNS registry with another naming system. The registry operator would have to control .example in both systems. Alice then registers alice.example.
Under the proposed model, the corresponding name in the alternative system must either be allocated to Alice or withheld exclusively for her. It could not be issued separately to Bob.
Alice would not have to use the name in both systems. She could operate a conventional website through the DNS while leaving the alternative version inactive. Alternatively, she could activate the name in both systems.
The central requirement is coordinated control, not simultaneous use.
“Same string” is also more exact than “looks the same.” Names must match according to DNS rules for labels, capitalization, and internationalized domain names. Visually similar Unicode characters would not be sufficient.
The real test begins after registration.
If control of alice.example passes to a new registrant, control of its alternative-system counterpart must pass with it. A transfer between registrars must likewise preserve the link. The two representations cannot be allowed to acquire different controllers during either process.
Expiration is more complicated. Suppose Alice stops renewing the DNS registration but continues to use the alternative name. The draft says the DNS version would have to remain withheld. The registry could not release it to a new DNS registrant while Alice still controlled the alternative version.
Only when the name has been disabled and deallocated across all the integrated systems could it become generally available again.
Under the draft’s specialized definition, a “suspension” blocks administrative changes without necessarily stopping resolution, and it must apply simultaneously across all integrated systems. If a name were deactivated for an external reason such as abuse or a court order, the registry would have to disable it throughout the integration. The report distinguishes those actions from a routine clientHold, which may be used for a narrower DNS purpose.
An active IETF DNSOP Internet-Draft—a work in progress, not a final standard—similarly identifies lifecycle events, domain-control validation, and synchronization mechanisms as central considerations for responsible DNS integrations.
This lifecycle problem is not merely theoretical.
A May 2026 research preprint examined integrations in which control of a DNS domain was verified when a connection was created but was not reliably checked afterward. The researchers called persistent mappings associated with expired or transferred domains “zombie linkages.”
Among the systems they measured, the authors reported that roughly 24 percent of the examined ENS on-chain imports were zombie linkages. Because the paper remains a preprint under submission, that percentage should be treated as the authors’ measurement rather than an established industry statistic. The underlying design problem is nevertheless clear: proving control once does not prove control forever.
An integration must follow the complete life of a domain—registration, renewal, transfer, expiration, and deletion.
The systems therefore need one dependable, auditable way to determine who controls the name.
The ICANN report describes two broad approaches.
The more straightforward approach would use the conventional registry’s Shared Registration System as the coordinating source. Changes would pass through the established registry infrastructure before being published into the DNS and the alternative system.
A distributed implementation could instead maintain what the report calls a Unified Source of Truth. Updates might involve pending states while a blockchain or another external system settles, but the design would still have to prevent conflicting control.
The report sketches cryptographic tokens as one possible way to demonstrate control. It also says that such a model would still have to meet applicable ICANN contractual requirements and consensus policies, including requirements involving registration data, domain-name disputes, and rapid suspension.
The difficult engineering lies in transfers, outages, and failures—not in creating the first matching record.
A credible integration also needs a way to stop safely.
ICANN’s Emergency Back-End Registry Operator program is intended to preserve specified critical registry functions when a registry encounters serious operational problems. The draft observes that an alternative-system integration appears to fall outside those critical functions and therefore may not survive emergency back-end operation.
The draft therefore recommends requiring an applicant to provide a turn-down plan explaining how the integration could be discontinued if it became nonviable. Such a plan would need to address how coordinated control would be preserved while the service was being ended.
Other questions that a proposed service would have to address include protection against network splits, data-integrity assurances for alternative-name lookups—including whether DNSSEC-like protection is needed—internationalized-name processing, anti-abuse procedures, and the application of policies such as the Uniform Domain Name Dispute Resolution Policy and Uniform Rapid Suspension System.
The integration would not make the alternative system part of the public DNS or delegate its separate namespace in the DNS root. It would not make every blockchain or alternative name universally accessible, and it would not allow an individual registrant to create a genuine registry-level integration simply by registering or minting the same spelling somewhere else.
The model is a registry-level service. An existing registry operator would have to seek approval individually through ICANN’s Registry Services Evaluation Policy process; a prospective registry could be evaluated as part of a New gTLD Program application. A technical-panel review may be required, and an approved service would need corresponding registry-agreement language.
Nothing in the ICANN report or Google Search documentation establishes a search-ranking advantage from the integration itself. The integration alone does not create another indexable web page. Google’s minimum technical requirements apply to pages, not naming-system registrations: Googlebot must be able to access a page, receive an HTTP 200 response, and find indexable content.
If equivalent content is available at more than one conventional web URL, Google may group the pages as duplicates and select a canonical. Publishers can indicate a preference with redirects, rel="canonical" annotations, and sitemap inclusion, and should link internally to the preferred URL. These are signals rather than guarantees, and Google describes redirects and canonical annotations as stronger signals than sitemap inclusion.
Can one domain work in both the DNS and an alternative naming system? Technically, yes.
But the achievement is not duplicating the label. It is maintaining one unambiguous controller through every registration, transfer, expiration, suspension, failure, and dispute.
This makes the proposal less a story about replacing the DNS than about extending a familiar name into another environment without allowing its identity to split.
Without those guarantees, the result is not one domain working in two systems. It is two different names that happen to look alike.
ICANN Technical Study Group: Initial Report on gTLD Integrations with Alternative Naming Systems, August 10, 2026.
ICANN public-comment proceeding, opened August 10, 2026.
IETF DNSOP: Integration of DNS Domain Names into Application Environments, active Internet-Draft.
ICANN OCTO-039: Introduction to Blockchain Name System Technologies, October 2024.
Zombies in Alternate Realities: The Afterlife of Domain Names in DNS Integrations, May 2026 preprint.
August 9, 2026
Most retail domain-name registrations are renewable and time-limited. A name may be registered but still lack working DNS configuration; registration alone does not publish a page.
The layers are easy to confuse because one company may sell all of them. A registrar typically handles the registration. An authoritative DNS provider publishes resource records that resolvers and clients use to locate services. A web hosting service serves the site for the domain.
Those layers can fail separately. DNS may lead to a server that has no site configured for that name. A site may be running at a host while the domain still points elsewhere. HTTPS is another layer: correct DNS and hosting can still produce a certificate warning until the host has a certificate covering the domain.
Start troubleshooting in the same order: confirm that the registration is current and controlled by the intended registrant; inspect the authoritative name servers and returned records; then verify that the web host is configured for the domain. After a recent DNS change, cached answers can disagree until the relevant cache entries expire.
Further reading: ICANN: About Domain Names and ICANN: Domain Name Industry.
July 24, 2026
For the first time since the 2012 application round, eligible organizations can apply to operate a new generic top-level domain. ICANN’s 2026 application window closes at 23:59 UTC on August 12, 2026. The required evaluation fee must reach ICANN no later than 23:59 UTC on August 19.
This is very different from registering an ordinary address beneath .com or .org. A successful applicant becomes the registry operator responsible for an entire extension and the domain names created beneath it. That role brings continuing technical, financial, security, policy, and contractual obligations.
Only eligible legal entities can apply. These include businesses, organizations, institutions, governments, and certain governmental, nongovernmental, and intergovernmental bodies. Individuals and sole proprietorships are not eligible.
The standard evaluation fee is $227,000 for each application. Conditional evaluations may require additional fees, while operating a registry creates substantial continuing costs. Qualified participants in ICANN’s Applicant Support Program may receive a significant reduction in the evaluation fee.
Applications may involve branded, community-based, geographic, general, or internationalized extensions. Closed generic applications are prohibited: an organization cannot apply for an ordinary generic term with the intention of reserving the entire extension exclusively for itself.
The round supports Internationalized Domain Names in 27 writing systems, including Arabic, Chinese, Devanagari, and Thai. This allows proposed extensions to appear in scripts beyond the basic Latin alphabet and could make the domain-name system more representative of the languages used across the world.
Each proposed extension must pass several forms of review. ICANN evaluates string similarity, technical stability, safeguards, geographic rules, and the risk of name collisions. Applicants must also demonstrate the financial, operational, and technical capacity required to run a registry. Applications for identical or confusingly similar strings may be placed into a formal contention process.
ICANN’s current projected timeline places publication of the applications around November 2026, although that date may change. Once the proposed extensions and applicants become public, governments, communities, rights holders, and other interested parties will be able to examine what has been requested.
The long-term importance of this round will depend on what applicants propose and how the resulting extensions are used. A new top-level domain has little value merely because it exists. Its success will depend on genuine adoption, public trust, responsible registry management, and Universal Acceptance by websites, email systems, browsers, and other software.
Official information: ICANN’s 2026 application deadline reminder and 2026 Round Applicant Guidebook.
July 22, 2026
On April 30, 2026, ICANN opened its latest application round for new generic top-level domains. The window closes on August 12, and proposed extensions may be submitted in 27 writing systems, including Arabic, Chinese, Devanagari and Thai. The wording matters: a script is a writing system, not a language. Arabic script, for example, is used for Arabic, Persian, Urdu and several other languages.
This is not the beginning of multilingual domain names. ICANN’s 2025 annual report on Internationalized Domain Names counted 151 delegated top-level domains representing 37 languages in 23 scripts. The 2026 round increases the range of scripts available for proposed generic extensions. It does not guarantee that applications will be submitted, approved or widely used in every one of them.
An Internationalized Domain Name, usually shortened to IDN, contains characters beyond the basic ASCII letters, numbers and hyphen historically used in web addresses. That can include Latin letters with accents as well as characters from Arabic, Hebrew, Cyrillic, Chinese, Devanagari and many other scripts. The internationalized portion may appear before the final dot, after it, or in both places.
The name exists in two related forms. A human reader may see a Unicode form known as a U-label, such as .شبكة. The Domain Name System works with a corresponding ASCII-compatible A-label, which begins with xn--. For that example, the technical form is xn--ngbc5azd. This Punycode-based representation is not a translation or a second website. It is the underlying form that allows the existing DNS infrastructure to process the same label.
Placing a name in the DNS is therefore necessary, but it is not enough. Universal Acceptance is the principle that all valid domain names and email addresses should work in internet-enabled applications, devices and systems regardless of their script, language or top-level-domain length. A commonly used framework describes five required operations: software must accept, validate, store, process and display the identifier correctly. “Valid” does not mean accepting every possible Unicode string. A name must still comply with the relevant technical standards and registry rules.
A domain can resolve correctly and open in a browser while failing somewhere else. A registration form may reject it as an invalid website. An account system may refuse the associated email address. A customer database may store the characters incorrectly, and a password-reset service may be unable to return a message to the user. Social platforms and messaging applications may display an address without turning it into a working link. Compatibility is only as strong as the least prepared component in that chain.
It is important not to overstate the browser problem. The UASG’s 2025 readiness report says major browsers now recognize, process and display IDNs correctly and generally take users to the intended website instead of treating the address as a search query. The report nevertheless identifies continuing weaknesses in account creation with local-language email addresses and in automatic link recognition, sometimes called linkification. Browsers are only the most visible part of a much larger technical environment.
Many failures begin with old assumptions written into software. A validation rule may allow only the letters a through z. Another may assume that every domain ending is two or three characters long. A database may mishandle Unicode normalization, while an interface designed entirely for left-to-right text may display an Arabic or Hebrew address confusingly. Rejecting everything unfamiliar may appear cautious, but it is not reliable security. Accepting every Unicode string without proper validation is equally unsound.
Email reveals an even deeper division. An address with an ASCII mailbox name and an internationalized domain, such as sales@internationalized-domain.example, may preserve the conventional characters before the @ sign while representing the domain through its A-label. A fully internationalized address can also contain Unicode characters in the mailbox name. That requires the broader technical framework described in RFC 6530 and the SMTPUTF8 extension in RFC 6531, together with compatible handling throughout the mail system.
A 2021 UASG examination of WordPress and selected plugins illustrated this distinction. The tested systems showed moderate support for addresses combining an ASCII mailbox name with an internationalized domain, but all failed at least part of the testing when Unicode appeared before the @ sign. That study should not be treated as a current ranking of those products. Its continuing value is conceptual: support for an IDN website does not prove support for fully internationalized email.
The human importance extends beyond technical convenience. A person should not always have to transliterate a name into unfamiliar Latin characters to find a local institution, business or public service. A familiar script can make an address easier to recognize, remember and share. Yet an IDN does not translate the material at its destination. Website owners still need to provide appropriate content, and users may face practical obstacles involving keyboards, copying, technical support and awareness of the address.
Security is the unavoidable concern. Some characters from different scripts look alike, creating opportunities for misleading names. The Unicode Consortium distinguishes several forms of confusable strings, including similarities within one script and across multiple scripts. The danger is real, but it does not make internationalized names inherently fraudulent. Visual ambiguity also exists in ASCII, where a lowercase l, an uppercase I and the number 1 may be difficult to distinguish.
Several layers of protection address this risk. ICANN’s IDN implementation guidelines call for registries to publish permitted character repertoires, consider confusing characters and generally avoid mixing scripts within a label except where an established writing system requires it. The Root Zone Label Generation Rules determine which internationalized top-level labels and related variants can be valid. Browsers also apply display policies. Chrome may show the underlying Punycode form when its rules identify a potential spoofing risk. These measures reduce danger without pretending that visual deception can be eliminated completely.
No single organization can solve the remaining problem. Registries decide which names may be registered. The DNS transports their technical representations. Browsers decide how addresses should appear. Forms, databases and identity systems must preserve and compare them correctly. Mail providers need the appropriate internationalization support. Organizations should test the entire journey: entering an address, creating an account, receiving confirmation, signing in, requesting a new password, importing contact information and exchanging email.
The 2026 application round is an important infrastructure milestone, but adding a new label to the root is only the beginning. A multilingual domain becomes genuinely useful when an ordinary person can type it, follow it, register with it, receive a message from it and return later without the surrounding software treating the address as a mistake. The success of a more inclusive naming system will ultimately be measured not by how many new extensions are approved, but by whether people can depend on them in daily life.
July 21, 2026
ICANN has completed the first interim reporting period for its inaugural Grant Program. The initiative uses proceeds from last-resort auctions held when competing applicants sought the same new top-level domain during the 2012 expansion round.
The first cycle awarded approximately $9.97 million across 23 projects. Recipients are working on IPv6 deployment in Africa, DNSSEC automation, Universal Acceptance, cybersecurity capacity, open-source infrastructure, and research into DNS resilience.
This is an unusual afterlife for domain-name competition. Money once paid to settle who would operate an extension is now supporting technical, educational, and public-interest efforts across several regions.
The reporting milestone matters because later installments depend on reviewed progress reports. Initial performance remains aligned with expectations, although many of the funded activities are still at an early stage.
For observers of new extensions, the broader lesson is that an application round has consequences long after successful strings enter the Internet’s root. Its financial legacy can shape infrastructure, security, and access for years afterward.
Read more: ICANN’s reporting update and the complete list of funded projects.
July 15, 2026
ICANN’s Board has adopted 47 recommendations intended to make transfers of generic top-level domains more secure and consistent. The changes include standardized 30-day transfer restrictions after a new registration and after a transfer between registrars. Registrars would also have up to five days to provide a Transfer Authorization Code and must notify the domain holder within 24 hours after a transfer is completed.
The changes do not take effect immediately. ICANN must first complete the implementation process, after which registrars and registry operators will need time to update their systems. For domain owners, the direction is encouraging: clearer notifications, more predictable restrictions, and fewer differences between registrars. These procedural details matter because a good transfer policy must make legitimate moves straightforward while still protecting domains from unauthorized transfers.
Sources: ICANN Board Resolution | GNSO Transfer Policy Review
July 14, 2026
Between April 5, 2024, and April 5, 2026, ICANN Contractual Compliance opened nearly 530 investigations connected to its DNS-abuse mitigation requirements and resolved more than 480. ICANN reports that about 66 percent resulted in registrars or registry operators taking action to stop abuse, while another 8 percent led to disruption measures. Its investigations directly contributed to the mitigation of more than 25,000 abusive domains. These figures cover ICANN’s defined contractual categories, not every form of online harm, but they show why enforceable obligations and transparent reporting matter. Rules become meaningful when someone measures what happens after they are introduced.
Source: www.icann.org (June 2nd).
July 14, 2026
ICANN plans to change the DNSSEC root-zone Key Signing Key on October 11, 2026. This cryptographic key helps validating DNS resolvers confirm that DNS information is authentic and has not been altered in transit. Most internet users should notice nothing, but operators using older software or manually configured trust anchors need to verify that their systems recognize the new key. It is a useful reminder that some of the internet’s most important work is almost invisible: the domain-name system remains dependable because technical changes are prepared, published, and tested long before they occur.
Source: www.icann.org/resources/press-material/release-2026-05-20-en
July 13, 2026
The first quarter of 2026 ended with approximately 392.5 million domain-name registrations across all top-level domains, according to the latest Domain Name Industry Brief. That was an increase of 5.6 million from the previous quarter and 24.1 million from a year earlier. Registrations should not be confused with active websites: some names are parked, redirected, held defensively, or never developed. Even with that limitation, the figures suggest that domain names remain an important layer of online identity while apps, social platforms, search engines, and AI systems continue to change how people reach the web.
Source: Verisign and DNIB.com
July 12, 2026
ICANN has clarified the payment deadline for organizations applying to operate a new generic top-level domain in the 2026 round.
The application-submission window still closes at 23:59 UTC on August 12, 2026. Late applications will not be accepted.
The evaluation-fee deadline now depends partly on when ICANN sends the applicant’s invoice. ICANN must receive the full evaluation fee by whichever of the following dates is later:
23:59 UTC on August 19, 2026; or
23:59 UTC seven days after the invoice was sent.
For example, if ICANN sends an invoice on August 14, payment must be received by 23:59 UTC on August 21. The clarification ensures that an applicant receiving an invoice after the application window closes still has seven days in which to make the payment.
Applicants should consult the invoice issued through the TLD Application Management System and ICANN’s current guidance rather than relying only on the general August 19 date.
Official information: ICANN’s evaluation-fee frequently asked questions and the 2026 Round Applicant Guidebook.
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.
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.
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.
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.
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.
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.
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 — 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.
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.
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.
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.
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.
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.
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.
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.
For project inquiries, corrections, accessibility assistance, or general questions:
Ardan Michael Blum
345 Forest Avenue
Palo Alto, 94301, California, United States
Telephone: +1 (650) 427-9358
Online: Contact Form