7Internet Engineering Task Force (IETF) J. Klensin
8Request for Comments: 5890 August 2010
10Category: Standards Track
14 Internationalized Domain Names for Applications (IDNA):
15 Definitions and Document Framework
19 This document is one of a collection that, together, describe the
20 protocol and usage context for a revision of Internationalized Domain
21 Names for Applications (IDNA), superseding the earlier version. It
22 describes the document collection and provides definitions and other
23 material that are common to the set.
27 This is an Internet Standards Track document.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc5890.
58Klensin Standards Track [Page 1]
60RFC 5890 IDNA Definitions August 2010
65 Copyright (c) 2010 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
78 This document may contain material from IETF Documents or IETF
79 Contributions published or made publicly available before November
80 10, 2008. The person(s) controlling the copyright in some of this
81 material may not have granted the IETF Trust the right to allow
82 modifications of such material outside the IETF Standards Process.
83 Without obtaining an adequate license from the person(s) controlling
84 the copyright in such materials, this document may not be modified
85 outside the IETF Standards Process, and derivative works of it may
86 not be created outside the IETF Standards Process, except to format
87 it for publication as an RFC or to translate it into languages other
114Klensin Standards Track [Page 2]
116RFC 5890 IDNA Definitions August 2010
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
122 1.1. IDNA2008 . . . . . . . . . . . . . . . . . . . . . . . . . 4
123 1.1.1. Audiences . . . . . . . . . . . . . . . . . . . . . . 4
124 1.1.2. Normative Language . . . . . . . . . . . . . . . . . . 5
125 1.2. Road Map of IDNA2008 Documents . . . . . . . . . . . . . . 5
126 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 6
127 2.1. Characters and Character Sets . . . . . . . . . . . . . . 6
128 2.2. DNS-Related Terminology . . . . . . . . . . . . . . . . . 6
129 2.3. Terminology Specific to IDNA . . . . . . . . . . . . . . . 7
130 2.3.1. LDH Label . . . . . . . . . . . . . . . . . . . . . . 7
131 2.3.2. Terms for IDN Label Codings . . . . . . . . . . . . . 11
132 2.3.2.1. IDNA-valid strings, A-label, and U-label . . . . . 11
133 2.3.2.2. NR-LDH Label . . . . . . . . . . . . . . . . . . . 13
134 2.3.2.3. Internationalized Domain Name and
135 Internationalized Label . . . . . . . . . . . . . 13
136 2.3.2.4. Label Equivalence . . . . . . . . . . . . . . . . 14
137 2.3.2.5. ACE Prefix . . . . . . . . . . . . . . . . . . . . 14
138 2.3.2.6. Domain Name Slot . . . . . . . . . . . . . . . . . 14
139 2.3.3. Order of Characters in Labels . . . . . . . . . . . . 15
140 2.3.4. Punycode is an Algorithm, Not a Name or Adjective . . 15
141 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
142 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
143 4.1. General Issues . . . . . . . . . . . . . . . . . . . . . . 16
144 4.2. U-label Lengths . . . . . . . . . . . . . . . . . . . . . 16
145 4.3. Local Character Set Issues . . . . . . . . . . . . . . . . 17
146 4.4. Visually Similar Characters . . . . . . . . . . . . . . . 17
147 4.5. IDNA Lookup, Registration, and the Base DNS
148 Specifications . . . . . . . . . . . . . . . . . . . . . . 18
149 4.6. Legacy IDN Label Strings . . . . . . . . . . . . . . . . . 18
150 4.7. Security Differences from IDNA2003 . . . . . . . . . . . . 19
151 4.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20
152 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
153 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
154 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
155 6.2. Informative References . . . . . . . . . . . . . . . . . . 21
170Klensin Standards Track [Page 3]
172RFC 5890 IDNA Definitions August 2010
179 This document is one of a collection that, together, describe the
180 protocol and usage context for a revision of Internationalized Domain
181 Names for Applications (IDNA) that was largely completed in 2008,
182 known within the series and elsewhere as "IDNA2008". The series
183 replaces an earlier version of IDNA [RFC3490] [RFC3491]. For
184 convenience, that version of IDNA is referred to in these documents
185 as "IDNA2003". The newer version continues to use the Punycode
186 algorithm [RFC3492] and ACE (ASCII-compatible encoding) prefix from
187 that earlier version. The document collection is described in
188 Section 1.2. As indicated there, this document provides definitions
189 and other material that are common to the set.
193 While many IETF specifications are directed exclusively to protocol
194 implementers, the character of IDNA requires that it be understood
195 and properly used by those whose responsibilities include making
198 o what names are permitted in DNS zone files,
200 o policies related to names and naming, and
202 o the handling of domain name strings in files and systems, even
203 with no immediate intention of looking them up.
205 This document and those documents concerned with the protocol
206 definition, rules for handling strings that include characters
207 written right to left, and the actual list of characters and
208 categories will be of primary interest to protocol implementers.
209 This document and the one containing explanatory material will be of
210 primary interest to others, although they may have to fill in some
211 details by reference to other documents in the set.
213 This document and the associated ones are written from the
214 perspective of an IDNA-aware user, application, or implementation.
215 While they may reiterate fundamental DNS rules and requirements for
216 the convenience of the reader, they make no attempt to be
217 comprehensive about DNS principles and should not be considered as a
218 substitute for a thorough understanding of the DNS protocols and
226Klensin Standards Track [Page 4]
228RFC 5890 IDNA Definitions August 2010
2311.1.2. Normative Language
233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
235 document are to be interpreted as described in RFC 2119 [RFC2119].
2371.2. Road Map of IDNA2008 Documents
239 IDNA2008 consists of the following documents:
241 o This document, containing definitions and other material that are
242 needed for understanding other documents in the set. It is
243 referred to informally in other documents in the set as "Defs" or
246 o A document, RFC 5894 [RFC5894], that provides an overview of the
247 protocol and associated tables together with explanatory material
248 and some rationale for the decisions that led to IDNA2008. That
249 document also contains advice for registry operations and those
250 who use Internationalized Domain Names (IDNs). It is referred to
251 informally in other documents in the set as "Rationale". It is
254 o A document, RFC 5891 [RFC5891], that describes the core IDNA2008
255 protocol and its operations. In combination with the Bidi
256 document, described immediately below, it explicitly updates and
257 replaces RFC 3490. It is referred to informally in other
258 documents in the set as "Protocol".
260 o A document, RFC 5893 [RFC5893], that specifies special rules
261 (Bidi) for labels that contain characters that are written from
264 o A specification, RFC 5892 [RFC5892], of the categories and rules
265 that identify the code points allowed in a label written in native
266 character form (defined more specifically as a "U-label" in
267 Section 2.3.2.1 below), based on Unicode 5.2 [Unicode52] code
268 point assignments and additional rules unique to IDNA2008. The
269 Unicode-based rules are expected to be stable across Unicode
270 updates and hence independent of Unicode versions. That
271 specification obsoletes RFC 3941 and IDN use of the tables to
272 which it refers. It is referred to informally in other documents
273 in the set as "Tables".
282Klensin Standards Track [Page 5]
284RFC 5890 IDNA Definitions August 2010
287 o A document [IDNA2008-Mapping] that discusses the issue of mapping
288 characters into other characters and that provides guidance for
289 doing so when that is appropriate. That document, referred to
290 informally as "Mapping", provides advice; it is not a required
2932. Definitions and Terminology
2952.1. Characters and Character Sets
297 A code point is an integer value in the codespace of a coded
298 character set. In Unicode, these are integers from 0 to 0x10FFFF.
300 Unicode [Unicode52] is a coded character set containing somewhat over
301 100,000 characters assigned to code points as of version 5.2. A
302 single Unicode code point is denoted in these documents by "U+"
303 followed by four to six hexadecimal digits, while a range of Unicode
304 code points is denoted by two four to six digit hexadecimal numbers
305 separated by "..", with no prefixes.
307 ASCII means US-ASCII [ASCII], a coded character set containing 128
308 characters associated with code points in the range 0000..007F.
309 Unicode is a superset of ASCII and may be thought of as a
310 generalization of it; it includes all the ASCII characters and
311 associates them with the equivalent code points.
313 "Letters" are, informally, generalizations from the ASCII and
314 common-sense understanding of that term, i.e., characters that are
315 used to write text and that are not digits, symbols, or punctuation.
316 Formally, they are characters with a Unicode General Category value
317 starting in "L" (see Section 4.5 of The Unicode Standard
3202.2. DNS-Related Terminology
322 When discussing the DNS, this document generally assumes the
323 terminology used in the DNS specifications [RFC1034] [RFC1035] as
324 subsequently modified [RFC1123] [RFC2181]. The term "lookup" is used
325 to describe the combination of operations performed by the IDNA2008
326 protocol and those actually performed by a DNS resolver. The process
327 of placing an entry into the DNS is referred to as "registration".
328 This is similar to common contemporary usage of that term in other
329 contexts. Consequently, any DNS zone administration is described as
330 a "registry", and the terms "registry" and "zone administrator" are
331 used interchangeably, regardless of the actual administrative
332 arrangements or level in the DNS tree. More details about that
333 relationship are included in the Rationale document.
338Klensin Standards Track [Page 6]
340RFC 5890 IDNA Definitions August 2010
343 The term "LDH code point" is defined in this document to refer to the
344 code points associated with ASCII letters (Unicode code points
345 0041..005A and 0061..007A), digits (0030..0039), and the hyphen-minus
346 (U+002D). "LDH" is an abbreviation for "letters, digits, hyphen" but
347 is used specifically in this document to refer to the set of naming
348 rules described in Section 2.3.1 below.
350 The base DNS specifications [RFC1034] [RFC1035] discuss "domain
351 names" and "hostnames", but many people use the terms
352 interchangeably, as do sections of these specifications. Lack of
353 clarity about that terminology has contributed to confusion about
354 intent in some cases. These documents generally use the term "domain
355 name". When they refer to, e.g., hostname syntax restrictions, they
356 explicitly cite the relevant defining documents. The remaining
357 definitions in this subsection are essentially a review: if there is
358 any perceived difference between those definitions and the
359 definitions in the base DNS documents or those cited below, the
360 definitions in the other documents take precedence.
362 A label is an individual component of a domain name. Labels are
363 usually shown separated by dots; for example, the domain name
364 "www.example.com" is composed of three labels: "www", "example", and
365 "com". (The complete name convention using a trailing dot described
366 in RFC 1123 [RFC1123], which can be explicit as in "www.example.com."
367 or implicit as in "www.example.com", is not considered in this
368 specification.) IDNA extends the set of usable characters in labels
369 that are treated as text (as distinct from the binary string labels
370 discussed in RFC 1035 and RFC 2181 [RFC2181] and bitstring ones
371 [RFC2673]), but only in certain contexts. The different contexts for
372 different sets of usable characters are outlined in the next section.
373 For the rest of this document and in the related ones, the term
374 "label" is shorthand for "text label", and "every label" means "every
375 text label", including the expanded context.
3772.3. Terminology Specific to IDNA
379 This section defines some terminology to reduce dependence on terms
380 and definitions that have been problematic in the past. The
381 relationships among these definitions are illustrated in Figure 1 and
382 Figure 2. In the first of those figures, the parenthesized numbers
383 refer to the notes below the figure.
387 This is the classical label form used, albeit with some additional
388 restrictions, in hostnames [RFC0952]. Its syntax is identical to
389 that described as the "preferred name syntax" in Section 3.5 of RFC
390 1034 [RFC1034] as modified by RFC 1123 [RFC1123]. Briefly, it is a
394Klensin Standards Track [Page 7]
396RFC 5890 IDNA Definitions August 2010
399 string consisting of ASCII letters, digits, and the hyphen with the
400 further restriction that the hyphen cannot appear at the beginning or
401 end of the string. Like all DNS labels, its total length must not
404 LDH labels include the specialized labels used by IDNA (described as
405 "A-labels" below) and some additional restricted forms (also
408 To facilitate clear description, two new subsets of LDH labels are
409 created by the introduction of IDNA. These are called Reserved LDH
410 labels (R-LDH labels) and Non-Reserved LDH labels (NR-LDH labels).
411 Reserved LDH labels, known as "tagged domain names" in some other
412 contexts, have the property that they contain "--" in the third and
413 fourth characters but which otherwise conform to LDH label rules.
414 Only a subset of the R-LDH labels can be used in IDNA-aware
415 applications. That subset consists of the class of labels that begin
416 with the prefix "xn--" (case independent), but otherwise conform to
417 the rules for LDH labels. That subset is called "XN-labels" in this
418 set of documents. XN-labels are further divided into those whose
419 remaining characters (after the "xn--") are valid output of the
420 Punycode algorithm [RFC3492] and those that are not (see below). The
421 XN-labels that are valid Punycode output are known as "A-labels" if
422 they also meet the other criteria for IDNA-validity described below.
423 Because LDH labels (and, indeed, any DNS label) must not be more than
424 63 octets in length, the portion of an XN-label derived from the
425 Punycode algorithm is limited to no more than 59 ASCII characters.
426 Non-Reserved LDH labels are the set of valid LDH labels that do not
427 have "--" in the third and fourth positions.
429 A consequence of the restrictions on valid characters in the native
430 Unicode character form (see U-labels) turns out to be that mixed-case
431 annotation, of the sort outlined in Appendix A of RFC 3492 [RFC3492],
432 is never useful. Therefore, since a valid A-label is the result of
433 Punycode encoding of a U-label, A-labels should be produced only in
434 lowercase, despite matching other (mixed-case or uppercase) potential
437 Some strings that are prefixed with "xn--" to form labels may not be
438 the output of the Punycode algorithm, may fail the other tests
439 outlined below, or may violate other IDNA restrictions and thus are
440 also not valid IDNA labels. They are called "Fake A-labels" for
443 Labels within the class of R-LDH labels that are not prefixed with
444 "xn--" are also not valid IDNA labels. To allow for future use of
445 mechanisms similar to IDNA, those labels MUST NOT be processed as
450Klensin Standards Track [Page 8]
452RFC 5890 IDNA Definitions August 2010
455 ordinary LDH labels by IDNA-conforming programs and SHOULD NOT be
456 mixed with IDNA labels in the same zone.
458 These distinctions among possible LDH labels are only of significance
459 for software that is IDNA-aware or for future extensions that use
460 extensions based on the same "prefix and encoding" model. For
461 IDNA-aware systems, the valid label types are: A-labels, U-labels,
464 IDNA labels come in two flavors: an ACE-encoded form and a Unicode
465 (native character) form. These are referred to as A-labels and
466 U-labels, respectively, and are described in detail in the next
506Klensin Standards Track [Page 9]
508RFC 5890 IDNA Definitions August 2010
512 __________________________________________________________________
514 | ____________________ LDH Label (1) (4) ________________ |
515 | | ___________________________________ | |
516 | | |IDN Reserved LDH Labels | | |
517 | | | ("??--") or R-LDH Labels | _______________ | |
518 | | | _______________________________ | |NON-RESERVED | | |
519 | | | | XN-labels | | | LDH Labels | | |
520 | | | | _____________ ___________ | | | (NR-LDH | | |
521 | | | | | A-labels | | Fake (3) || | | labels) | | |
522 | | | | | "xn--"(2) | | A-labels || | |_____________| | |
523 | | | | |___________| |__________|| | | |
524 | | | |_____________________________| | | |
525 | | |_________________________________| | |
526 | |_______________________________________________________| |
528 | _____________NON-LDH label________ |
529 | | ______________________ | |
530 | | | Underscore labels | | |
531 | | | e.g., _tcp | | |
532 | | |____________________| | |
533 | | | Labels with leading| | |
534 | | | or trailing | | |
535 | | | hyphens "-abcd" | | |
536 | | | or "xyz-" | | |
537 | | | or "-uvw-" | | |
538 | | |____________________| | |
539 | | | Labels with other | | |
540 | | | non-LDH ASCII chars| | |
541 | | | e.g., #$%_ | | |
542 | | |____________________| | |
543 | |________________________________| |
544 |________________________________________________________________|
546 (1) ASCII letters (uppercase and lowercase), digits,
547 hyphen. Hyphen may not appear in first or last
548 position. No more than 63 octets.
549 (2) Note that the string following "xn--" must
550 be the valid output of the Punycode algorithm
551 and must be convertible into valid U-label form.
552 (3) Note that a Fake A-label has a prefix "xn--"
553 but the remainder of the label is NOT the valid
554 output of the Punycode algorithm.
555 (4) LDH label subtypes are indistinguishable to
556 applications that are not IDNA-aware.
558 Figure 1: IDNA and Related DNS Terminology Space -- ASCII Labels
562Klensin Standards Track [Page 10]
564RFC 5890 IDNA Definitions August 2010
567 __________________________
570 | ___________________ |
572 | |_________________| |
577 | |_________________| |
581 | |_________________| |
582 |________________________|
584 (5) To applications that are not IDNA-aware, U-labels
585 are indistinguishable from Binary ones.
587 Figure 2: Non-ASCII Labels
5892.3.2. Terms for IDN Label Codings
5912.3.2.1. IDNA-valid strings, A-label, and U-label
593 For IDNA-aware applications, the three types of valid labels are
594 "A-labels", "U-labels", and "NR-LDH labels", each of which is defined
595 below. The relationships among them are illustrated in Figure 1 and
598 o A string is "IDNA-valid" if it meets all of the requirements of
599 these specifications for an IDNA label. IDNA-valid strings may
600 appear in either of the two forms defined immediately below, or
601 may be drawn from the NR-LDH label subset. IDNA-valid strings
602 must also conform to all basic DNS requirements for labels. These
603 documents make specific reference to the form appropriate to any
604 context in which the distinction is important.
606 o An "A-label" is the ASCII-Compatible Encoding (ACE, see
607 Section 2.3.2.5) form of an IDNA-valid string. It must be a
608 complete label: IDNA is defined for labels, not for parts of them
609 and not for complete domain names. This means, by definition,
610 that every A-label will begin with the IDNA ACE prefix, "xn--"
611 (see Section 2.3.2.5), followed by a string that is a valid output
612 of the Punycode algorithm [RFC3492] and hence a maximum of 59
613 ASCII characters in length. The prefix and string together must
614 conform to all requirements for a label that can be stored in the
618Klensin Standards Track [Page 11]
620RFC 5890 IDNA Definitions August 2010
623 DNS including conformance to the rules for LDH labels
624 (Section 2.3.1). If and only if a string meeting the above
625 requirements can be decoded into a U-label is it an A-label.
627 o A "U-label" is an IDNA-valid string of Unicode characters, in
628 Normalization Form C (NFC) and including at least one non-ASCII
629 character, expressed in a standard Unicode Encoding Form (such as
630 UTF-8). It is also subject to the constraints about permitted
631 characters that are specified in Section 4.2 of the Protocol
632 document and the rules in the Sections 2 and 3 of the Tables
633 document, the Bidi constraints in that document if it contains any
634 character from scripts that are written right to left, and the
635 symmetry constraint described immediately below. Conversions
636 between U-labels and A-labels are performed according to the
637 "Punycode" specification [RFC3492], adding or removing the ACE
640 To be valid, U-labels and A-labels must obey an important symmetry
641 constraint. While that constraint may be tested in any of several
642 ways, an A-label A1 must be capable of being produced by conversion
643 from a U-label U1, and that U-label U1 must be capable of being
644 produced by conversion from A-label A1. Among other things, this
645 implies that both U-labels and A-labels must be strings in Unicode
646 NFC [Unicode-UAX15] normalized form. These strings MUST contain only
647 characters specified elsewhere in this document series, and only in
648 the contexts indicated as appropriate.
650 Any rules or conventions that apply to DNS labels in general apply to
651 whichever of the U-label or A-label would be more restrictive. There
652 are two exceptions to this principle. First, the restriction to
653 ASCII characters does not apply to the U-label. Second, expansion of
654 the A-label form to a U-label may produce strings that are much
655 longer than the normal 63 octet DNS limit (potentially up to 252
656 characters) due to the compression efficiency of the Punycode
657 algorithm. Such extended-length U-labels are valid from the
658 standpoint of IDNA, but caution should be exercised as shorter limits
659 may be imposed by some applications.
661 For context, applications that are not IDNA-aware treat all LDH
662 labels as valid for appearance in DNS zone files and queries and some
663 of them may permit additional types of labels (i.e., not impose the
664 LDH restriction). IDNA-aware applications permit only A-labels and
665 NR-LDH labels to appear in zone files and queries. U-labels can
666 appear, along with the other two, in presentation and user interface
667 forms, and in protocols that use IDNA forms but that do not involve
674Klensin Standards Track [Page 12]
676RFC 5890 IDNA Definitions August 2010
679 Specifically, for IDNA-aware applications and contexts, the three
680 allowed categories are A-label, U-label, and NR-LDH label. Of the
681 Reserved LDH labels (R-LDH labels) only A-labels are valid for IDNA
684 Strings that appear to be A-labels or U-labels are processed in
685 various operations of the Protocol document [RFC5891]. Those strings
686 are not yet demonstrably conformant with the conditions outlined
687 above because they are in the process of validation. Such strings
688 may be referred to as "unvalidated", "putative", or "apparent", or as
689 being "in the form of" one of the label types to indicate that they
690 have not been verified to meet the specified conformance
693 Unvalidated A-labels are known only to be XN-labels, while Fake
694 A-labels have been demonstrated to fail some of the A-label tests.
695 Similarly, unvalidated U-labels are simply non-ASCII labels that may
696 or may not meet the requirements for U-labels.
700 These specifications use the term "NR-LDH label" strictly to refer to
701 an all-ASCII label that obeys the LDH label syntax discussed in
702 Section 2.3.1 and that is neither an IDN nor a label form reserved by
703 IDNA (R-LDH label). It should be stressed that all A-labels obey the
704 "hostname" [RFC0952] rules other than the length restriction in those
7072.3.2.3. Internationalized Domain Name and Internationalized Label
709 An "internationalized domain name" (IDN) is a domain name that
710 contains at least one A-label or U-label, but that otherwise may
711 contain any mixture of NR-LDH labels, A-labels, or U-labels. Just as
712 has been the case with ASCII names, some DNS zone administrators may
713 impose restrictions, beyond those imposed by DNS or IDNA, on the
714 characters or strings that may be registered as labels in their
715 zones. Because of the diversity of characters that can be used in a
716 U-label and the confusion they might cause, such restrictions are
717 mandatory for IDN registries and zones even though the particular
718 restrictions are not part of these specifications (the issue is
719 discussed in more detail in Section 4.3 of the Protocol document
720 [RFC5891]. Because these restrictions, commonly known as "registry
721 restrictions", only affect what can be registered and not lookup
722 processing, they have no effect on the syntax or semantics of DNS
723 protocol messages; a query for a name that matches no records will
724 yield the same response regardless of the reason why it is not in the
725 zone. Clients issuing queries or interpreting responses cannot be
730Klensin Standards Track [Page 13]
732RFC 5890 IDNA Definitions August 2010
735 assumed to have any knowledge of zone-specific restrictions or
736 conventions. See the section on registration policy in the Rationale
737 document [RFC5894] for additional discussion.
739 "Internationalized label" is used when a term is needed to refer to a
740 single label of an IDN, i.e., one that might be any of an NR-LDH
741 label, A-label, or U-label. There are some standardized DNS label
742 formats, such as the "underscore labels" used for service location
743 (SRV) records [RFC2782], that do not fall into any of the three
744 categories and hence are not internationalized labels.
7462.3.2.4. Label Equivalence
748 In IDNA, equivalence of labels is defined in terms of the A-labels.
749 If the A-labels are equal in a case-independent comparison, then the
750 labels are considered equivalent, no matter how they are represented.
751 Because of the isomorphism of A-labels and U-labels in IDNA2008, it
752 is possible to compare U-labels directly; see the Protocol document
753 [RFC5891] for details. Traditional LDH labels already have a notion
754 of equivalence: within that list of characters, uppercase and
755 lowercase are considered equivalent. The IDNA notion of equivalence
756 is an extension of that older notion but, because the protocol does
757 not specify any mandatory mapping and only those isomorphic forms are
758 considered, the only equivalents are:
760 o Exact (bit-string identity) matches between a pair of U-labels.
762 o Matches between a pair of A-labels, using normal DNS
763 case-insensitive matching rules.
765 o Equivalence between a U-label and an A-label determined by
766 translating the U-label form into an A-label form and then testing
767 for a match between the A-labels using normal DNS case-insensitive
772 The "ACE prefix" is defined in this document to be a string of ASCII
773 characters, "xn--", that appears at the beginning of every A-label.
774 "ACE" stands for "ASCII-Compatible Encoding".
7762.3.2.6. Domain Name Slot
778 A "domain name slot" is defined in this document to be a protocol
779 element or a function argument or a return value (and so on)
780 explicitly designated for carrying a domain name. Examples of domain
781 name slots include the QNAME field of a DNS query; the name argument
782 of the gethostbyname() or getaddrinfo() standard C library functions;
786Klensin Standards Track [Page 14]
788RFC 5890 IDNA Definitions August 2010
791 the part of an email address following the at sign ("@") in the
792 parameter to the SMTP MAIL or RCPT commands or the "From:" field of
793 an email message header; and the host portion of the URI in the "src"
794 attribute of an HTML "<IMG>" tag. A string that has the syntax of a
795 domain name but that appears in general text is not in a domain name
796 slot. For example, a domain name appearing in the plain text body of
797 an email message is not occupying a domain name slot.
799 An "IDNA-aware domain name slot" is defined for this set of documents
800 to be a domain name slot explicitly designated for carrying an
801 internationalized domain name as defined in this document. The
802 designation may be static (for example, in the specification of the
803 protocol or interface) or dynamic (for example, as a result of
804 negotiation in an interactive session).
806 Name slots that are not IDNA-aware obviously include any domain name
807 slot whose specification predates IDNA. Note that the requirements
808 of some protocols that use the DNS for data storage prevent the use
809 of IDNs. For example, the format required for the underscore labels
810 used by the service location protocol [RFC2782] precludes
811 representation of a non-ASCII label in the DNS using A-labels because
812 those SRV-related labels must start with underscores. Of course,
813 non-ASCII IDN labels may be part of a domain name that also includes
8162.3.3. Order of Characters in Labels
818 Because IDN labels may contain characters that are read, and
819 preferentially displayed, from right to left, there is a potential
820 ambiguity about which character in a label is "first". For the
821 purposes of these specifications, labels are considered, and
822 characters numbered, strictly in the order in which they appear "on
823 the wire". That order is equivalent to the leftmost character being
824 treated as first in a label that is read left to right and to the
825 rightmost character being first in a label that is read right to
826 left. The Bidi specification contains additional discussion of the
827 conditions that influence reading order.
8292.3.4. Punycode is an Algorithm, Not a Name or Adjective
831 There has been some confusion about whether a "Punycode string" does
832 or does not include the ACE prefix and about whether it is required
833 that such strings could have been the output of the ToASCII operation
834 (see RFC 3490, Section 4 [RFC3490]). This specification discourages
835 the use of the term "Punycode" to describe anything but the encoding
836 method and algorithm of RFC 3492 [RFC3492]. The terms defined above
837 are preferred as much more clear than the term "Punycode string".
842Klensin Standards Track [Page 15]
844RFC 5890 IDNA Definitions August 2010
8473. IANA Considerations
849 IANA actions for this version of IDNA (IDNA2008) are specified in the
850 Tables document [RFC5892]. An overview of the relationships among
851 the various IANA registries appears in the Rationale document
852 [RFC5894]. This document does not specify any actions for IANA.
8544. Security Considerations
858 Security on the Internet partly relies on the DNS. Thus, any change
859 to the characteristics of the DNS can change the security of much of
862 Domain names are used by users to identify and connect to Internet
863 hosts and other network resources. The security of the Internet is
864 compromised if a user entering a single internationalized name is
865 connected to different servers based on different interpretations of
866 the internationalized domain name. In addition to characters that
867 are permitted by IDNA2003 and its mapping conventions (see
868 Section 4.6), the current specification changes the interpretation of
869 a few characters that were mapped to others in the earlier version;
870 zone administrators should be aware of the problems that this might
871 raise and take appropriate measures. The context for this issue is
872 discussed in more detail in the Rationale document [RFC5894].
874 In addition to the Security Considerations material that appears in
875 this document, the Bidi document [RFC5893] contains a discussion of
876 security issues specific to labels containing characters from scripts
877 that are normally written right to left.
881 Labels associated with the DNS have traditionally been limited to 63
882 octets by the general restrictions in RFC 1035 and by the need to
883 treat them as a six-bit string length followed by the string in
884 actual calls to the DNS. That format is used in some other
885 applications and, in general, that representations of domain names as
886 dot-separated labels and as length-string pairs have been treated as
887 interchangeable. Because A-labels (the form actually used in the
888 DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
889 in general, more compressed that UTF-16 or UTF-32), U-labels that
890 obey all of the relevant symmetry (and other) constraints of these
891 documents may be quite a bit longer, potentially up to 252 characters
892 (Unicode code points). A fully-qualified domain name containing
893 several such labels can obviously also exceed the nominal 255 octet
898Klensin Standards Track [Page 16]
900RFC 5890 IDNA Definitions August 2010
903 limit for such names. Application authors using U-labels must exert
904 due caution to avoid buffer overflow and truncation errors and
905 attacks in contexts where shorter strings are expected.
9074.3. Local Character Set Issues
909 When systems use local character sets other than ASCII and Unicode,
910 these specifications leave the problem of converting between the
911 local character set and Unicode up to the application or local
912 system. If different applications (or different versions of one
913 application) implement different rules for conversions among coded
914 character sets, they could interpret the same name differently and
915 contact different servers. This problem is not solved by security
916 protocols, such as Transport Layer Security (TLS) [RFC5246], that do
917 not take local character sets into account.
9194.4. Visually Similar Characters
921 To help prevent confusion between characters that are visually
922 similar (sometimes called "confusables"), it is suggested that
923 implementations provide visual indications where a domain name
924 contains multiple scripts, especially when the scripts contain
925 characters that are easily confused visually, such as an omicron in
926 Greek mixed with Latin text. Such mechanisms can also be used to
927 show when a name contains a mixture of Simplified Chinese characters
928 with Traditional ones that have Simplified forms, or to distinguish
929 zero and one from uppercase "O" and lowercase "L". DNS zone
930 administrators may impose restrictions (subject to the limitations
931 identified elsewhere in these documents) that try to minimize
932 characters that have similar appearance or similar interpretations.
934 If multiple characters appear in a label and the label consists only
935 of characters in one script, individual characters that might be
936 confused with others if compared separately may be unambiguous and
937 non-confusing. On the other hand, that observation makes labels
938 containing characters from more than one script (often called "mixed-
939 script labels") even more risky -- users will tend to see what they
940 expect to see and context is a powerful reinforcement to perception.
941 At the same time, while the risks associated with mixed-script labels
942 are clear, simply prohibiting them will not eliminate problems,
943 especially where closely related scripts are involved. For example,
944 there are many strings that are entirely in Greek or Cyrillic scripts
945 that can be confused with each other or with Latin script strings.
947 It is worth noting that there are no comprehensive technical
948 solutions to the problems of confusable characters. One can reduce
949 the extent of the problems in various ways, but probably never
954Klensin Standards Track [Page 17]
956RFC 5890 IDNA Definitions August 2010
959 eliminate it. Some specific suggestions about identification and
960 handling of confusable characters appear in a Unicode Consortium
961 publication [Unicode-UTR36].
9634.5. IDNA Lookup, Registration, and the Base DNS Specifications
965 The Protocol specification [RFC5891] describes procedures for
966 registering and looking up labels that are not compatible with the
967 preferred syntax described in the base DNS specifications (see
968 Section 2.3.1) because they contain non-ASCII characters. These
969 procedures depend on the use of a special ASCII-compatible encoding
970 form that contains only characters permitted in hostnames by those
971 earlier specifications. The encoding used is Punycode [RFC3492]. No
972 security issues such as string length increases or new allowed values
973 are introduced by the encoding process or the use of these encoded
974 values, apart from those introduced by the ACE encoding itself.
976 Domain names (or portions of them) are sometimes compared against a
977 set of domains to be given special treatment if a match occurs, e.g.,
978 treated as more privileged than others or blocked in some way. In
979 such situations, it is especially important that the comparisons be
980 done properly, as specified in the "Requirements" section of the
981 Protocol document [RFC5891]. For labels already in ASCII form, the
982 proper comparison reduces to the same case-insensitive ASCII
983 comparison that has always been used for ASCII labels although
984 IDNA-aware applications are expected to look up only A-labels and
985 NR-LDH labels, i.e., to avoid looking up R-LDH labels that are not
988 The introduction of IDNA meant that any existing labels that start
989 with the ACE prefix would be construed as A-labels, at least until
990 they failed one of the relevant tests, whether or not that was the
991 intent of the zone administrator or registrant. There is no evidence
992 that this has caused any practical problems since RFC 3490 was
993 adopted, but the risk still exists in principle.
9954.6. Legacy IDN Label Strings
997 The URI Standard [RFC3986] and a number of application specifications
998 (e.g., SMTP [RFC5321] and HTTP [RFC2616]) do not permit non-ASCII
999 labels in DNS names used with those protocols, i.e., only the A-label
1000 form of IDNs is permitted in those contexts. If only A-labels are
1001 used, differences in interpretation between IDNA2003 and this version
1002 arise only for characters whose interpretation have actually changed
1003 (e.g., characters, such as ZWJ and ZWNJ, that were mapped to nothing
1004 in IDNA2003 and that are considered legitimate in some contexts by
1005 these specifications). Despite that prohibition, there are a
1006 significant number of files and databases on the Internet in which
1010Klensin Standards Track [Page 18]
1012RFC 5890 IDNA Definitions August 2010
1015 domain name strings appear in native-character form; a subset of
1016 those strings use native-character labels that require IDNA2003
1017 mapping to produce valid A-labels. The treatment of such labels will
1018 vary by types of applications and application-designer preference: in
1019 some situations, warnings to the user or outright rejection may be
1020 appropriate; in others, it may be preferable to attempt to apply the
1021 earlier mappings if lookup strictly conformant to these
1022 specifications fails or even to do lookups under both sets of rules.
1023 This general situation is discussed in more detail in the Rationale
1024 document [RFC5894]. However, in the absence of care by registries
1025 about how strings that could have different interpretations under
1026 IDNA2003 and the current specification are handled, it is possible
1027 that the differences could be used as a component of name-matching or
1028 name-confusion attacks. Such care is therefore appropriate.
10304.7. Security Differences from IDNA2003
1032 The registration and lookup models described in this set of documents
1033 change the mechanisms available for lookup applications to determine
1034 the validity of labels they encounter. In some respects, the ability
1035 to test is strengthened. For example, putative labels that contain
1036 unassigned code points will now be rejected, while IDNA2003 permitted
1037 them (see the Rationale document [RFC5894] for a discussion of the
1038 reasons for this). On the other hand, the Protocol specification no
1039 longer assumes that the application that looks up a name will be able
1040 to determine, and apply, information about the protocol version used
1041 in registration. In theory, that may increase risk since the
1042 application will be able to do less pre-lookup validation. In
1043 practice, the protection afforded by that test has been largely
1044 illusory for reasons explained in RFC 4690 [RFC4690] and elsewhere in
1047 Any change to the Stringprep [RFC3454] procedure that is profiled and
1048 used in IDNA2003, or, more broadly, the IETF's model of the use of
1049 internationalized character strings in different protocols, creates
1050 some risk of inadvertent changes to those protocols, invalidating
1051 deployed applications or databases, and so on. But these
1052 specifications do not change Stringprep at all; they merely bypass
1053 it. Because these documents do not depend on Stringprep, the
1054 question of upgrading other protocols that do have that dependency
1055 can be left to experts on those protocols: the IDNA changes and
1056 possible upgrades to security protocols or conventions are
1066Klensin Standards Track [Page 19]
1068RFC 5890 IDNA Definitions August 2010
1073 No mechanism involving names or identifiers alone can protect against
1074 a wide variety of security threats and attacks that are largely
1075 independent of the naming or identification system. These attacks
1076 include spoofed pages, DNS query trapping and diversion, and so on.
1080 The initial version of this document was created largely by
1081 extracting text from early draft versions of the Rationale document
1082 [RFC5894]. See the section of this name and the one entitled
1083 "Contributors", in it.
1085 Specific textual suggestions after the extraction process came from
1086 Vint Cerf, Lisa Dusseault, Bill McQuillan, Andrew Sullivan, and Ken
1087 Whistler. Other changes were made in response to more general
1088 comments, lists of concerns or specific errors from participants in
1089 the Working Group and other observers, including Lyman Chapin, James
1090 Mitchell, Subramanian Moonesamy, and Dan Winship.
10946.1. Normative References
1096 [ASCII] American National Standards Institute (formerly United
1097 States of America Standards Institute), "USA Code for
1098 Information Interchange", ANSI X3.4-1968, 1968. ANSI
1099 X3.4-1968 has been replaced by newer versions with
1100 slight modifications, but the 1968 version remains
1101 definitive for the Internet.
1103 [RFC1034] Mockapetris, P., "Domain names - concepts and
1104 facilities", STD 13, RFC 1034, November 1987.
1106 [RFC1035] Mockapetris, P., "Domain names - implementation and
1107 specification", STD 13, RFC 1035, November 1987.
1109 [RFC1123] Braden, R., "Requirements for Internet Hosts -
1110 Application and Support", STD 3, RFC 1123, October 1989.
1112 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1113 Requirement Levels", BCP 14, RFC 2119, March 1997.
1122Klensin Standards Track [Page 20]
1124RFC 5890 IDNA Definitions August 2010
1128 The Unicode Consortium, "Unicode Standard Annex #15:
1129 Unicode Normalization Forms, Revision 31",
1131 <http://www.unicode.org/reports/tr15/tr15-31.html>.
1133 [Unicode52] The Unicode Consortium. The Unicode Standard, Version
1134 5.2.0, defined by: "The Unicode Standard, Version
1135 5.2.0", (Mountain View, CA: The Unicode Consortium,
1136 2009. ISBN 978-1-936213-00-9).
1137 <http://www.unicode.org/versions/Unicode5.2.0/>.
11396.2. Informative References
1142 Resnick, P. and P. Hoffman, "Mapping Characters in
1143 Internationalized Domain Names for Applications (IDNA)",
1144 Work in Progress, April 2010.
1146 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD
1147 Internet host table specification", RFC 952,
1150 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1151 Specification", RFC 2181, July 1997.
1153 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1154 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1155 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1157 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
1158 RFC 2673, August 1999.
1160 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
1161 specifying the location of services (DNS SRV)",
1162 RFC 2782, February 2000.
1164 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
1165 Internationalized Strings ("stringprep")", RFC 3454,
1168 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
1169 "Internationalizing Domain Names in Applications
1170 (IDNA)", RFC 3490, March 2003.
1172 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
1173 Profile for Internationalized Domain Names (IDN)",
1174 RFC 3491, March 2003.
1178Klensin Standards Track [Page 21]
1180RFC 5890 IDNA Definitions August 2010
1183 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of
1184 Unicode for Internationalized Domain Names in
1185 Applications (IDNA)", RFC 3492, March 2003.
1187 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1188 Resource Identifier (URI): Generic Syntax", STD 66,
1189 RFC 3986, January 2005.
1191 [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review
1192 and Recommendations for Internationalized Domain Names
1193 (IDNs)", RFC 4690, September 2006.
1195 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
1196 Security (TLS) Protocol Version 1.2", RFC 5246,
1199 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1202 [RFC5891] Klensin, J., "Internationalized Domain Names in
1203 Applications (IDNA): Protocol", RFC 5891, August 2010.
1205 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
1206 Internationalized Domain Names for Applications (IDNA)",
1207 RFC 5892, August 2010.
1209 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for
1210 Internationalized Domain Names for Applications (IDNA)",
1211 RFC 5893, August 2010.
1213 [RFC5894] Klensin, J., "Internationalized Domain Names for
1214 Applications (IDNA): Background, Explanation, and
1215 Rationale", RFC 5894, August 2010.
1218 The Unicode Consortium, "Unicode Technical Report #36:
1219 Unicode Security Considerations, Revision 7", July 2008,
1220 <http://www.unicode.org/reports/tr36/tr36-7.html>.
1234Klensin Standards Track [Page 22]
1236RFC 5890 IDNA Definitions August 2010
1242 1770 Massachusetts Ave, Ste 322
1246 Phone: +1 617 245 1457
1247 EMail: john+ietf@jck.com
1290Klensin Standards Track [Page 23]