Blocking vs Allow-Listing Scripts Policy Choices

In the administration of domain name systems, especially those involving Internationalized Domain Names (IDNs), one of the most consequential and technically nuanced decisions that registries and registrars must make involves whether to implement a blocking model or an allow-listing model for Unicode scripts. This policy choice fundamentally affects how domain labels are validated, which scripts are permitted or denied, and how risks such as phishing, homograph attacks, and user confusion are managed. Both approaches come with significant trade-offs, and their impact reverberates across linguistic inclusivity, operational security, and the accessibility of the internet for non-Latin-script users.

The blocking model is rooted in the philosophy of openness with controlled restriction. Under this policy, a registry or registrar begins with a permissive default—potentially accepting all Unicode scripts—and then selectively blocks specific characters or character combinations deemed unsafe, visually ambiguous, or non-standard. This method assumes that most of the script space is usable and focuses on eliminating problematic code points, such as homoglyphs or symbols with ambiguous typographic renderings. For example, the Latin small letter “a” and the Cyrillic small letter “а” (U+0430) are nearly indistinguishable in many typefaces. In a blocking model, registries may allow both the Latin and Cyrillic scripts in general but will block registrations that include combinations of characters from both scripts, particularly when the mix could produce deceptive domain names.

Blocking models provide a degree of linguistic freedom, allowing registrants to use a wide variety of characters and scripts while relying on curated exception lists to exclude dangerous permutations. However, this flexibility also introduces a reactive security posture. As new exploits emerge or as attackers find ways to combine less-obvious character similarities, the block list must be updated continuously. This introduces an administrative burden and creates inconsistencies across registrars, especially in the absence of universally adopted confusables databases or normalization standards. Moreover, because the block lists can never be exhaustive, residual risks remain for script-mixing and visual impersonation.

In contrast, the allow-listing model takes the opposite stance: it begins with a restrictive baseline, where no scripts are permitted by default, and only explicitly approved characters or character sets are allowed. This approach is more conservative and security-focused. Registries that implement allow-lists generally define their permitted code points in the form of a Label Generation Ruleset (LGR), which is vetted through linguistic research, Unicode analysis, and policy consultation. Each TLD may publish its own LGR, detailing which scripts it supports, whether character variants are bundled, and what contextual rules apply—such as character adjacency constraints, placement rules for diacritics, or restrictions on combining marks.

Allow-listing provides a clear security advantage by dramatically reducing the attack surface. By tightly constraining the scripts that can be used, particularly within a single label, registries can minimize the risk of homograph attacks and script misuse. It also enables more consistent application of policies across registrars, as the LGRs can be standardized, versioned, and reviewed by stakeholders through ICANN’s Root Zone LGR procedure. However, this model has drawbacks in inclusivity and expressiveness. Languages that use multiple scripts—such as Japanese, which includes Kanji, Hiragana, and Katakana, or Serbian, which may use both Latin and Cyrillic—can find themselves constrained if the registry does not accommodate script plurality. Likewise, communities that depend on minority scripts or less commonly used characters may be excluded if those scripts are not included in the approved set.

These policy choices do not exist in a vacuum; they must be tailored to the nature and purpose of the top-level domain in question. For example, a registry managing a corporate brand TLD may prefer the allow-list model, restricting usage to a narrow Latin character set for strict brand consistency and phishing resistance. In contrast, a country-code TLD like .中国 (China) or .भारत (India) may adopt a carefully curated block list to maximize linguistic accessibility while safeguarding against typographic deception. Some registries adopt hybrid approaches, where a core allow-list is supplemented with a targeted block list for known confusables or deprecated code points.

The implementation of either policy must also account for variant management. Unicode characters can have visually or semantically equivalent alternatives depending on script, orthography, and regional usage. In an allow-list model, registries can predefine which variant forms are acceptable and how they are bundled or reserved. In a blocking model, handling variants becomes more complex, requiring dynamic evaluation of potential confusables at registration time. This may involve script-mixing detection algorithms, normalization routines, and comparisons against known phishing patterns.

Technical enforcement also varies. Allow-lists are often enforced at the registry level during the EPP (Extensible Provisioning Protocol) validation phase, rejecting domain creation attempts that violate LGR rules. Block lists may be enforced at the registrar level, relying on client-side validation, regular expressions, or third-party libraries such as Unicode security profiles or the Unicode Technical Standard #39, which provides guidelines for the identification of confusable characters.

International policy bodies like ICANN play a vital role in shaping the global application of these models. Through programs like the IDN Guidelines and the Root Zone LGR project, ICANN encourages registries to publish and adhere to script-specific rules that promote linguistic integrity and mitigate security concerns. However, enforcement remains decentralized, with each TLD operator ultimately responsible for interpreting and applying these recommendations within their operational and cultural context.

From a linguistic standpoint, the blocking model is more tolerant of linguistic diversity and orthographic creativity, which can be particularly important in regions with rich typographic traditions or evolving writing systems. On the other hand, the allow-list model reinforces standardization and stability, ensuring that the domain namespace does not become fragmented or unsafe due to unrestricted Unicode inclusion. The challenge lies in striking the right balance between openness and protection—facilitating the authentic use of native scripts while ensuring that bad actors cannot exploit visual ambiguity for harm.

In the broader context of internet governance, the choice between blocking and allow-listing reflects deeper philosophical differences about openness, safety, and global inclusion. Blocking models trust in user behavior and remediation, while allow-lists prioritize preemptive control. As domain names become more integral to identity, commerce, and communication in every language, the policies that govern script acceptance will shape who has a voice in the digital world and how safely they can use it.

You said:

In the administration of domain name systems, especially those involving Internationalized Domain Names (IDNs), one of the most consequential and technically nuanced decisions that registries and registrars must make involves whether to implement a blocking model or an allow-listing model for Unicode scripts. This policy choice fundamentally affects how domain labels are validated, which scripts…