Internationalized Domain Names in Applications (IDNA): Protocol
obsoletes
- rfc-3490 — Internationalizing Domain Names in Applications (IDNA)
- rfc-3491 — Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)
updates
- rfc-3492 — Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)
Extracted elements (29)
IDNA does not require any changes to DNS servers, resolvers, or DNS protocol elements because the ASCII name service provided by the existing DNS is sufficient. A-labels serve as the DNS-compatible representation of internationalized labels.
IDNA2008 is Unicode-version agnostic, unlike IDNA2003 which was pegged to Unicode 3.2. Character validity is determined by Unicode properties plus a small human-curated exclusion list rather than a fixed table, allowing the protocol to evolve with Unicode.
Mapping and normalization steps were removed from the IDNA2008 protocol itself and delegated to applications before invoking the protocol, enabling locale-specific behavior without embedding it in the standard. This is a major change from IDNA2003.
Registries are permitted and encouraged to impose additional restrictions beyond the protocol rules (Section 4.3) because policy about permissible labels is language- and script-dependent and cannot be fully captured in a universal protocol specification.
The registration and lookup protocols are intentionally separate with different strictness: registration enforces maximum validity to protect the DNS namespace, while lookup is more permissive to avoid blocking resolution of labels that exist in the DNS even if locally unvalidated.
During lookup, CONTEXTO characters need only have a rule defined (not necessarily evaluated), whereas CONTEXTJ characters require full contextual rule evaluation. This asymmetry is intentional to balance protection with lookup performance.
IDNA-aware protocols and implementations MAY accept U-labels, A-labels, or both. IDNA is not defined for extended label types (RFC 2671 Section 3).
IDNA does not update existing email standards: although an email local part may be stored in a domain-name-like format in DNS (e.g., SOA RNAME), IDNA does not enable non-ASCII characters in those local parts, which remain ASCII-only per email standards.
A label's Unicode string MUST NOT contain '--' (two consecutive hyphens) in the third and fourth character positions and MUST NOT start or end with a '-' (hyphen).
Applications resolving DNS names MUST rely on the presence or absence of labels in the DNS to determine validity for strings that pass the explicit lookup checks; applications that decline to process a conforming string are not in conformance with this protocol.
By the time a string enters the IDNA registration process, it MUST be in Unicode and in Normalization Form C (NFC). Registries MUST accept only the exact string for which registration is requested, free of any mappings or local adjustments.
During lookup, putative U-labels that are not in NFC, contain '--' in positions 3-4, begin with a combining mark, contain DISALLOWED code points, fail CONTEXTJ rules, lack defined CONTEXTO rules, or contain UNASSIGNED code points MUST be rejected prior to DNS lookup.
IDNs in older protocols not explicitly upgraded to support IDNs MUST be in A-label form. IDNs actually appearing in DNS queries or responses MUST be A-labels.
If a proposed label contains any characters from right-to-left scripts, it MUST meet the Bidi criteria specified in RFC 5893.
If an A-label is converted to U-label form during lookup using the Punycode decoding algorithm, the processing in Sections 5.4 and 5.5 MUST be performed, and the label MUST be rejected if the re-encoded result is not identical to the original A-label.
Labels MUST be compared using equivalent forms: either both A-label or both U-label. A-labels MUST be compared as case-insensitive ASCII; U-labels MUST be compared as-is, without case folding.
Strings that appear to be A-labels (start with 'xn--') but are not valid A-labels per Punycode encoding rules MUST NOT be placed in DNS zones that support IDNA.
The candidate Unicode string MUST NOT contain characters that appear in the DISALLOWED and UNASSIGNED lists specified in the Tables document (RFC 5892).
The result of converting a lookup string to Unicode MUST be a Unicode string in NFC form.
The Unicode string for a label MUST NOT begin with a combining mark or combining character as defined in The Unicode Standard Section 2.11.
The Unicode string MUST NOT contain any characters whose validity is context-dependent unless positively confirmed by a contextual rule. Each CONTEXTJ or CONTEXTO code point MUST have a non-null rule; if the rule is missing, null, or produces a negative result, the label is invalid.
When both U-label and A-label forms are available at registration, the registry MUST ensure the A-label is lowercase, convert to a U-label, validate it, and verify the re-encoded A-label matches the provided input; if any test fails, the registration MUST be rejected.
Whenever a domain name is placed into a non-IDNA-aware domain name slot, it MUST contain only ASCII characters (i.e., its labels must be either A-labels or NR-LDH labels).
A U-label is a Unicode string that contains at least one non-ASCII character, passes all label validation tests in Section 4.2.3, and is 63 or fewer characters long in ACE form. It is the canonical human-readable form of an internationalized label.
An A-label is produced by encoding a U-label with the Punycode algorithm (RFC 3492) and prepending the ACE prefix 'xn--'. The Punycode algorithm itself is not altered by this document.
IDNA applies only to domain names in the NAME and RDATA fields of DNS resource records whose CLASS is IN, regardless of the record TYPE (unless a new TYPE defines TYPE-specific rules). Special underscore labels (e.g., SRV) are incompatible with IDNA coding.
The IDNA lookup protocol (Section 5) defines a sequential process: accept local-charset string, convert to Unicode NFC, optionally process A-label input, apply validation/character-list testing, convert to ACE via Punycode, and perform DNS resolution. Lookup validation is more permissive than registration.
The IDNA registration protocol (Section 4) defines a sequential process: accept NFC Unicode input, reject disallowed/unassigned characters, perform label validation (hyphen, combining mark, contextual rules, Bidi), apply registry restrictions, convert to A-label via Punycode, then insert in the DNS zone.
To avoid intentional or accidental attacks from visually confusable labels and rendering problems, the IDNA model requires that registries exercise care and thoughtfulness about what labels they permit. Security considerations for IDNA2008 also reference RFC 5890 (definitions) and RFC 5893 (Bidi/RTL scripts).