Internationalized Domain Name Registration Guide

Internationalized domain names (IDNs) allow registration of domains that contain non-ASCII characters — accented Latin letters, Cyrillic, Arabic, Han, and many other scripts. OpenSRS supports IDN registration for every TLD whose registry publishes an IDN table. This article explains how IDN encoding works, how to submit IDN registrations, and what limitations apply.

How IDN encoding works

The DNS protocol only carries ASCII characters in domain labels. To support non-ASCII names, IDNs are encoded into Punycode (ASCII-Compatible Encoding, or ACE) before they enter the DNS. Every IDN therefore has two representations:

• Unicode form — the human-readable name, for example muenchen.de or cafe.com with accented characters.
• Punycode (ACE) form — the DNS-safe encoding, prefixed with xn--, for example xn--mnchen-3ya.de or xn--caf-dma.com.

Both forms refer to the same domain. WHOIS, the registry, and DNS use Punycode internally; browsers and email clients display Unicode where it is safe to do so.

Before you begin

• Confirm the target TLD supports IDN registration. Not every TLD does. The list changes over time — check the current OpenSRS-supported TLD list in TLD Policies.
• Identify the script (language) of the IDN. Each TLD's IDN table allows only specific scripts; mixing scripts within one domain label is generally not allowed.
• Be ready to provide the domain in either Unicode or Punycode form — OpenSRS accepts both, but normalizes to Punycode for the registry submission.
• Set the registrant's preferred locale on their contact record so WHOIS messaging arrives in a readable language.

Step 1: Choose the script and language tag

Most registries require you to declare the language or script of an IDN registration. The OpenSRS registration form asks for an IDN language tag (for example, de for German, ru for Russian, ja for Japanese). The tag tells the registry which IDN table to validate the name against.

Warning: Submitting the wrong language tag is the most common cause of IDN registration rejections. If a Han character appears in a name tagged de, the registry rejects the order even though the character is valid in another table. Match the tag to the script of the characters used.

Step 2: Enter the domain in Unicode or Punycode

In the Control Panel or RWI registration form, enter the domain in whichever form is most convenient. The system auto-detects the encoding:

• Non-ASCII characters are treated as Unicode and converted to Punycode on submission.
• An entry that starts with xn-- is treated as Punycode and used as-is.

The form displays both representations side-by-side so you can verify the conversion before continuing.

Step 3: Complete the registration

Fill the standard registrant, admin, technical, and billing contacts. WHOIS data may itself contain non-ASCII characters; OpenSRS supports UTF-8 in contact fields where the registry allows it. For TLDs that do not accept non-ASCII WHOIS data, transliterate the contact information into Latin script.

Submit the registration. The confirmation screen records the domain in Punycode — that is the canonical name from the registry's perspective. The Unicode form remains displayable in OpenSRS interfaces and customer-facing tools that support it.

Variant domains and bundled registrations

Some registries (notably .cn, .jp, and .ru) treat groups of visually or linguistically similar characters as variants of the same domain. Registering a Simplified Chinese IDN under .cn, for example, may also reserve or bundle the Traditional Chinese variant. OpenSRS surfaces variant pricing and bundling rules in the availability response.

Note: Variant bundling is a registry policy — not an OpenSRS option. The registry decides whether variants are reserved automatically, sold as a bundle, or available separately. Check the per-TLD policy in TLD Policies before quoting an IDN price.

Common limitations

• Email at IDNs is inconsistent. Many mail clients accept Unicode in the local part and domain part of an address (EAI / SMTPUTF8) but many do not. Test deliverability before relying on IDN email addresses for production traffic.
• Mixed-script labels are rejected. One label cannot mix scripts (for example, Latin + Cyrillic) under most IDN tables. The registry rejects mixed-script submissions to prevent homograph attacks.
• SSL/TLS certificates require Punycode in the certificate. When issuing certificates for IDNs, the certificate's common name and SAN entries must use the xn-- form.
• Browser display rules vary. Chrome, Firefox, and Safari display Unicode IDNs only when the entire label belongs to a trusted script for the user's locale; otherwise they show Punycode. Customers may see xn-- in their address bar even after successful registration.

Next steps

• Test resolution. Resolve both Unicode and Punycode forms after registration to confirm DNS is working. Browsers and dig both accept either form.
• Issue an SSL certificate using the Punycode form. Order the certificate against the xn-- form so browsers accept it.
• Document the customer-facing name. Record both Unicode and Punycode in your CRM so support staff can recognize the domain regardless of how it is queried.
• Cross-check eligibility for ccTLDs. Some ccTLDs restrict IDN registration to registrants with national presence. See TLD Policies.

Questions? Contact OpenSRS Support.