Internationalizing Domain Names in Applications (IDNA)
obsoleted by
Extracted elements (31)
IDNA applicability depends entirely on the DNS CLASS (IN vs. non-IN) and not on the resource record TYPE, to avoid type-specific complexity. This will remain true even as new types are defined unless there is a compelling reason.
IDNA is contained entirely within applications and requires no changes to DNS servers, resolvers, or protocol elements, because the ASCII name service provided by existing DNS is entirely sufficient. This enables IDNs to be introduced with no changes to any shared infrastructure.
IDNA uses the Unicode character repertoire rather than a new domain-specific character set, to avoid significant delays inherent in waiting for a separate character set to be defined by another standards body.
ToUnicode is specified to never fail — if any step fails, the original input is returned immediately. This design ensures that a display path always produces some output, preferring to show raw ACE over breaking the application.
Existing DNS servers must be shielded from non-ASCII IDN forms. All channels through which names enter a DNS server (master files, DNS update messages) predate IDNA and are IDN-unaware; requirement 2 ensures names are already in ASCII by the time they enter the server database.
For DNSSEC to work correctly with IDNs, any proxies or forwarders that transform user input into IDNs (applying ToASCII) must be earlier in the resolution flow than DNSSEC-authenticating nameservers.
IDNA does not apply to domain names in the NAME and RDATA fields of DNS resource records whose CLASS is not IN. This exclusion covers every non-IN class, present and future, unless a future standard explicitly invites IDNA use.
IDNA does not update existing email standards for address local parts. A domain label holding an email local part SHOULD NOT begin with the ACE prefix, and even if it does, it is interpreted literally rather than as an ACE label.
ACE labels obtained from domain name slots SHOULD be hidden from users when it is known that the environment can handle the non-ACE form, except when the ACE form is explicitly requested. When requirements 2 and 3 both apply, requirement 2 (ASCII-only in IDN-unaware slots) takes precedence.
Applications MUST prepare labels that are passed to the resolver library using the ToASCII operation, because resolver libraries today expect only domain names in ASCII.
For internationalized labels that cannot be represented directly in ASCII, DNS servers MUST use the ACE form produced by the ToASCII operation. All IDNs served by DNS servers MUST contain only ASCII characters.
IDNA-aware applications MUST be able to work with both non-internationalized labels (those conforming to STD13 and STD3) and internationalized labels.
If any step of the ToASCII operation fails on any label in a domain name, that domain name MUST NOT be used as an internationalized domain name; the method for dealing with this failure is application-specific.
Implementations MUST NOT use more recent Unicode normalization tables than the one referenced from this document. If an application is unsure which version of the normalization tables is in the operating system, it must include the normalization tables itself.
Implementations of IDNA MUST fully implement Nameprep and Punycode; neither Nameprep nor Punycode are optional.
In the presence of DNSSEC, the ASCII domain name (ACE form) is the name that MUST be signed in the zone and MUST be validated against; DNSSEC authenticates the ASCII form, not the Unicode form.
Whenever a domain name is put into an IDN-unaware domain name slot, it MUST contain only ASCII characters. An internationalized domain name can be converted by applying ToASCII to each label and changing all label separators to U+002E.
Whenever dots are used as label separators, the following characters MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full stop).
Whenever two labels are compared, they MUST be considered to match if and only if they are equivalent — their ASCII forms (obtained by applying ToASCII) match using a case-insensitive ASCII comparison. Whenever two names are compared, they MUST be considered to match if and only if their corresponding labels match, regardless of label separator form.
A 'domain name slot' is a protocol element, function argument, or return value explicitly designated for carrying a domain name. Examples include the DNS QNAME field, gethostbyname() argument, and the host portion of a URI. General text that merely contains a domain name is not a domain name slot.
An ACE label is any label that the ToUnicode operation would alter. Every ACE label begins with the ACE prefix. ACE labels are unsuitable for display to users; applications should apply ToUnicode before display.
LDH code points are defined as the ASCII letters, digits, and hyphen-minus: U+002D, 30..39, 41..5A, and 61..7A. These are the characters permitted in traditional host name labels under STD3.
The ACE prefix is 'xn--' (or any capitalization thereof), two alphanumeric ASCII characters followed by two hyphen-minuses. ToASCII and ToUnicode MUST recognize it in a case-insensitive manner. Excluded historical prefixes include 'bl--', 'bq--', 'dq--', 'lq--', 'mq--', 'ra--', 'wq--', and 'zq--'.
The AllowUnassigned flag and UseSTD3ASCIIRules flag are inputs to ToASCII and ToUnicode. AllowUnassigned is set for 'query' strings per Stringprep rules; UseSTD3ASCIIRules triggers additional checks prohibiting non-LDH ASCII code points and leading/trailing hyphen-minus.
The ToASCII operation takes a sequence of Unicode code points making up one label and transforms it into a sequence of ASCII code points (0..7F). It applies Nameprep, validates LDH and hyphen rules if UseSTD3ASCIIRules is set, verifies the label does not already begin with the ACE prefix, encodes with Punycode, prepends the ACE prefix, and verifies the result is 1–63 code points.
The ToUnicode operation takes a sequence of Unicode code points for one label and returns a Unicode sequence. If the input is an ACE label, it decodes the Punycode portion after removing the ACE prefix, applies ToASCII to the result, and verifies it matches the saved ACE label. ToUnicode never fails; if any step fails, the original input is returned unchanged.
IANA has assigned the ACE prefix 'xn--' in consultation with the IESG. This is the sole IANA action required by RFC 3490.
If different applications implement different transcoding rules between local character sets and Unicode, they could interpret the same internationalized name differently and contact different servers. This problem is not solved by TLS or other security protocols that do not account for local character sets.
Implementations must not use more recent Unicode normalization tables than those referenced by this specification. Using different normalization tables could cause two applications to produce different ASCII encodings for the same input name, with security and operational implications.
To help prevent confusion between visually similar characters (homographs), implementations should provide visual indications when a domain name contains multiple scripts, and DNS zone administrators may impose registration restrictions to minimize homograph risks.
When domain names are compared against privileged or anti-privileged sets, comparisons MUST be done per section 3.1 requirement 4 (ToASCII equivalence, case-insensitive). Any existing labels that start with the ACE prefix and would be altered by ToUnicode are automatically treated as ACE labels equivalent to non-ASCII labels.