Internationalized Domain Names (IDNs) were introduced to make the internet more accessible to non-Latin script users. The system allows domain names to contain Unicode characters from scripts like Cyrillic, Greek, Armenian, and hundreds of others. This is a genuinely important feature for global internet access. It is also one of the most effective phishing vectors we have encountered in our research.

The core problem is simple. Many Unicode characters from different scripts are visually identical or nearly identical to Latin characters. Cyrillic "a" (U+0430) looks exactly like Latin "a" (U+0061). Cyrillic "o", "e", "p", "c", "x", and "y" are all visually indistinguishable from their Latin counterparts at normal display sizes. An attacker who registers a domain using these lookalike characters can create URLs that appear legitimate to human readers but resolve to completely different servers.

How the Attack Works

Consider the domain apple.com. An attacker can register аррle.com where the first three characters are Cyrillic "a", Cyrillic "r", and Cyrillic "r" instead of their Latin equivalents. In a browser address bar, in an email, or in a chat message, this domain looks identical to the real one. The attacker hosts a convincing login page on this domain, sends phishing links, and harvests credentials from victims who have no visual indication that anything is wrong.

This is not a theoretical attack. In 2017, researcher Xudong Zheng demonstrated a proof-of-concept with аррle.com (xn--80ak6aa92e.com in Punycode) that was visually indistinguishable from the real apple.com in several major browsers. The demonstration prompted browser vendors to update their IDN display policies, but the underlying problem remains.

Our team has catalogued hundreds of Unicode characters that serve as effective homoglyphs for Latin letters. The Cyrillic script provides the most complete coverage since it contains near-perfect matches for a, c, d, e, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, and z. But other scripts contribute too. Greek omicron matches Latin "o". Armenian characters provide matches for several Latin letters. Mathematical symbols, enclosed alphanumerics, and fullwidth characters add further possibilities.

Script Mixing and Whole-Script Attacks

There are two main categories of IDN homograph attacks. Mixed-script attacks combine characters from multiple scripts within a single domain label. Whole-script attacks use characters from only one non-Latin script, choosing a script that provides lookalikes for every character in the target domain.

Mixed-script attacks are the easier ones to detect and prevent. If a domain label contains both Latin and Cyrillic characters, something is almost certainly wrong. Modern browsers detect this and display the Punycode representation instead of the Unicode rendering, which immediately reveals the deception.

Whole-script attacks are far more difficult to mitigate. If every character in a domain label comes from the Cyrillic script, the domain is a legitimate Cyrillic IDN. Blocking or flagging it means blocking legitimate Cyrillic domains, which affects millions of real users. The word "coca" can be written entirely in Cyrillic characters that look identical to Latin ones. A domain like "coca-cola" constructed entirely from Cyrillic lookalikes passes mixed-script detection and displays as readable text.

Browser Mitigations

Browser vendors have implemented various heuristics to combat IDN homograph attacks, with varying degrees of effectiveness.

Chrome uses a set of rules that display Punycode when a domain contains characters from multiple scripts (with some exceptions for common combinations like Latin + Han). It also maintains a list of "confusable" whole-script domains and displays Punycode for those. As of Chrome 88, the browser checks single-script labels against a list of skeleton matches for popular domains.

Firefox takes a similar approach but with different thresholds. It displays Punycode for mixed-script domains and for domains that mix Latin with Cyrillic or Greek characters. Users can also set network.IDN_show_punycode to true in about:config to force Punycode display for all IDN domains, though this is not practical for users who legitimately read non-Latin scripts.

Safari blocks rendering of domains that mix scripts from a curated list of confusable combinations. Its approach is less documented than Chrome's but follows similar principles.

The fundamental limitation of browser-based mitigation is that it only protects users who view the URL in a browser address bar. Phishing links in emails, chat messages, documents, and mobile notifications display the Unicode representation. A victim who clicks a link from an email client never sees the address bar warning.

DNS-Level Prevention

This is where DNS-level filtering becomes valuable. Services like NextDNS and Pi-hole can block resolution of known homograph domains before the browser is ever involved. This provides protection regardless of how the user encounters the link.

NextDNS specifically includes an IDN homograph protection feature that detects domains using characters from multiple scripts or characters that are confusable with popular domain names. When enabled, DNS queries for these domains are blocked at the resolver level, preventing the connection entirely.

For organizations running their own DNS infrastructure, implementing homograph detection at the resolver level is straightforward. The Unicode Consortium publishes a confusables.txt file that maps characters to their visual equivalents. A DNS middleware can normalize incoming queries using this mapping and compare the result against a list of protected domains. If a query for a Cyrillic-lookalike version of a protected domain arrives, the resolver returns NXDOMAIN.

Pi-hole users can achieve similar protection through curated blocklists. Several community-maintained lists specifically target known IDN homograph domains. The limitation is that these lists are reactive - they block known malicious domains but cannot prevent new ones from resolving.

Programmatic Detection

Our team has developed internal tooling for detecting homograph domains, and the approach is simple enough that any security team can implement it. The process works in three steps.

Step 1: Generate confusable variants. For each domain you want to protect, generate all possible homograph variants by substituting each character with its confusable equivalents from the Unicode confusables database. For a short domain like "apple", this produces a manageable number of variants. For longer domains, you may need to limit substitution depth.

Step 2: Convert to Punycode and check registration. Convert each variant to its Punycode representation and perform a WHOIS lookup. If the domain is registered and you do not own it, flag it for review. Many homograph domains are registered speculatively and parked. Some are actively used for phishing.

Step 3: Monitor Certificate Transparency logs. Services like crt.sh provide real-time feeds of newly issued TLS certificates. Monitor these feeds for certificates matching your confusable variants. An attacker who registers a homograph domain and obtains a TLS certificate for it is almost certainly preparing a phishing campaign.

For automated detection in network traffic, normalizing domain names to their ASCII skeleton form is the most reliable method. The Unicode Technical Standard #39 defines a skeleton function that maps each character to a canonical form, collapsing confusable characters together. If two domains produce the same skeleton but have different actual characters, one is likely a homograph of the other.

Real-World Impact

During our research, we monitored Certificate Transparency logs for homograph variants of the top 100 most-phished domains. Over a 90-day period in mid-2020, we identified 847 certificates issued for domains that were homograph variants of major financial institutions, email providers, and social media platforms. Of those, 312 were actively serving phishing pages at the time of discovery.

The most commonly targeted brands were predictable - PayPal, Apple, Google, Microsoft, and major banks. But we also found homograph phishing targeting cryptocurrency exchanges, cloud service providers, and even bug bounty platforms. The attack surface is essentially unlimited since any domain with characters that have confusable equivalents is a potential target.

Recommendations

For end users, the most practical defense is using a DNS resolver with IDN homograph protection enabled. NextDNS provides this out of the box. Combined with a modern browser that displays Punycode for suspicious domains, this covers the majority of attack scenarios.

For organizations, proactive monitoring of homograph variants for your primary domains is essential. Register the most obvious confusable variants yourself. Monitor Certificate Transparency logs for the rest. Implement DNS-level blocking for known homograph domains on your corporate network.

For security researchers, IDN homograph attacks remain an underexplored area with significant impact. The intersection of Unicode complexity and DNS infrastructure creates a large attack surface that existing mitigations only partially address. We believe there is substantial room for improvement in both detection tooling and browser-level defenses.

The fundamental tension between internationalization and security in the domain name system is not going away. As long as visually identical characters exist across different Unicode scripts, homograph attacks will remain viable. The best we can do is build layered defenses - browser heuristics, DNS filtering, certificate monitoring, and user awareness - and continue improving each layer.