Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
obsoletes
- rfc-3490 — Internationalizing Domain Names in Applications (IDNA)
updates
- rfc-4343 — Domain Name System (DNS) Case Insensitivity Clarification
Extracted elements (25)
A-labels should be produced only in lowercase. Because the valid characters for U-labels (the source of A-labels) make mixed-case Punycode annotation of the sort described in RFC 3492 Appendix A never useful, requiring lowercase output avoids ambiguity without any practical cost.
Character ordering in labels is defined strictly by wire order—equivalent to left-to-right for LTR scripts and right-to-left for RTL scripts—to eliminate ambiguity about which character is 'first' in labels that mix reading directions.
IDNA2008 does not change Stringprep; it bypasses it entirely. This means that upgrades to other protocols that depend on Stringprep are independent of the IDNA2008 changes and can be handled by experts on those protocols without entangling IDNA concerns.
The IDNA2008 document set is split into separate normative documents (Protocol, Tables, Bidi, Definitions) and a non-normative Rationale document. This structure separates the stable technical rules from explanatory and advisory material, and allows the Tables specification to evolve with Unicode updates independently.
The term 'Punycode' is discouraged as a name or adjective for labels. Calling a label a 'Punycode string' conflates the encoding algorithm with the label form and leaves ambiguity about whether the ACE prefix is included; the terms A-label and U-label are more precise.
IDNA-unaware applications treat all LDH labels as valid and some may permit additional label types. IDNA-aware applications permit only A-labels and NR-LDH labels in DNS zone files and queries; U-labels may appear in user interface and presentation forms and in protocols that use IDNA but do not directly involve the DNS.
URI (RFC 3986), SMTP (RFC 5321), and HTTP (RFC 2616) do not permit non-ASCII labels in DNS names, allowing only A-label form of IDNs. Compatibility problems between IDNA2003 and IDNA2008 arise only for characters whose interpretation actually changed between the two versions.
R-LDH labels that are not A-labels SHOULD NOT be mixed with IDNA labels in the same DNS zone, in order to preserve the integrity of the label namespace partitioning established by IDNA.
R-LDH labels that are not prefixed with 'xn--' MUST NOT be processed as ordinary LDH labels by IDNA-conforming programs, because those labels are reserved for future use of mechanisms similar to IDNA.
U-labels and A-labels MUST contain only characters specified in the IDNA2008 document series and only in the contexts indicated as appropriate, as part of the symmetry constraint between the two label forms.
A domain name slot is a protocol element, function argument, or return value explicitly designated for carrying a domain name—such as the DNS QNAME field, the gethostbyname() argument, or the host portion of a URI. Strings with domain name syntax appearing in general text (e.g., email body) are not in domain name slots.
A Non-Reserved LDH (NR-LDH) label is a valid LDH label that does not have '--' in the third and fourth positions, and is thus neither an IDN label nor a label form reserved by IDNA. All A-labels also conform to NR-LDH hostname syntax rules other than the length restriction.
A U-label is an IDNA-valid string of Unicode characters in Normalization Form C (NFC) that includes at least one non-ASCII character, expressed in a standard Unicode Encoding Form (e.g., UTF-8). It must satisfy permitted-character constraints from the Tables document, Bidi constraints if it contains right-to-left script characters, and must exhibit a symmetry with its corresponding A-label.
An A-label is the ASCII-Compatible Encoding (ACE) form of an IDNA-valid string. It must begin with the ACE prefix 'xn--', be followed by a valid Punycode-encoded string of at most 59 ASCII characters, conform to LDH label rules, and be decodable into a valid U-label.
An IDNA-aware domain name slot is a domain name slot explicitly designated—either statically in a protocol specification or dynamically through negotiation—for carrying an internationalized domain name. Domain name slots whose specifications predate IDNA are not IDNA-aware.
An LDH label is a DNS label consisting solely of ASCII letters, digits, and the hyphen-minus character, with the constraint that hyphens cannot appear at the beginning or end of the string. Its total length must not exceed 63 octets. LDH labels are subdivided into Reserved LDH (R-LDH) and Non-Reserved LDH (NR-LDH) labels.
Label equivalence in IDNA is defined in terms of A-labels: two labels are equivalent if their A-label forms are equal under case-insensitive comparison. This covers exact U-label identity, case-insensitive A-label matching, and equivalence between a U-label and an A-label determined by translating and comparing.
Reserved LDH (R-LDH) labels, also called 'tagged domain names', are LDH labels that contain '--' in the third and fourth character positions. Only the subset beginning with the prefix 'xn--' (XN-labels) may be used in IDNA-aware applications; other R-LDH labels are reserved for future use.
The ACE prefix is the fixed ASCII string 'xn--' that appears at the beginning of every A-label. 'ACE' stands for 'ASCII-Compatible Encoding', and the prefix allows IDNA-encoded labels to be stored in the DNS using only characters permitted in standard hostnames.
XN-labels are R-LDH labels that begin with the 'xn--' prefix. Those whose remaining characters are valid Punycode output and that meet other IDNA-validity criteria are A-labels; those that fail these tests are called 'Fake A-labels'.
Differences in character interpretation between IDNA2003 and IDNA2008—particularly for characters such as ZWJ and ZWNJ that were mapped to nothing in IDNA2003 but permitted in some IDNA2008 contexts—can be exploited for name-matching or name-confusion attacks if registries do not take care to manage strings with dual interpretations.
IDNA2008 strengthens validation by rejecting putative labels containing unassigned code points (which IDNA2003 permitted). However, it no longer assumes that lookup applications can determine the protocol version used during registration, reducing pre-lookup validation ability; in practice the protection this afforded was largely illusory.
U-labels that satisfy IDNA symmetry constraints may be up to 252 Unicode code points long, far exceeding the 63-octet DNS label limit that applies to A-labels. Applications using U-labels must guard against buffer overflow and truncation errors and attacks in contexts where shorter strings are expected.
Visually similar (confusable) characters in different scripts pose a risk that users will be connected to unintended hosts. Implementations should provide visual indications when a domain name contains multiple scripts, and DNS zone administrators should impose restrictions to minimize confusable characters, though no comprehensive technical solution exists.
When local character sets other than ASCII and Unicode are used, inconsistent conversion rules between applications or versions may cause the same name to be interpreted differently and resolve to different servers. TLS and other security protocols that do not consider local character sets cannot mitigate this problem.