draft-ietf-idnabis-protocol-07.txt   draft-ietf-idnabis-protocol-08.txt 
Network Working Group J. Klensin Network Working Group J. Klensin
Obsoletes: 3490, 3491 Obsoletes: 3490, 3491
(if approved) (if approved)
Updates: 3492 (if approved) Updates: 3492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: June 1, 2009 Expires: June 10, 2009
Internationalized Domain Names in Applications (IDNA): Protocol Internationalized Domain Names in Applications (IDNA): Protocol
draft-ietf-idnabis-protocol-07.txt draft-ietf-idnabis-protocol-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2009. This Internet-Draft will expire on June 10, 2009.
Abstract Abstract
This document supplies the protocol definition for a revised and This document supplies the protocol definition for a revised and
updated specification for internationalized domain names (IDNs). The updated specification for internationalized domain names (IDNs). The
rationale for these changes, the relationship to the older rationale for these changes, the relationship to the older
specification, and important terminology are provided in other specification, and important terminology are provided in other
documents. This document specifies the protocol mechanism, called documents. This document specifies the protocol mechanism, called
Internationalizing Domain Names in Applications (IDNA), for Internationalizing Domain Names in Applications (IDNA), for
registering and looking up IDNs in a way that does not require registering and looking up IDNs in a way that does not require
skipping to change at page 2, line 28 skipping to change at page 2, line 28
4.3. Permitted Character and Label Validation . . . . . . . . . 7 4.3. Permitted Character and Label Validation . . . . . . . . . 7
4.3.1. Input Format . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Input Format . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. Rejection of Characters that are not Permitted . . . . 8 4.3.2. Rejection of Characters that are not Permitted . . . . 8
4.3.3. Label Validation . . . . . . . . . . . . . . . . . . . 8 4.3.3. Label Validation . . . . . . . . . . . . . . . . . . . 8
4.3.4. Registration Validation Summary . . . . . . . . . . . 9 4.3.4. Registration Validation Summary . . . . . . . . . . . 9
4.4. Registry Restrictions . . . . . . . . . . . . . . . . . . 9 4.4. Registry Restrictions . . . . . . . . . . . . . . . . . . 9
4.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10 4.5. Punycode Conversion . . . . . . . . . . . . . . . . . . . 10
4.6. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10 4.6. Insertion in the Zone . . . . . . . . . . . . . . . . . . 10
5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10 5. Domain Name Lookup Protocol . . . . . . . . . . . . . . . . . 10
5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 10 5.1. Label String Input . . . . . . . . . . . . . . . . . . . . 10
5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 10 5.2. Conversion to Unicode . . . . . . . . . . . . . . . . . . 11
5.3. Character Changes in Preprocessing or the User 5.3. Character Changes in Preprocessing or the User
Interface . . . . . . . . . . . . . . . . . . . . . . . . 11 Interface . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 12 5.4. A-label Input . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Validation and Character List Testing . . . . . . . . . . 12 5.5. Validation and Character List Testing . . . . . . . . . . 12
5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 13 5.6. Punycode Conversion . . . . . . . . . . . . . . . . . . . 14
5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 13 5.7. DNS Name Resolution . . . . . . . . . . . . . . . . . . . 14
6. Name Server Considerations . . . . . . . . . . . . . . . . . . 14 6. Name Server Considerations . . . . . . . . . . . . . . . . . . 14
6.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 14 6.1. Processing Non-ASCII Strings . . . . . . . . . . . . . . . 14
6.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 14 6.2. DNSSEC Authentication of IDN Domain Names . . . . . . . . 15
6.3. Root and other DNS Server Considerations . . . . . . . . . 15 6.3. Root and other DNS Server Considerations . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 19 Appendix A. Summary of Major Changes from IDNA2003 . . . . . . . 19
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
B.1. Changes between Version -00 and -01 of B.1. Changes between Version -00 and -01 of
draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 20 draft-ietf-idnabis-protocol . . . . . . . . . . . . . . . 20
B.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 20 B.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 20
B.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 21 B.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 21
B.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 21 B.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 21
B.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 21 B.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 21
B.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 21 B.6. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 21
B.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 21 B.7. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 22
B.8. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
This document supplies the protocol definition for a revised and This document supplies the protocol definition for a revised and
updated specification for internationalized domain names. Essential updated specification for internationalized domain names. Essential
definitions and terminology for understanding this document and a definitions and terminology for understanding this document and a
road map of the collection of documents that make up IDNA2008 appear road map of the collection of documents that make up IDNA2008 appear
in [IDNA2008-Defs]. Appendix A discusses the relationship between in [IDNA2008-Defs]. Appendix A discusses the relationship between
skipping to change at page 5, line 29 skipping to change at page 5, line 29
1. Whenever a domain name is put into an IDN-unaware domain name 1. Whenever a domain name is put into an IDN-unaware domain name
slot (see Section 2 and [IDNA2008-Defs]), it MUST contain only slot (see Section 2 and [IDNA2008-Defs]), it MUST contain only
ASCII characters (i.e., must be either an A-label or an LDH- ASCII characters (i.e., must be either an A-label or an LDH-
label), or must be a label associated with a DNS application that label), or must be a label associated with a DNS application that
is not subject to either IDNA or the historical recommendations is not subject to either IDNA or the historical recommendations
for "hostname"-style names [RFC1034]. for "hostname"-style names [RFC1034].
2. Comparison of labels MUST be done on equivalent forms: either 2. Comparison of labels MUST be done on equivalent forms: either
both A-Label forms or both U-Label forms. Because A-labels and both A-Label forms or both U-Label forms. Because A-labels and
U-labels can be transformed into each other without loss of U-labels can be transformed into each other without loss of
information, these comparisons are equivalent. However, when the information, these comparisons are equivalent. However, when a
A-label form is compared, it MUST use an ASCII case-insensitive pair of putative A-labels are compared, the comparison MUST use
comparison as with all comparisons of DNS labels. Comparison is an ASCII case-insensitive comparison (as with all comparisons of
only valid if the putative labels have been verified to be either ASCII DNS labels). Comparisons on putative U-labels must test
A-Labels or U-Labels. that the two strings are identical, without case-folding or other
intermediate steps. Note that it is not necessary to verify that
labels are valid in order to compare them. In many cases,
verification of validity (that the strings actually are A-labels
or U-labels) may be important for other reasons and SHOULD be
performed.
3. Labels being registered MUST conform to the requirements of 3. Labels being registered MUST conform to the requirements of
Section 4. Labels being looked up and the lookup process MUST Section 4. Labels being looked up and the lookup process MUST
conform to the requirements of Section 5. conform to the requirements of Section 5.
3.2. Applicability 3.2. Applicability
IDNA is applicable to all domain names in all domain name slots IDNA is applicable to all domain names in all domain name slots
except where it is explicitly excluded. It is not applicable to except where it is explicitly excluded. It is not applicable to
domain name slots which do not use the LDH syntax rules. domain name slots which do not use the LDH syntax rules.
This implies that IDNA is applicable to many protocols that predate This implies that IDNA is applicable to many protocols that predate
IDNA. Note that IDNs occupying domain name slots in those older IDNA. Note that IDNs occupying domain name slots in those older
protocols MUST be in A-label form until and unless those protocols protocols MUST be in A-label form until and unless those protocols
and implementations of them are upgraded to be IDN-aware and that and implementations of them are upgraded to be IDN-aware. IDNs
IDNs actually appearing in DNS queries or responses MUST be in actually appearing in DNS queries or responses MUST be A-labels.
A-label form.
3.2.1. DNS Resource Records 3.2.1. DNS Resource Records
IDNA applies only to domain names in the NAME and RDATA fields of DNS IDNA applies only to domain names in the NAME and RDATA fields of DNS
resource records whose CLASS is IN. resource records whose CLASS is IN.
There are currently no other exclusions on the applicability of IDNA There are currently no other exclusions on the applicability of IDNA
to DNS resource records. Applicability depends entirely on the to DNS resource records. Applicability depends entirely on the
CLASS, and not on the TYPE except as noted below. This will remain CLASS, and not on the TYPE except as noted below. This will remain
true, even as new types are defined, unless there is a compelling true, even as new types are defined, unless there is a compelling
skipping to change at page 8, line 31 skipping to change at page 8, line 35
4.3.3.1. Rejection of Hyphen Sequences in U-labels 4.3.3.1. Rejection of Hyphen Sequences in U-labels
The Unicode string MUST NOT contain "--" (two consecutive hyphens) in The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
the third and fourth character positions when the label is considered the third and fourth character positions when the label is considered
in "on the wire" order. in "on the wire" order.
4.3.3.2. Leading Combining Marks 4.3.3.2. Leading Combining Marks
The first character of the string (when the label is considered in The first character of the string (when the label is considered in
"on the wire" order) is examined to verify that it is not a combining "on the wire" order) is examined to verify that it is not a combining
mark. If it is a combining mark, the string MUST NOT be registered. mark (or combining character) (see The Unicode Standard, Section 2.11
[Unicode] for an exact definition). If it is a combining mark, the
string MUST NOT be registered.
4.3.3.3. Contextual Rules 4.3.3.3. Contextual Rules
Each code point is checked for its identification as a character Each code point is checked for its identification as a character
requiring contextual processing for registration (the list of requiring contextual processing for registration (the list of
characters appears as the combination of CONTEXTJ and CONTEXTO in characters appears as the combination of CONTEXTJ and CONTEXTO in
[IDNA2008-Tables] as do the contextual rules themselves). If that [IDNA2008-Tables] as do the contextual rules themselves). If that
indication appears, the table of contextual rules is checked for a indication appears, the table of contextual rules is checked for a
rule for that character. If no rule is found, the proposed label is rule for that character. If no rule is found, the proposed label is
rejected and MUST NOT be installed in a zone file. If one is found, rejected and MUST NOT be installed in a zone file. If one is found,
skipping to change at page 9, line 10 skipping to change at page 9, line 17
that could be used, under other conditions, to produce misleading that could be used, under other conditions, to produce misleading
labels or to cause unacceptable ambiguity in label matching and labels or to cause unacceptable ambiguity in label matching and
interpretation. For example, labels containing invisible ("zero- interpretation. For example, labels containing invisible ("zero-
width") characters may be permitted in context with characters whose width") characters may be permitted in context with characters whose
presentation forms are significantly changed by the presence or presentation forms are significantly changed by the presence or
absence of the zero-width characters, while other labels in which absence of the zero-width characters, while other labels in which
zero-width characters appear may be rejected. zero-width characters appear may be rejected.
4.3.3.4. Labels Containing Characters Written Right to Left 4.3.3.4. Labels Containing Characters Written Right to Left
Additional special tests for right-to-left strings are applied. Special tests are required for strings containing characters that are
Strings that contain right to left characters that do not conform to normally written from right to left. The criteria for classifying
the rule(s) identified in [IDNA2008-BIDI] MUST NOT be inserted as characters in terms of directionality are identified in the "Bidi"
document [IDNA2008-BIDI] in this series. That document also
describes conditions for strings that contain one or more of those
characters to be U-labels. The tests for those conditions, specified
there, are applied. Strings that contain right to left characters
that do not conform to the IDNA Bidi rules MUST NOT be inserted as
labels in zone files. labels in zone files.
4.3.4. Registration Validation Summary 4.3.4. Registration Validation Summary
Strings that contain at least one non-ASCII character, have been Strings that contain at least one non-ASCII character, have been
produced by the steps above, whose contents pass the above tests, and produced by the steps above, whose contents pass the above tests, and
are 63 or fewer characters long in ACE form (see Section 4.5), are are 63 or fewer characters long in ACE form (see Section 4.5), are
U-labels. U-labels.
To summarize, tests are made in Section 4.3 for invalid characters, To summarize, tests are made in Section 4.3 for invalid characters,
skipping to change at page 10, line 10 skipping to change at page 10, line 19
The string produced by the above steps is checked and processed as The string produced by the above steps is checked and processed as
appropriate to local registry restrictions. Application of those appropriate to local registry restrictions. Application of those
registry restrictions may result in the rejection of some labels or registry restrictions may result in the rejection of some labels or
the application of special restrictions to others. the application of special restrictions to others.
4.5. Punycode Conversion 4.5. Punycode Conversion
The resulting U-label is converted to an A-label. The A-label, more The resulting U-label is converted to an A-label. The A-label, more
precisely defined elsewhere, is the encoding of the U-label according precisely defined elsewhere, is the encoding of the U-label according
to the Punycode algorithm [RFC3492] with the ACE prefix "xn--" added to the Punycode algorithm [RFC3492] with the ACE prefix "xn--" added
at the beginning of the string. This document updates RFC 3492 only at the beginning of the string. The resulting string much, of
to the extent of replacing the reference to the discussion of the ACE course, conform to the length limits imposed by the DNS. This
prefix. The ACE prefix is now specified in this document rather than document updates RFC 3492 only to the extent of replacing the
as part of RFC 3490 or Nameprep [RFC3491] but is the same in both reference to the discussion of the ACE prefix. The ACE prefix is now
sets of documents. specified in this document rather than as part of RFC 3490 or
Nameprep [RFC3491] but is the same in both sets of documents.
The failure conditions identified in the Punycode encoding procedure The failure conditions identified in the Punycode encoding procedure
cannot occur if the input is a U-label as determined by the steps cannot occur if the input is a U-label as determined by the steps
above. above.
4.6. Insertion in the Zone 4.6. Insertion in the Zone
The A-label is registered in the DNS by insertion into a zone. The A-label is registered in the DNS by insertion into a zone.
5. Domain Name Lookup Protocol 5. Domain Name Lookup Protocol
skipping to change at page 12, line 29 skipping to change at page 12, line 40
are not performed, the lookup process SHOULD at least make tests to are not performed, the lookup process SHOULD at least make tests to
determine that the string is actually an A-label, examining it for determine that the string is actually an A-label, examining it for
the invalid formats specified in the Punycode decoding specification. the invalid formats specified in the Punycode decoding specification.
Applications that are not IDNA-aware will obviously omit that Applications that are not IDNA-aware will obviously omit that
testing; others MAY treat the string as opaque to avoid the testing; others MAY treat the string as opaque to avoid the
additional processing at the expense of providing less protection and additional processing at the expense of providing less protection and
information to users. information to users.
5.5. Validation and Character List Testing 5.5. Validation and Character List Testing
As with the registration procedure, the Unicode string is checked to As with the registration procedure described in Section 4, the
verify that all characters that appear in it are valid as input to Unicode string is checked to verify that all characters that appear
IDNA lookup processing. As discussed above and in in it are valid as input to IDNA lookup processing. As discussed
[IDNA2008-Rationale], the lookup check is more liberal than the above and in [IDNA2008-Rationale], the lookup check is more liberal
registration one. Putative labels with any of the following than the registration one. Putative labels with any of the following
characteristics MUST BE rejected prior to DNS lookup: characteristics MUST BE rejected prior to DNS lookup:
o Labels containing code points that are unassigned in the version o Labels containing code points that are unassigned in the version
of Unicode being used by the application, i.e., in the of Unicode being used by the application, i.e.,in the UNASSIGNED
"Unassigned" Unicode category or the UNASSIGNED category of category of [IDNA2008-Tables].
[IDNA2008-Tables].
o Labels that are not in NFC form. o Labels that are not in NFC form as defined in [Unicode-UAX15].
o Labels containing prohibited code points, i.e., those that are o Labels containing prohibited code points, i.e., those that are
assigned to the "DISALLOWED" category in the permitted character assigned to the "DISALLOWED" category in the permitted character
table [IDNA2008-Tables]. table [IDNA2008-Tables].
o Labels containing code points that are shown in the permitted o Labels containing code points that are identified in
character table as requiring a contextual rule and that are [IDNA2008-Tables] as "CONTEXTJ", i.e., requiring exceptional
flagged as requiring exceptional special processing on lookup contextual rule processing on lookup, but that do not conform to
("CONTEXTJ" in the Tables) but do not conform to that rule. that rule. Note that this implies that a rule much be defined,
not missing: a character that requires a contextual rule but for
which the rule is missing is treated in this step as having failed
to conform to the rule.
o Labels containing other code points that are shown in the o Labels containing code points that are identified in in
permitted character table as requiring a contextual rule [IDNA2008-Tables] as "CONTEXTO", but for which no such rule
("CONTEXTO" in the tables), but for which no such rule appears in appears in the table of rules. Applications resolving DNS names
the table of rules. Applications resolving DNS names or carrying or carrying out equivalent operations are not required to test
out equivalent operations are not required to test contextual contextual rules for "CONTEXTO" characters, only to verify that a
rules for "CONTEXTO" characters, only to verify that a rule exists rule exists (although they MAY make such tests to give better
(although they MAY make such tests to give better information to information to the user).
the user).
o Labels whose first character is a combining mark. o Labels whose first character is a combining mark (see
Section 4.3.3.2.
In addition, the application SHOULD apply the following test. The In addition, the application SHOULD apply the following test. The
test may be omitted in special circumstances, such as when the lookup test may be omitted in special circumstances, such as when the lookup
application knows that the conditions are enforced elsewhere, because application knows that the conditions are enforced elsewhere, because
an attempt to look up and resolve such strings will almost certainly an attempt to look up and resolve such strings will almost certainly
lead to a DNS lookup failure except when wildcards are present in the lead to a DNS lookup failure except when wildcards are present in the
zone. However, applying the test is likely to give much better zone. However, applying the test is likely to give much better
information about the reason for a lookup failure -- information that information about the reason for a lookup failure -- information that
may be usefully passed to the user when that is feasible -- than DNS may be usefully passed to the user when that is feasible -- than DNS
resolution failure information alone. In any event, lookup resolution failure information alone. In any event, lookup
skipping to change at page 14, line 7 skipping to change at page 14, line 17
The validated string, a U-label, is converted to an A-label using the The validated string, a U-label, is converted to an A-label using the
Punycode algorithm with the ACE prefix added. Punycode algorithm with the ACE prefix added.
5.7. DNS Name Resolution 5.7. DNS Name Resolution
The A-label is looked up in the DNS, using normal DNS resolver The A-label is looked up in the DNS, using normal DNS resolver
procedures. procedures.
6. Name Server Considerations 6. Name Server Considerations
[[anchor16: Note in draft: If we really want this document to contain [[anchor15: Note in draft: If we really want this document to contain
only information that is necessary to proper implementation of IDNA only information that is necessary to proper implementation of IDNA
by implementers who are familiar with the DNS, the material in this by implementers who are familiar with the DNS, the material in this
section is either tutorial, explanatory, or totally unnecessary. section is either tutorial, explanatory, or totally unnecessary.
Should some or all of it be moved back to Rationale?]] Should some or all of it be moved back to Rationale?]]
6.1. Processing Non-ASCII Strings 6.1. Processing Non-ASCII Strings
Existing DNS servers do not know the IDNA rules for handling non- Existing DNS servers do not know the IDNA rules for handling non-
ASCII forms of IDNs, and therefore need to be shielded from them. ASCII forms of IDNs, and therefore need to be shielded from them.
All existing channels through which names can enter a DNS server All existing channels through which names can enter a DNS server
skipping to change at page 14, line 41 skipping to change at page 15, line 7
allows domain labels to contain octets beyond the ASCII range allows domain labels to contain octets beyond the ASCII range
(0000..007F), and this document does not change that. Note, however, (0000..007F), and this document does not change that. Note, however,
that there is no defined interpretation of octets 0080..00FF as that there is no defined interpretation of octets 0080..00FF as
characters. If labels containing these octets are returned to characters. If labels containing these octets are returned to
applications, unpredictable behavior could result. The A-label form, applications, unpredictable behavior could result. The A-label form,
which cannot contain those characters, is the only standard which cannot contain those characters, is the only standard
representation for internationalized labels in the DNS protocol. representation for internationalized labels in the DNS protocol.
6.2. DNSSEC Authentication of IDN Domain Names 6.2. DNSSEC Authentication of IDN Domain Names
DNS Security [RFC2535] is a method for supplying cryptographic DNS Security (DNSSEC) [RFC2535] is a method for supplying
verification information along with DNS messages. Public Key cryptographic verification information along with DNS messages.
Cryptography is used in conjunction with digital signatures to Public Key Cryptography is used in conjunction with digital
provide a means for a requester of domain information to authenticate signatures to provide a means for a requester of domain information
the source of the data. This ensures that it can be traced back to a to authenticate the source of the data. This ensures that it can be
trusted source, either directly or via a chain of trust linking the traced back to a trusted source, either directly or via a chain of
source of the information to the top of the DNS hierarchy. trust linking the source of the information to the top of the DNS
hierarchy.
IDNA specifies that all internationalized domain names served by DNS IDNA specifies that all internationalized domain names served by DNS
servers that cannot be represented directly in ASCII MUST use the servers that cannot be represented directly in ASCII MUST use the
A-label form. Conversion to A-labels MUST be performed prior to a A-label form. Conversion to A-labels MUST be performed prior to a
zone being signed by the private key for that zone. Because of this zone being signed by the private key for that zone. Because of this
ordering, it is important to recognize that DNSSEC authenticates a ordering, it is important to recognize that DNSSEC authenticates a
domain name containing A-labels or conventional LDH-labels, not domain name containing A-labels or conventional LDH-labels, not
U-labels. In the presence of DNSSEC, no form of a zone file or query U-labels. In the presence of DNSSEC, no form of a zone file or query
response that contains a U-label may be signed or the signature response that contains a U-label may be signed or the signature
validated. validated.
skipping to change at page 20, line 24 skipping to change at page 20, line 37
contexts or as part of running text in paragraphs. contexts or as part of running text in paragraphs.
9. Remove the dot separator from the mandatory part of the 9. Remove the dot separator from the mandatory part of the
protocol. protocol.
10. Make some currently-valid labels that are not actually IDNA 10. Make some currently-valid labels that are not actually IDNA
labels invalid. labels invalid.
Appendix B. Change Log Appendix B. Change Log
[[anchor25: RFC Editor: Please remove this appendix.]] [[anchor24: RFC Editor: Please remove this appendix.]]
B.1. Changes between Version -00 and -01 of draft-ietf-idnabis-protocol B.1. Changes between Version -00 and -01 of draft-ietf-idnabis-protocol
o Corrected discussion of SRV records. o Corrected discussion of SRV records.
o Several small corrections for clarity. o Several small corrections for clarity.
o Inserted more "open issue" placeholders. o Inserted more "open issue" placeholders.
B.2. Version -02 B.2. Version -02
skipping to change at page 22, line 11 skipping to change at page 22, line 18
B.7. Version -07 B.7. Version -07
o Multiple small textual and editorial changes and clarifications. o Multiple small textual and editorial changes and clarifications.
o Requirement for normalization clarified to apply to all cases and o Requirement for normalization clarified to apply to all cases and
conditions for preprocessing further clarified. conditions for preprocessing further clarified.
o Substantive change to Section 4.3.1, turning a SHOULD to a MUST o Substantive change to Section 4.3.1, turning a SHOULD to a MUST
(see note from Mark Davis, 19 November, 2008 18:14 -0800). (see note from Mark Davis, 19 November, 2008 18:14 -0800).
B.8. Version -08
o Added some references and altered text to improve clarity.
o Changed the description of CONTEXTJ/CONTEXTO to conform to that in
Tables. In other words, these are now treated as distinction
categories (again), rather than as specially-flagged subsets of
PROTOCOL VALID.
o The discussion of label comparisons has been rewritten to make it
more precise and to clarify that one does not need to verify that
a string is a [valid] A-label or U-label in order to test it for
equality with another string. The WG should verify that the
current text is what is desired.
o Other changes to reflect post-IETF discussions or editorial
improvements.
Author's Address Author's Address
John C Klensin John C Klensin
1770 Massachusetts Ave, Ste 322 1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Phone: +1 617 245 1457 Phone: +1 617 245 1457
Email: john+ietf@jck.com Email: john+ietf@jck.com
 End of changes. 23 change blocks. 
57 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/