RFC 5890

Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework

📅 published August 2010, from ietf

RFC 5890: Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework 💖 (part 1 of 5)

okay so bestie, this is RFC 5890 🎀, written by J. Klensin and dated August 2010. It's a Standards Track doc in the ISSN 2070-1721 series, and it obsoletes RFC 3490 🦋. It's the definitions doc for the big IDNA2008 revision, so it's basically the foundation for the whole set. Here's the full vibe check ✨

Abstract ✨

so this doc is one piece of a whole collection that together describes the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), which replaces the earlier version. it explains what the collection is and gives the definitions and other stuff that every doc in the set shares 🫶

Status of This Memo 📜

this is an Internet Standards Track document. it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🔥 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). for more about Internet Standards, check Section 2 of RFC 5741.

for the current status, any errata, and how to send feedback, look at http://www.rfc-editor.org/info/rfc5890 💅

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. read those carefully, because they spell out your rights and restrictions for this doc 🙈 any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says.

this doc might contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. the people who control the copyright in some of that material may not have given the IETF Trust permission to allow changes outside the IETF Standards Process. so unless you get a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be created outside it either. the one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🫶

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
  1.1.  IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . .  4
    1.1.1.  Audiences  . . . . . . . . . . . . . . . . . . . . . .  4
    1.1.2.  Normative Language . . . . . . . . . . . . . . . . . .  5
  1.2.  Road Map of IDNA2008 Documents . . . . . . . . . . . . . .  5
2.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  6
  2.1.  Characters and Character Sets  . . . . . . . . . . . . . .  6
  2.2.  DNS-Related Terminology  . . . . . . . . . . . . . . . . .  6
  2.3.  Terminology Specific to IDNA . . . . . . . . . . . . . . .  7
    2.3.1.  LDH Label  . . . . . . . . . . . . . . . . . . . . . .  7
    2.3.2.  Terms for IDN Label Codings  . . . . . . . . . . . . . 11
      2.3.2.1.  IDNA-valid strings, A-label, and U-label . . . . . 11
      2.3.2.2.  NR-LDH Label . . . . . . . . . . . . . . . . . . . 13
      2.3.2.3.  Internationalized Domain Name and
                Internationalized Label  . . . . . . . . . . . . . 13
      2.3.2.4.  Label Equivalence  . . . . . . . . . . . . . . . . 14
      2.3.2.5.  ACE Prefix . . . . . . . . . . . . . . . . . . . . 14
      2.3.2.6.  Domain Name Slot . . . . . . . . . . . . . . . . . 14
    2.3.3.  Order of Characters in Labels  . . . . . . . . . . . . 15
    2.3.4.  Punycode is an Algorithm, Not a Name or Adjective  . . 15
3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
  4.1.  General Issues . . . . . . . . . . . . . . . . . . . . . . 16
  4.2.  U-label Lengths  . . . . . . . . . . . . . . . . . . . . . 16
  4.3.  Local Character Set Issues . . . . . . . . . . . . . . . . 17
  4.4.  Visually Similar Characters  . . . . . . . . . . . . . . . 17
  4.5.  IDNA Lookup, Registration, and the Base DNS
        Specifications . . . . . . . . . . . . . . . . . . . . . . 18
  4.6.  Legacy IDN Label Strings . . . . . . . . . . . . . . . . . 18
  4.7.  Security Differences from IDNA2003 . . . . . . . . . . . . 19
  4.8.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  6.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
  6.2.  Informative References . . . . . . . . . . . . . . . . . . 21

1. Introduction ✨

1.1. IDNA2008 🍓

this doc is one of a collection that together describes the protocol and usage context for a revision of IDNA that was mostly finished in 2008. inside the series and elsewhere it's known as "IDNA2008" 💜 the series replaces an earlier version of IDNA [RFC3490] [RFC3491], and for convenience the docs call that older version "IDNA2003". the newer version still uses the Punycode algorithm [RFC3492] and the ACE (ASCII-compatible encoding) prefix from the earlier version. the doc collection is covered in Section 1.2, and as that section says, this doc provides the definitions and other stuff the whole set has in common ✨

1.1.1. Audiences 🎀

a lot of IETF specs are written just for protocol implementers, but IDNA needs to be understood and used properly by people who make decisions about:

  • what names are permitted in DNS zone files,
  • policies related to names and naming, and
  • the handling of domain name strings in files and systems, even with no immediate intention of looking them up.

this doc, plus the docs about the protocol definition, the rules for handling strings with right-to-left characters, and the actual list of characters and categories, are the ones protocol implementers will care about most 🤓 this doc and the explainer doc are the main ones for everyone else, though they may have to fill in some details by looking at other docs in the set.

this doc and the related ones are written from the point of view of an IDNA-aware user, application, or implementation 💅 they might restate fundamental DNS rules and requirements so you don't have to hunt for them, but they don't try to cover all of DNS. they're not a substitute for really understanding the DNS protocols and specs, so go read those too 🙈

1.1.2. Normative Language 📜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in RFC 2119 [RFC2119] 🔥

1.2. Road Map of IDNA2008 Documents 🗺️

IDNA2008 is made up of these docs:

  • this doc 💖, which has the definitions and other stuff needed to understand the other docs in the set. other docs in the set informally call it "Defs" or "Definitions".
  • RFC 5894 [RFC5894] 🌸 gives an overview of the protocol and its associated tables, plus explanatory material and some rationale for the choices that led to IDNA2008. it also has advice for registry operators and people who use Internationalized Domain Names (IDNs). other docs in the set informally call it "Rationale", and it is not normative.
  • RFC 5891 [RFC5891] 🦋 describes the core IDNA2008 protocol and its operations. combined with the Bidi doc below, it explicitly updates and replaces RFC 3490. other docs informally call it "Protocol".
  • RFC 5893 [RFC5893] ✨ specifies the special rules (Bidi) for labels that contain characters written right to left.
  • RFC 5892 [RFC5892] 👑 is a spec for the categories and rules that identify the code points allowed in a label written in native character form (more specifically defined as a "U-label" in Section 2.3.2.1 below). it's based on the Unicode 5.2 [Unicode52] code point assignments plus extra rules unique to IDNA2008. the Unicode-based rules are expected to stay stable across Unicode updates, so they don't depend on Unicode versions. this spec obsoletes RFC 3941, and the IDN use of the tables it refers to. other docs informally call it "Tables".
  • a doc [IDNA2008-Mapping] that talks about mapping characters into other characters and gives guidance for doing that when it's appropriate 🧚 other docs call it "Mapping". it gives advice, and it is not a required part of IDNA.

2. Definitions and Terminology 📖

2.1. Characters and Character Sets 🔤

a code point is an integer value in the codespace of a coded character set. in Unicode, those are integers from 0 to 0x10FFFF 💜

Unicode [Unicode52] is a coded character set with somewhat over 100,000 characters assigned to code points as of version 5.2 ✨ a single Unicode code point is written as "U+" followed by four to six hexadecimal digits, and a range of Unicode code points is written as two four-to-six-digit hexadecimal numbers separated by "..", with no prefixes, like 0000..007F.

ASCII means US-ASCII [ASCII], a coded character set with 128 characters tied to code points in the range 0000..007F 🍓 Unicode is a superset of ASCII, so you can think of it as a generalization of it. it includes all the ASCII characters and links them to the equivalent code points, which is honestly iconic 🫶

"Letters" are, informally, generalizations of the ASCII idea of that term. they're characters used to write text that aren't digits, symbols, or punctuation 💅 formally, they're characters whose Unicode General Category value starts with "L" (see Section 4.5 of The Unicode Standard [Unicode52]) 🌈

Okay bestie, when we talk about the DNS, this doc basically sticks with the vocab from [RFC1034] [RFC1035], as later tweaked by [RFC1123] [RFC2181]. ✨ The word "lookup" is used for the whole combo of stuff the IDNA2008 protocol does plus the stuff a DNS resolver actually does. 🔍 Putting an entry into the DNS is called "registration", which is pretty much how people use that word everywhere else too 💅. So any DNS zone admin gets called a "registry", and "registry" and "zone administrator" mean the same thing 🫶. That's true no matter how the admin stuff is set up or where it sits in the DNS tree. More on that relationship is in the Rationale document 🌸.

Next up: the "LDH code point" 🎀. In this doc, that means the code points for ASCII letters (Unicode code points 0041..005A and 0061..007A), digits (0030..0039), and the hyphen-minus (U+002D). 🦋 "LDH" stands for "letters, digits, hyphen", but here it specifically points at the naming rules in Section 2.3.1 below 💖.

The base DNS specs [RFC1034] [RFC1035] talk about "domain names" and "hostnames", and honestly, lots of people (and some sections of those specs) use the two interchangeably 🙈. That fuzziness has caused confusion about what people actually meant, ngl 💀. This doc mostly says "domain name". When it mentions stuff like hostname syntax restrictions, it explicitly cites the document that defines them 📚. The rest of the definitions in this subsection are basically a recap 🌈. If there's any perceived difference between them and the definitions in the base DNS docs or the ones cited below, the definitions in the other documents win 👑.

A "label" is just one individual piece of a domain name 🍓. Labels are usually separated by dots, so "www.example.com" has three labels: "www", "example", and "com" ✨. (The complete name convention with a trailing dot, described in RFC 1123 [RFC1123], can be explicit like "www.example.com." or implicit like "www.example.com". This spec doesn't cover that 🙅‍♀️.) IDNA expands the set of characters that can show up in labels when they're treated as text (which is different from the binary string labels discussed in RFC 1035 and RFC 2181 [RFC2181] and the bitstring ones [RFC2673]), but only in certain contexts 💜. The different contexts for different character sets get outlined in the next section ⭐. For the rest of this doc and the related ones, "label" is shorthand for "text label", and "every label" means "every text label", including the expanded context 🫶.

2.3. Terminology Specific to IDNA 💖

This section defines some terms so we don't have to lean on words that have caused drama in the past 🙃. The relationships among these definitions are shown in Figure 1 and Figure 2 📊. In the first of those figures, the numbers in parentheses point to the notes below the figure 🔢.

2.3.1. LDH Label 🎀

This is the classic label form, with some extra restrictions, used in hostnames [RFC0952] ✨. Its syntax is identical to the "preferred name syntax" in Section 3.5 of RFC 1034 [RFC1034] as modified by RFC 1123 [RFC1123] 📖. Basically, it's a string made of ASCII letters, digits, and the hyphen, with one extra rule: the hyphen can't be at the start or end of the string 🙅‍♀️. And like all DNS labels, its total length must not exceed 63 octets 📏.

LDH labels include the special labels that IDNA uses (called "A-labels" below) and some extra restricted forms (also described below) 🦋.

IDNA introduces two new subsets of LDH labels to make things clearer 🌈. They're called Reserved LDH labels (R-LDH labels) and Non-Reserved LDH labels (NR-LDH labels) 💅. Reserved LDH labels, which are called "tagged domain names" in some other contexts, have "--" in the third and fourth characters but otherwise follow the LDH label rules 🎀. Only a subset of R-LDH labels can be used in IDNA-aware applications 👀. That subset is the labels that start with the prefix "xn--" (case doesn't matter) but otherwise follow the LDH label rules 💜. This subset is called "XN-labels" in this set of documents 📚. XN-labels are split again: some have remaining characters (after the "xn--") that are valid output of the Punycode algorithm [RFC3492], and some don't (more on that below) 🧩. The XN-labels that are valid Punycode output are called "A-labels", as long as they also meet the other IDNA-validity criteria described below ✨. Since LDH labels (and any DNS label) can't be more than 63 octets, the Punycode-derived part of an XN-label is limited to no more than 59 ASCII characters 🔢. Non-Reserved LDH labels are just the valid LDH labels that don't have "--" in the third and fourth positions 🫶.

Here's a fun consequence: because of the restrictions on valid characters in native Unicode form (see U-labels), mixed-case annotation (the kind outlined in Appendix A of RFC 3492 [RFC3492]) is never useful 🙈. So, since a valid A-label is the result of Punycode-encoding a U-label, A-labels should be produced only in lowercase, even though they match other potential labels in the DNS that are mixed-case or uppercase 🔤.

Some strings get prefixed with "xn--" to form labels, but they might not be Punycode output, might fail the other tests below, or might break other IDNA rules. Those aren't valid IDNA labels either 💀. They're called "Fake A-labels" for convenience 🎭.

Labels in the R-LDH class that don't start with "xn--" are also not valid IDNA labels 🚫. To leave room for future mechanisms similar to IDNA, those labels MUST NOT be processed as ordinary LDH labels by IDNA-conforming programs, and they SHOULD NOT be mixed with IDNA labels in the same zone 🙏.

These distinctions among possible LDH labels only matter to software that's IDNA-aware, or to future extensions that use the same "prefix and encoding" model 🧚. For IDNA-aware systems, the valid label types are: A-labels, U-labels, and NR-LDH labels 💖.

IDNA labels come in two flavors: an ACE-encoded form and a Unicode (native character) form 🌸. These are called A-labels and U-labels, respectively, and we'll dig into them in the next section 🦋.

                                 ASCII Label
  __________________________________________________________________
  |                                                                |
  |     ____________________ LDH Label (1) (4) ________________    |
  |    |  ___________________________________                  |   |
  |    |  |IDN Reserved LDH Labels          |                  |   |
  |    |  | ("??--") or R-LDH Labels        | _______________  |   |
  |    |  | _______________________________ | |NON-RESERVED |  |   |
  |    |  | |       XN-labels             | | | LDH Labels  |  |   |
  |    |  | | _____________   ___________ | | | (NR-LDH     |  |   |
  |    |  | | | A-labels  |   | Fake (3) || | |   labels)   |  |   |
  |    |  | | | "xn--"(2) |   | A-labels || | |_____________|  |   |
  |    |  | | |___________|   |__________|| |                  |   |
  |    |  | |_____________________________| |                  |   |
  |    |  |_________________________________|                  |   |
  |    |_______________________________________________________|   |
  |                                                                |
  |       _____________NON-LDH label________                       |
  |       |      ______________________    |                       |
  |       |      | Underscore labels  |    |                       |
  |       |      |  e.g., _tcp        |    |                       |
  |       |      |____________________|    |                       |
  |       |      | Labels with leading|    |                       |
  |       |      | or trailing        |    |                       |
  |       |      | hyphens "-abcd"    |    |                       |
  |       |      | or "xyz-"          |    |                       |
  |       |      | or "-uvw-"         |    |                       |
  |       |      |____________________|    |                       |
  |       |      | Labels with other  |    |                       |
  |       |      | non-LDH ASCII chars|    |                       |
  |       |      | e.g., #$%_         |    |                       |
  |       |      |____________________|    |                       |
  |       |________________________________|                       |
  |________________________________________________________________|

         (1) ASCII letters (uppercase and lowercase), digits,
                hyphen.  Hyphen may not appear in first or last
                position.  No more than 63 octets.
         (2) Note that the string following "xn--" must
                be the valid output of the Punycode algorithm
                and must be convertible into valid U-label form.
         (3) Note that a Fake A-label has a prefix "xn--"
                but the remainder of the label is NOT the valid
                output of the Punycode algorithm.
         (4) LDH label subtypes are indistinguishable to
                applications that are not IDNA-aware.

Figure 1: IDNA and Related DNS Terminology Space -- ASCII Labels
                    __________________________
                    |  Non-ASCII             |
                    |                        |
                    |    ___________________ |
                    |    | U-label (5)     | |
                    |    |_________________| |
                    |    |                 | |
                    |    |  Binary Label   | |
                    |    | (including      | |
                    |    |  high bit on)   | |
                    |    |_________________| |
                    |    |                 | |
                    |    | Bit String      | |
                    |    |   Label         | |
                    |    |_________________| |
                    |________________________|

         (5) To applications that are not IDNA-aware, U-labels
                are indistinguishable from Binary ones.

                    Figure 2: Non-ASCII Labels

2.3.2. Terms for IDN Label Codings 🦋

2.3.2.1. IDNA-valid strings, A-label, and U-label

okay so, for IDNA-aware apps there are three valid label types, bestie: A-labels, U-labels, and NR-LDH labels 🎀. Figure 1 and Figure 2 show how they relate to each other ✨.

  • IDNA-valid 💖: a string is IDNA-valid if it meets every requirement in these specs for an IDNA label. An IDNA-valid string can take either of the two forms defined right below, or it can come from the NR-LDH label subset. It also has to follow all the basic DNS rules for labels, periodt. These docs point to whichever form matters in any context where the difference counts.
  • An A-label 🦋 is the ASCII-Compatible Encoding (ACE, see Section 2.3.2.5) form of an IDNA-valid string. It has to be a complete label, because IDNA is defined for labels, not for parts of them and not for complete domain names. So by definition, every A-label begins with the IDNA ACE prefix, xn-- (see Section 2.3.2.5), followed by a string that is a valid output of the Punycode algorithm [RFC3492]. That means it's a maximum of 59 ASCII characters long. The prefix and string together have to conform to all requirements for a label that can be stored in the DNS, including the rules for LDH labels (Section 2.3.1). A string is an A-label if and only if it meets the above requirements and can be decoded into a U-label 🫶.
  • A U-label 🌸 is an IDNA-valid string of Unicode characters, in Normalization Form C (NFC) and including at least one non-ASCII character, written in a standard Unicode Encoding Form (such as UTF-8). It's also bound by the permitted-character constraints in Section 4.2 of the Protocol document, the rules in Sections 2 and 3 of the Tables document, the Bidi constraints in that document if it has any characters from right-to-left scripts, and the symmetry constraint described right below. Conversions between U-labels and A-labels are done using the "Punycode" specification [RFC3492], adding or removing the ACE prefix as needed 💅.

To be valid, U-labels and A-labels have to obey a really important symmetry constraint 👑. There are several ways to test it, but the idea is this: an A-label A1 has to be producible by converting some U-label U1, and that U-label U1 has to be producible by converting A-label A1. Among other things, this means both U-labels and A-labels have to be strings in Unicode NFC [Unicode-UAX15] normalized form. These strings MUST contain only characters specified elsewhere in this document series, and only in the contexts indicated as appropriate 🔥.

Any rules or conventions that apply to DNS labels in general apply to whichever of the U-label or A-label would be more restrictive. There are two exceptions to this principle. First, the restriction to ASCII characters does not apply to the U-label. Second, expanding an A-label into a U-label may produce strings that are much longer than the normal 63 octet DNS limit (potentially up to 252 characters), thanks to the compression efficiency of the Punycode algorithm. Such extended-length U-labels are valid from the standpoint of IDNA, but caution should be exercised, as shorter limits may be imposed by some applications ⚠️.

For context 🧚: applications that are not IDNA-aware treat all LDH labels as valid for appearance in DNS zone files and queries, and some of them may permit additional types of labels (i.e., not impose the LDH restriction). IDNA-aware applications permit only A-labels and NR-LDH labels to appear in zone files and queries. U-labels can appear, along with the other two, in presentation and user interface forms, and in protocols that use IDNA forms but that do not involve the DNS itself.

Specifically, for IDNA-aware applications and contexts, the three allowed categories are A-label, U-label, and NR-LDH label. Of the Reserved LDH labels (R-LDH labels), only A-labels are valid for IDNA use 🌈.

Strings that appear to be A-labels or U-labels are processed in various operations of the Protocol document [RFC5891]. Those strings are not yet demonstrably conformant with the conditions outlined above, because they are still in the process of validation. Such strings may be referred to as "unvalidated", "putative", or "apparent", or as being "in the form of" one of the label types, to indicate that they have not been verified to meet the specified conformance requirements 🙈.

Unvalidated A-labels are known only to be XN-labels, while Fake A-labels have been demonstrated to fail some of the A-label tests. Similarly, unvalidated U-labels are simply non-ASCII labels that may or may not meet the requirements for U-labels 💀.

2.3.2.2. NR-LDH Label

These specifications use "NR-LDH label" strictly to refer to an all-ASCII label that follows the LDH label syntax discussed in Section 2.3.1 and that is neither an IDN nor a label form reserved by IDNA (R-LDH label). It's worth stressing that all A-labels follow the "hostname" [RFC0952] rules, other than the length restriction in those rules 🍓.

2.3.2.3. Internationalized Domain Name and Internationalized Label

An "internationalized domain name" (IDN) is a domain name that contains at least one A-label or U-label, but that otherwise may contain any mixture of NR-LDH labels, A-labels, or U-labels. Just like with ASCII names, some DNS zone administrators may impose restrictions, beyond those imposed by DNS or IDNA, on the characters or strings that may be registered as labels in their zones. Because U-labels can use such a huge variety of characters, and that can cause confusion, such restrictions are mandatory for IDN registries and zones, even though the particular restrictions are not part of these specifications (the issue is discussed in more detail in Section 4.3 of the Protocol document [RFC5891]). Because these restrictions, commonly known as "registry restrictions", only affect what can be registered and not lookup processing, they have no effect on the syntax or semantics of DNS protocol messages. A query for a name that matches no records will yield the same response regardless of the reason why it is not in the zone. Clients issuing queries or interpreting responses cannot be assumed to have any knowledge of zone-specific restrictions or conventions. See the section on registration policy in the Rationale document [RFC5894] for additional discussion 🦋.

"Internationalized label" is used when a term is needed to refer to a single label of an IDN, i.e., one that might be any of an NR-LDH label, A-label, or U-label. There are some standardized DNS label formats, such as the "underscore labels" used for service location (SRV) records [RFC2782], that do not fall into any of the three categories and hence are not internationalized labels 🌸.

2.3.2.4. Label Equivalence

In IDNA, equivalence of labels is defined in terms of the A-labels. If the A-labels are equal in a case-independent comparison, then the labels are considered equivalent, no matter how they are represented. Because of the isomorphism of A-labels and U-labels in IDNA2008, it is possible to compare U-labels directly; see the Protocol document [RFC5891] for details. Traditional LDH labels already have a notion of equivalence: within that list of characters, uppercase and lowercase are considered equivalent. The IDNA notion of equivalence is an extension of that older notion, but, because the protocol does not specify any mandatory mapping and only those isomorphic forms are considered, the only equivalents are:

  • Exact (bit-string identity) matches between a pair of U-labels.
  • Matches between a pair of A-labels, using normal DNS case-insensitive matching rules.
  • Equivalence between a U-label and an A-label, determined by translating the U-label form into an A-label form and then testing for a match between the A-labels using normal DNS case-insensitive matching rules 💜.

2.3.2.5. ACE Prefix

The "ACE prefix" is defined in this document to be a string of ASCII characters, "xn--", that appears at the beginning of every A-label. "ACE" stands for "ASCII-Compatible Encoding" 🎀.

2.3.2.6. Domain Name Slot

A "domain name slot" is defined in this document to be a protocol element, a function argument, a return value (and so on) explicitly designated for carrying a domain name. Examples of domain name slots include the QNAME field of a DNS query; the name argument of the gethostbyname() or getaddrinfo() standard C library functions; the part of an email address following the at sign ("@") in the parameter to the SMTP MAIL or RCPT commands, or the "From:" field of an email message header; and the host portion of the URI in the "src" attribute of an HTML "<IMG>" tag. A string that has the syntax of a domain name but that appears in general text is not in a domain name slot. For example, a domain name appearing in the plain text body of an email message is not occupying a domain name slot 📬.

An "IDNA-aware domain name slot" is defined for this set of documents to be a domain name slot explicitly designated for carrying an internationalized domain name as defined in this document. The designation may be static (for example, in the specification of the protocol or interface) or dynamic (for example, as a result of negotiation in an interactive session) 💖.

Name slots that are not IDNA-aware obviously include any domain name slot whose specification predates IDNA. Note that the requirements of some protocols that use the DNS for data storage prevent the use of IDNs. For example, the format required for the underscore labels used by the service location protocol [RFC2782] precludes representation of a non-ASCII label in the DNS using A-labels, because those SRV-related labels have to start with underscores. Of course, non-ASCII IDN labels may be part of a domain name that also includes underscore labels 🧚.

2.3.3. Order of Characters in Labels

Because IDN labels may contain characters that are read, and preferentially displayed, from right to left, there is a potential ambiguity about which character in a label is "first". For the purposes of these specifications, labels are considered, and characters numbered, strictly in the order in which they appear "on the wire". That order is equivalent to the leftmost character being treated as first in a label that is read left to right, and to the rightmost character being first in a label that is read right to left. The Bidi specification contains additional discussion of the conditions that influence reading order 🔥.

2.3.4. Punycode is an Algorithm, Not a Name or Adjective

There has been some confusion about whether a "Punycode string" does or does not include the ACE prefix, and about whether it is required that such strings could have been the output of the ToASCII operation (see RFC 3490, Section 4 [RFC3490]). This specification discourages the use of the term "Punycode" to describe anything but the encoding method and algorithm of RFC 3492 [RFC3492]. The terms defined above are preferred, as much more clear than the term "Punycode string" 💅✨.

3. IANA Considerations 📋✨

okay so the IANA stuff for IDNA2008 lives in the Tables document [RFC5892] 📚 if you want the big picture of how all the IANA registries vibe together, the Rationale document [RFC5894] has the overview 🫶. The main thing to know is that this document does not specify any actions for IANA, so there's nothing to do here for them 💅

4. Security Considerations 🔐💀

bestie, this is the serious part, so put your listening ears on 👂 everything in here keeps its full weight, no cap

4.1. General Issues 🌐

security on the Internet partly relies on the DNS 😭 so any change to the characteristics of the DNS can change the security of a huge chunk of the Internet

domain names are how users find and connect to Internet hosts and other network resources. the security of the Internet is compromised if a user types in a single internationalized name and ends up connected to different servers, because different systems interpreted that name differently 💀 on top of the characters that IDNA2003 and its mapping conventions already allow (see Section 4.6), this specification changes how a few characters are interpreted, and those characters were mapped to other characters in the earlier version. zone administrators should be aware of the problems this might raise and take appropriate measures 🚨 the context for this issue is covered in more detail in the Rationale document [RFC5894]

also, in addition to the Security Considerations material in this document, the Bidi document [RFC5893] talks about security issues specific to labels containing characters from scripts that are normally written right to left ↔️

4.2. U-label Lengths 📏

labels tied to the DNS have traditionally been limited to 63 octets, thanks to the general restrictions in RFC 1035 and the need to treat them as a six-bit string length followed by the string in actual calls to the DNS. that format shows up in some other applications too, and representations of domain names as dot-separated labels and as length-string pairs have generally been treated as interchangeable 🔄

here's the twist: A-labels (the form actually used in the DNS) are potentially much more compressed than UTF-8, and UTF-8 is, in general, more compressed than UTF-16 or UTF-32 🤯 so U-labels that obey all of the relevant symmetry (and other) constraints of these documents can be quite a bit longer, potentially up to 252 characters (Unicode code points). a fully-qualified domain name with several of those labels can obviously also go past the nominal 255 octet limit for such names 😱

application authors using U-labels must exert due caution to avoid buffer overflow and truncation errors and attacks in contexts where shorter strings are expected. this one is not optional, bestie 🛑

4.3. Local Character Set Issues 🗂️

when systems use local character sets other than ASCII and Unicode, these specifications leave the problem of converting between the local character set and Unicode up to the application or local system 🤷‍♀️ if different applications (or different versions of one application) implement different rules for converting among coded character sets, they could interpret the same name differently and contact different servers. this is not solved by security protocols, such as Transport Layer Security (TLS) [RFC5246], that do not take local character sets into account 🙈

4.4. Visually Similar Characters 👀

to help prevent confusion between characters that look alike (sometimes called "confusables"), it is suggested that implementations provide visual indications where a domain name contains multiple scripts 🎨 especially when the scripts contain characters that are easily confused visually, like an omicron in Greek mixed with Latin text. these mechanisms can also show when a name mixes Simplified Chinese characters with Traditional ones that have Simplified forms, or help tell zero and one apart from uppercase "O" and lowercase "L" 🔍 DNS zone administrators may impose restrictions (subject to the limitations identified elsewhere in these documents) that try to minimize characters with similar appearance or similar interpretations 💅

if multiple characters appear in a label and the label consists only of characters from one script, individual characters that might be confused with others if compared separately may be unambiguous and non-confusing ✨ on the other hand, that observation makes labels containing characters from more than one script (often called "mixed-script labels") even more risky 🚩 users tend to see what they expect to see, and context is a powerful reinforcement to perception 🙃 at the same time, while the risks with mixed-script labels are clear, simply prohibiting them won't eliminate problems, especially where closely related scripts are involved. for example, there are many strings written entirely in Greek or Cyrillic that can be confused with each other or with Latin script strings 🌍

it's worth noting that there are no comprehensive technical solutions to confusable characters. you can reduce the extent of the problems in various ways, but you'll probably never eliminate them 😮‍💨 some specific suggestions about identifying and handling confusable characters appear in a Unicode Consortium publication [Unicode-UTR36] 📖

4.5. IDNA Lookup, Registration, and the Base DNS Specifications 🔎

the Protocol specification [RFC5891] describes procedures for registering and looking up labels that aren't compatible with the preferred syntax in the base DNS specifications (see Section 2.3.1) because they contain non-ASCII characters 🌏 these procedures depend on a special ASCII-compatible encoding form that contains only characters permitted in hostnames by those earlier specifications. the encoding used is Punycode [RFC3492] 🧩 no security issues such as string length increases or new allowed values are introduced by the encoding process or by using these encoded values, apart from those introduced by the ACE encoding itself 🫧

domain names (or portions of them) are sometimes compared against a set of domains to get special treatment if a match occurs, e.g., treated as more privileged than others or blocked in some way 🚧 in those situations it's especially important that the comparisons are done properly, as specified in the "Requirements" section of the Protocol document [RFC5891] 💯 for labels already in ASCII form, the proper comparison reduces to the same case-insensitive ASCII comparison that has always been used for ASCII labels. IDNA-aware applications are expected to look up only A-labels and NR-LDH labels, i.e., to avoid looking up R-LDH labels that are not A-labels 🙅‍♀️

the introduction of IDNA meant that any existing labels starting with the ACE prefix would be construed as A-labels, at least until they failed one of the relevant tests, whether or not that was the intent of the zone administrator or registrant 😬 there's no evidence this has caused any practical problems since RFC 3490 was adopted, but the risk still exists in principle 🤞

4.6. Legacy IDN Label Strings 📜

the URI Standard [RFC3986] and a number of application specifications (e.g., SMTP [RFC5321] and HTTP [RFC2616]) do not permit non-ASCII labels in DNS names used with those protocols 🙅 in other words, only the A-label form of IDNs is permitted in those contexts. if only A-labels are used, differences in interpretation between IDNA2003 and this version arise only for characters whose interpretation has actually changed (e.g., characters like ZWJ and ZWNJ, which were mapped to nothing in IDNA2003 and are considered legitimate in some contexts by these specifications) 🪄

despite that prohibition, there are a significant number of files and databases on the Internet where domain name strings appear in native-character form 🗃️ a subset of those strings use native-character labels that require IDNA2003 mapping to produce valid A-labels. the treatment of such labels will vary by type of application and application-designer preference: in some situations, warnings to the user or outright rejection may be appropriate; in others, it may be preferable to try the earlier mappings if lookup strictly conformant to these specifications fails, or even to look up under both sets of rules 🎭 this general situation is discussed in more detail in the Rationale document [RFC5894]

however, without care from registries about how strings that could have different interpretations under IDNA2003 and this specification are handled, the differences could be used as a component of name-matching or name-confusion attacks 😈 such care is therefore appropriate 🛡️

4.7. Security Differences from IDNA2003 ⚖️

the registration and lookup models in this set of documents change the mechanisms available for lookup applications to determine the validity of labels they encounter. in some respects, the ability to test is strengthened ✅ for example, putative labels containing unassigned code points will now be rejected, while IDNA2003 permitted them (see the Rationale document [RFC5894] for a discussion of the reasons for this) 🔒 on the other hand, the Protocol specification no longer assumes that the application that looks up a name will be able to determine, and apply, information about the protocol version used in registration 🤔 in theory, that may increase risk since the application will be able to do less pre-lookup validation. in practice, the protection that test afforded has been largely illusory, for reasons explained in RFC 4690 [RFC4690] and elsewhere in these documents 🫠

any change to the Stringprep [RFC3454] procedure that is profiled and used in IDNA2003, or, more broadly, to the IETF's model of using internationalized character strings in different protocols, creates some risk of inadvertent changes to those protocols, invalidating deployed applications or databases, and so on 😵 but these specifications do not change Stringprep at all; they merely bypass it 🏃‍♀️ because these documents do not depend on Stringprep, the question of upgrading other protocols that do have that dependency can be left to experts on those protocols. the IDNA changes and possible upgrades to security protocols or conventions are independent issues 🧁

4.8. Summary 🌸

no mechanism involving names or identifiers alone can protect against a wide variety of security threats and attacks that are largely independent of the naming or identification system 🙃 these attacks include spoofed pages, DNS query trapping and diversion, and so on 🪤

5. Acknowledgments 🫶🎀

the initial version of this document was created largely by extracting text from early draft versions of the Rationale document [RFC5894] 📝 see the section of this name and the one entitled "Contributors" in it 💜

specific textual suggestions after the extraction process came from Vint Cerf, Lisa Dusseault, Bill McQuillan, Andrew Sullivan, and Ken Whistler 🌈 other changes were made in response to more general comments, lists of concerns, or specific errors from participants in the Working Group and other observers, including Lyman Chapin, James Mitchell, Subramanian Moonesamy, and Dan Winship ✨

6. References 📚

6.1. Normative References ✨

okay bestie, here's the reading list the spec leans on hardest 📚💅 these are the ones it treats as required reading.

  • [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
  • [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms, Revision 31", September 2009, <http://www.unicode.org/reports/tr15/tr15-31.html>.
  • [Unicode52] The Unicode Consortium. The Unicode Standard, Version 5.2.0, defined by: "The Unicode Standard, Version 5.2.0", (Mountain View, CA: The Unicode Consortium, 2009. ISBN 978-1-936213-00-9). <http://www.unicode.org/versions/Unicode5.2.0/>.

6.2. Informative References 🦋

and these are the extra reads 🧚 helpful background, good for the group chat, not strictly required.

  • [IDNA2008-Mapping] Resnick, P. and P. Hoffman, "Mapping Characters in Internationalized Domain Names for Applications (IDNA)", Work in Progress, April 2010.
  • [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
  • [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
  • [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
  • [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
  • [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
  • [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
  • [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
  • [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
  • [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
  • [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
  • [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
  • [Unicode-UTR36] The Unicode Consortium, "Unicode Technical Report #36: Unicode Security Considerations, Revision 7", July 2008, <http://www.unicode.org/reports/tr36/tr36-7.html>.

Author's Address 💌

John C Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA  02140
USA

Phone: +1 617 245 1457
EMail: john+ietf@jck.com
📦 where this page comes from