About New Web Domains
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.
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 17, 2026
ICANN has formed a technical study group to examine whether conventional internet domains could be integrated safely with alternative naming systems.
The global Domain Name System provides the shared structure behind familiar addresses ending in extensions such as .com, .org and newer generic top-level domains. Alternative naming systems operate differently and may exist outside the globally coordinated DNS. Some are connected to blockchain-based identity and naming projects, while others use separate technical methods.
ICANN says it may be technically possible for names from the global DNS to work within these alternative systems. Such integration could make domain-based identities more portable or useful across different online environments. It could also create serious problems if two systems interpret the same name differently or send users to different destinations.
The central issue is coordination. A domain name is dependable because users normally expect it to resolve consistently. Without suitable protocols, combining separate naming systems could produce operational failures, security risks, routing problems and confusion over which party controls a name.
The study group includes specialists associated with ENS Domains, Unstoppable Domains, Verisign, Public Interest Registry, Identity Digital, ICANN’s Security and Stability Advisory Committee and other organizations. Members are meeting weekly and will participate in two multi-day workshops. ICANN expects the resulting report to be published for public comment by mid-August 2026.
The practical lesson is that an alternative name should not automatically be treated as equivalent to a conventional internet domain. Buyers and developers need to understand where a name resolves, which applications recognize it, who controls its records and what happens if the same label exists in more than one system.
New naming technologies may eventually complement the DNS, but interoperability requires more than placing the same word in several digital systems. It requires common rules that preserve security, predictability and the expectation that an internet name leads everyone to the same place.
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.
Source: ICANN Board Resolution | Further details: 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/en/blogs/details/two-years-of-enforcing-dns-abuse-mitigation-requirements-progress-next-steps-02-06-2026-en (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/en/announcements/details/reminder-icann-2026-round-new-gtld-application-window-closes-12-august-13-07-2026-en
Information published on this website is provided for general informational purposes only and does not constitute a binding offer, agreement, or commitment to provide services. Please review the website's full Privacy Policy, Disclaimer, and Further Terms.
For project inquiries, corrections, accessibility assistance, or general questions:
Ardan Michael Blum
A. Blum Localization Services
Palo Alto, California
Telephone: +1 (650) 427-9358
Online: Contact Form