Every Unicode domain name has two bodies. One is what humans see — the display form, with its diacritics, scripts, and sacred accents. The other is what the DNS sees — the ASCII-Compatible Encoding (ACE) form, prefixed with xn-- and generated by the Punycode algorithm. Understanding the split between these two bodies is the first step toward building an authentic Unicode web.
The Two Layers of an Internationalized Domain
The Domain Name System was designed in the 1980s to accept only a limited subset of ASCII: letters, digits, and hyphens. That design is still with us. When you register a name such as zeús.com, the registrar does not store the Unicode string in the root zone. It stores the Punycode translation: xn--zes-9na.com.
The display form and the ACE form are logically the same domain, but they are not visually the same string. This duality is the source of both opportunity and risk. Opportunity, because it lets the web speak in its own scripts. Risk, because a user who sees zeús.com may not realize that the underlying certificate, DNS record, and WHOIS entry all reference xn--zes-9na.com.
How PUNYCODEX Computes the Mapping
When the PÚNYCODEX type tool receives an ASCII query such as zeus, it does not simply prepend diacritics. It looks up the entry in the canonical lexicon (type/js/lexicon.js), retrieves the attested Unicode restoration, and then computes the Punycode equivalent for domain registration purposes.
- Nameprep / UTS #46. The Unicode string is mapped, normalized (NFKC or NFC), and checked for allowed code points. IDNA2008 defines a Protocol Validity List of labels and scripts that may be used in the DNS.
- Punycode encoding. The normalized Unicode label is passed through the Bootstring algorithm described in RFC 3492, producing an ASCII string beginning with
xn--. - Validation. The resulting ACE label must pass DNS length limits and IDNA2008 contextual rules. Combining marks, for example, must be applied to valid base characters in the correct order.
For Zeus, the fully restored display form is zeús.com, but the ACE form that actually travels through the resolver chain is xn--zes-9na.com. Both are correct; neither is a corruption of the other. They are simply two views of the same identifier.
Why Browsers Hide the Truth
Modern browsers are deliberately bilingual. They show the Unicode form in the address bar when they judge it safe to do so, and they fall back to the xn-- form when the label might be used for spoofing. The decision depends on mixed-script checks, top-level domain policy, and user locale.
This hiding is usually helpful, but it can also create a false sense of security. A domain that looks Greek may actually be a homograph attack assembled from Cyrillic or Latin look-alikes. That is why PÚNYCODEX maintains an authenticity layer: every owned flagship domain is vetted against the canonical lexicon, and every temple page discloses both the display form and the ACE form of the primary domain.
The Cultural Cost of Invisibility
There is a deeper cost to the xn-- prefix than mere ugliness. When the DNS only speaks ASCII, the public record of a culture's name is stored in a script that culture never used. A Greek god's name, encoded for the router, is no longer Greek. It is a string of Latin letters, digits, and hyphens prefixed with an artificial marker.
PÚNYCODEX treats this invisibility as a design problem to solve, not a fact to accept. The search engine indexes both forms; the temple pages display both forms; the lexicon stores the scholarly restoration as the canonical source. The ACE form is a transport detail. The display form is the name.
If you want to see the mapping for yourself, visit the temple of Zeus or explore the authenticity framework that keeps the display form honest.