About New Web Domains
News, commentary, and practical notes on domain names, new top-level domains, internet governance, online identity, and the evolving structure of the web.
Written and curated by Ardan Michael Blum.
News, commentary, and practical notes on domain names, new top-level domains, internet governance, online identity, and the evolving structure of the web.
Written and curated by Ardan Michael Blum.
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 20, 2026
For the first time since 2012, 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 payment must arrive no later than August 19.
This is very different from registering an ordinary address beneath .com or .org. A successful participant becomes responsible for an entire extension and the names created beneath it. That role carries continuing technical, financial, security, and policy obligations.
The base evaluation fee is $227,000 for each submission. Conditional reviews and long-term operating costs may add considerably more. The program is therefore aimed primarily at established businesses, communities, governments, institutions, and registry enterprises rather than individual domain investors.
Possible proposals include branded, geographic, community-based, and general terms. The round also supports Internationalized Domain Names in 27 scripts, allowing more identities to appear in writing systems beyond the basic Latin alphabet.
Every proposed string must pass several forms of examination. Reviewers consider similarity to other names, geographic significance, potential collisions, DNS stability, and the organization’s operational capacity. Competing requests for the same or confusingly similar extension may enter a formal contention process.
The most interesting consequences will appear after the applications become public. Names selected during this round could influence the visible structure of the web for years. Their lasting value, however, will depend on genuine use, public trust, and Universal Acceptance by websites, email systems, browsers, and other software.
Read More: ICANN’s application deadline reminder
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 reminded organizations that applications for its 2026 new generic top-level domain round must be submitted by 23:59 UTC on August 12. The evaluation fee is due by August 19. An applicant is not simply registering another website address; it is applying to operate an entire extension—the part appearing to the right of the dot. This could produce new domains for brands, communities, cities, industries, and languages. The important question will be whether they become useful and trusted online spaces rather than merely more digital inventory.
Source: www.icann.org
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.
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