mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 06:25:31 +00:00
Code Issues Releases Wiki Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2001-07-05 17:56:47 +00:00
parent 97c5be1daa
commit f18701aeaf
6 changed files with 400 additions and 330 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
doc/draft/draft-ietf-dnsext-ad-is-secure-01.txt → doc/draft/draft-ietf-dnsext-ad-is-secure-02.txt
View File

@@ -1,12 +1,7 @@
DNSEXT Working Group Brian Wellington
INTERNET-DRAFT Olafur Gudmundsson
<draft-ietf-dnsext-ad-is-secure-02.txt> June 2001
DNSEXT Working Group Brian Wellington (Nominum)
INTERNET-DRAFT Olafur Gudmundsson (NAI Labs)
<draft-ietf-dnsext-ad-is-secure-01.txt> January 2001
Updates: RFC 2535 Updates: RFC 2535
@@ -37,7 +32,7 @@ Status of this Memo
Comments should be sent to the authors or the DNSEXT WG mailing list Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org namedroppers@ops.ietf.org
This draft expires on July 19, 2001. This draft expires on December 18, 2001.
Copyright Notice Copyright Notice
@@ -55,9 +50,9 @@ Abstract
Expires July 2001 [Page 1] Expires December 2001 [Page 1]
INTERNET-DRAFT AD bit set on secure answers January 2001 INTERNET-DRAFT AD bit set on secure answers June 2001
1 - Introduction 1 - Introduction
@@ -111,14 +106,14 @@ INTERNET-DRAFT AD bit set on secure answers January 2001
Expires July 2001 [Page 2] Expires December 2001 [Page 2]
INTERNET-DRAFT AD bit set on secure answers January 2001 INTERNET-DRAFT AD bit set on secure answers June 2001
If the answer section contains any data, the server MUST NOT include AD should be set if and only if all RRs in the answer section, and
data in the authority section that would cause the AD bit to be any relevant negative response RRs in the authority section are
unset. Authenticated.
The AD bit MUST NOT be set on a response unless all of the RRsets in The AD bit MUST NOT be set on a response unless all of the RRsets in
the answer and authority sections are Authenticated. the answer and authority sections are Authenticated.
@@ -161,15 +156,15 @@ References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and [RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987. Specification'', STD 13, RFC 1035, November 1987.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
2535, March 1999. 2535, March 1999.
Expires July 2001 [Page 3]
Expires December 2001 [Page 3]
INTERNET-DRAFT AD bit set on secure answers January 2001 INTERNET-DRAFT AD bit set on secure answers June 2001
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, [RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
@@ -183,12 +178,11 @@ INTERNET-DRAFT AD bit set on secure answers January 2001
Authors Addresses Authors Addresses
Brian Wellington Olafur Gudmundsson Brian Wellington Olafur Gudmundsson
Nominum Inc. NAI Labs Nominum Inc.
950 Charter Street 3060 Washington Road (Rt. 97) 950 Charter Street 3826 Legation Street, NW
Redwood City, CA, 94063 Glenwood, MD, 21738 Redwood City, CA, 94063 Washington, DC, 20015
USA USA USA USA
+1 650 381 6022 +1 443 259 2389 <Brian.Wellington@nominum.com> <ogud@ogud.com>
<Brian.Wellington@nominum.com> <ogud@tislabs.com>
Full Copyright Statement Full Copyright Statement
@@ -223,4 +217,6 @@ Full Copyright Statement
Expires July 2001 [Page 4]
Expires December 2001 [Page 4]

179
doc/draft/draft-ietf-dnsext-axfr-clarify-01.txt → doc/draft/draft-ietf-dnsext-axfr-clarify-02.txt
View File

@@ -1,6 +1,7 @@
INTERNET-DRAFT Andreas Gustafsson INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-01.txt Nominum Inc. draft-ietf-dnsext-axfr-clarify-02.txt Nominum Inc.
November 2000 June 2001
DNS Zone Transfer Protocol Clarifications DNS Zone Transfer Protocol Clarifications
@@ -49,9 +50,9 @@ Abstract
Expires May 2001 [Page 1] Expires December 2001 [Page 1]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000 draft-ietf-dnsext-axfr-clarify-02.txt June 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -75,6 +76,11 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
transfer, it MUST respond with a single DNS message containing an transfer, it MUST respond with a single DNS message containing an
appropriate RCODE other than NOERROR. appropriate RCODE other than NOERROR.
Slave servers should note that some master server implementations
will simply close the connection when denying the slave access to the
zone. Therefore, slaves MAY interpret an immediate graceful close of
the TCP connection as equivalent to a "Refused" response (RCODE 5).
If a zone transfer can be provided, the master server sends one or If a zone transfer can be provided, the master server sends one or
more DNS messages containing the zone data as described below. more DNS messages containing the zone data as described below.
@@ -98,18 +104,17 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
DNS message size. In the case of a small zone, this can cause the DNS message size. In the case of a small zone, this can cause the
entire transfer to be transmitted in a single response message. entire transfer to be transmitted in a single response message.
Expires December 2001 [Page 2]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
Slaves MUST accept messages containing any number of answer RRs. For Slaves MUST accept messages containing any number of answer RRs. For
compatibility with old slaves, masters that support sending multiple compatibility with old slaves, masters that support sending multiple
answers per message SHOULD be configurable to revert to the answers per message SHOULD be configurable to revert to the
historical mode of one answer per message, and the configuration historical mode of one answer per message, and the configuration
Expires May 2001 [Page 2]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
SHOULD be settable on a per-slave basis. SHOULD be settable on a per-slave basis.
3.2. DNS message header contents 3.2. DNS message header contents
@@ -121,19 +126,20 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
ID Copy from request ID Copy from request
QR 1 QR 1
OPCODE QUERY OPCODE QUERY
AA 1 (but MAY be 0 when RCODE is nonzero) AA 1, but MAY be 0 when RCODE is not NOERROR
TC 0 TC 0
RD Copy from request RD Copy from request, or 0
RA Set according to availability of recursion S Z 0 RA Set according to availability of recursion, or 0
Z 0
AD 0 AD 0
CD 0 CD 0
RCODE 0 or error code RCODE NOERROR on success, error code otherwise
The slave MUST check the RCODE and abort the transfer if it is The slave MUST check the RCODE in each message and abort the transfer
nonzero. It SHOULD check the ID of the first message received and if it is not NOERROR. It SHOULD check the ID of the first message
abort the transfer if it does not match the ID of the request. The received and abort the transfer if it does not match the ID of the
ID SHOULD be ignored in subsequent messages, and fields other than request. The ID SHOULD be ignored in subsequent messages, and fields
RCODE and ID SHOULD be ignored in all messages, to ensure other than RCODE and ID SHOULD be ignored in all messages, to ensure
interoperability with certain older implementations which transmit interoperability with certain older implementations which transmit
incorrect or arbitrary values in these fields. incorrect or arbitrary values in these fields.
@@ -154,51 +160,50 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
3.5. The authority section 3.5. The authority section
Expires December 2001 [Page 3]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
The master server MUST transmit messages with an empty authority The master server MUST transmit messages with an empty authority
section. Slaves MUST ignore any authority section contents they may section. Slaves MUST ignore any authority section contents they may
receive from masters that do not comply with this requirement. receive from masters that do not comply with this requirement.
Expires May 2001 [Page 3]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
3.6. The additional section 3.6. The additional section
The additional section MAY contain additional RRs such as transaction The additional section MAY contain additional RRs such as transaction
signatures. The slave MUST ignore any unexpected RRs in the signatures. The slave MUST ignore any unexpected RRs in the
additional section. additional section.
4. Glue 4. Zone data
A master transmitting a zone transfer MUST include the full set of The purpose of the zone transfer mechanism is to exactly replicate at
zone data it loaded from the zone's master file, from an incoming each slave the set of RRs associated with a particular zone at its
zone transfer, or other similar means of configuring zone data. This primary master. An RR is associated with a zone by being loaded from
includes any nonauthoritative data ("glue") associated with the zone the master file of that zone at the primary master server, or by some
by being present in the zone's master file or the incoming transfer other, equivalent method for configuring zone data.
along with the authoritative data. This glue data includes any
configured zone data obscured by zone cuts or otherwise outside the
zone in case; it is not limited to RRs pointed to by NS records.
The glue RRs are transmitted in the answer section along with the This replication shall be complete and unaltered, regardless of how
authoritative data. This is unlike ordinary DNS responses where glue many and which intermediate masters/slaves are involved, and
is transmitted in the authority or additional section. regardless of what other zones those intermediate masters/slaves do
or do not serve, and regardless of what data may be cached in
resolvers associated with the intermediate masters/slaves.
Zone transfers MUST NOT contain RRs from the authoritative data of Therefore, in a zone transfer the master MUST send exactly those
zones other than the one being transferred or from the cache, even records that are associated with the zone, whether or not their owner
when such RRs are pointed to by NS records in the zone being names would be considered to be "in" the zone for purposes of
transferred. resolution, and whether or not they would be eligible for use as glue
in responses. The transfer MUST NOT include any RRs that are not
associated with the zone, such as RRs associated with zones other
than the one being transferred or present in the cache of the local
resolver, even if their owner names are in the zone being transferred
or are pointed to by NS records in the zone being transferred.
A slave receiving a zone transfer MUST accept glue data and recognize The slave MUST associate the RRs received in a zone transfer with the
it as such; glue MUST NOT be treated as authoritative data nor specific zone being transferred, and maintain that association for
entered into the cache. Note that classifying an RR as glue or non- purposes of acting as a master in outgoing transfers.
glue may not be possible until the entire zone has been received so
that the zone cuts defined by the zone's NS records can be
determined. Glue data that is not below the zone origin ("cross-zone
glue") MAY be discarded by the slave.
5. Transmission order 5. Transmission order
@@ -210,30 +215,33 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
zone's apex are transmitted only once. zone's apex are transmitted only once.
Therefore, the quoted sentence is hereby changed to read "The first Therefore, the quoted sentence is hereby changed to read "The first
Expires December 2001 [Page 4]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
and last RR transmitted must be the SOA record of the zone". and last RR transmitted must be the SOA record of the zone".
The initial and final SOA record MUST be identical, with the possible The initial and final SOA record MUST be identical, with the possible
exception of case and compression. In particular, they MUST have the exception of case and compression. In particular, they MUST have the
Expires May 2001 [Page 4]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
same serial number. same serial number.
The transmission order of all other RRs in the zone, including glue The transmission order of all other RRs in the zone is undefined.
records, is undefined. Each of them MUST be transmitted exactly once. As some older masters
do not comply with this requirement, slaves SHOULD silently ignore
duplicate RRs for interoperability.
6. Security Considerations 6. Security Considerations
The zone transfer protocol as defined in [RFC1034] and clarified by The zone transfer protocol as defined in [RFC1034] and clarified by
this memo does not have any built-in mechanisms for the slave to this memo does not have any built-in mechanisms for the slave to
securely verify the identity of the master server and the integrity securely verify the identity of the master server and the integrity
of the transferred zone data. The use of TSIG [RFC2845] for this of the transferred zone data. The use of a cryptographic mechanism
purpose is RECOMMENDED. for ensuring authenticity and integrity, such as TSIG [RFC2845],
IPSEC, or TLS, is RECOMMENDED.
The zone transfer protocol allows read-only public access to the The zone transfer protocol allows read-only public access to the
complete zone data. Since data in the DNS is public by definition, complete zone data. Since data in the DNS is public by definition,
@@ -244,6 +252,13 @@ draft-ietf-dnsext-axfr-clarify-01.txt November 2000
These clarifications are not believed to themselves introduce any new These clarifications are not believed to themselves introduce any new
security problems, nor to solve any existing ones. security problems, nor to solve any existing ones.
Acknowledgements
Many people have contributed input and commentary to earlier versions
of this document, including but not limited to Bob Halley, Dan
Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Levon Esibov,
Mark Andrews, Michael Patton, Peter Koch, and Sam Trenholme.
References References
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
@@ -256,6 +271,14 @@ References
S. Bradner, BCP 14, March 1997. S. Bradner, BCP 14, March 1997.
[RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P. [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
Expires December 2001 [Page 5]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
Author's Address Author's Address
@@ -266,21 +289,14 @@ Author's Address
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 779 6004 Phone: +1 650 381 6004
Email: gson@nominum.com Email: gson@nominum.com
Expires May 2001 [Page 5]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000, 2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
@@ -314,20 +330,5 @@ Full Copyright Statement
Expires December 2001 [Page 6]
Expires May 2001 [Page 6]

174
doc/draft/draft-ietf-dnsext-dnssec-roadmap-03.txt → doc/draft/draft-ietf-dnsext-dnssec-roadmap-04.txt
View File

@@ -6,7 +6,7 @@
DNEXT Working Group S. Rose DNEXT Working Group S. Rose
Internet Draft NIST Internet Draft NIST
Expires: November 2001 April 2001 Expires: January 2001 July 2001
Category: Informational Category: Informational
@@ -14,44 +14,44 @@ Category: Informational
DNS Security Document Roadmap DNS Security Document Roadmap
------------------------------ ------------------------------
<draft-ietf-dnsext-dnssec-roadmap-03.txt> <draft-ietf-dnsext-dnssec-roadmap-04.txt>
Status of this Document Status of this Document
This document is an Internet-Draft and is in full This document is an Internet-Draft and is in full conformance with
conformance with all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026. Distribution of this
Distribution of this document is unlimited. Comments document is unlimited. Comments regarding this document should be
regarding this document should be sent to the author. sent to the author.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet Engineering
Engineering Task Force (IETF), its areas, and its working Task Force (IETF), its areas, and its working groups. Note that other
groups. Note that other groups may also distribute groups may also distribute working documents as Internet-Drafts.
working documents as Internet-Drafts. Internet-Drafts are Internet-Drafts are draft documents valid for a maximum of six months
draft documents valid for a maximum of six months and may and may be updated, replaced, or obsoleted by other documents at any
be updated, replaced, or obsoleted by other documents at time. It is inappropriate to use Internet Drafts as reference
any time. It is inappropriate to use Internet Drafts as material or to cite them other than as "work in progress."
reference 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 The list of Internet-Draft Shadow Directories can be accessed at
accessed at http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
DNS Security (DNSSEC)technology is composed of extensions DNS Security (DNSSEC)technology is composed of extensions to the
to the Domain Name System (DNS) protocol that provide Domain Name System (DNS) protocol that provide data integrity and
data integrity and authentication to security aware authentication to security aware resolvers and applications through
resolvers and applications through the use of the use of cryptographic digital signatures. Several documents exist
cryptographic digital signatures. Several documents to describe these extensions and the implementation-specific details
exist to describe these extensions and the regarding specific digital signing schemes. The interrelationship
implementation-specific details regarding specific between these different documents is discussed here. A brief
digital signing schemes. The interrelationship between overview of what to find in which document and author guidelines for
these different documents is discussed here. A brief what to include in new DNS Security documents, or revisions to
existing documents, is described.
@@ -64,11 +64,6 @@ Rose [Page 1]
INTERNET-DRAFT DNS Security Document Roadmap April 2001 INTERNET-DRAFT DNS Security Document Roadmap April 2001
overview of what to find in which document and author
guidelines for what to include in new DNS Security
documents, or revisions to existing documents, is
described.
@@ -108,6 +103,11 @@ Table of Contents
@@ -206,13 +206,14 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
| RRs | | | | Uses | | RRs | | | | Uses |
| [RFC2538, | | [RFC2535, | | [SSH-DNS] | | [RFC2538, | | [RFC2535, | | [SSH-DNS] |
| RFC2931, | | RFC3007, | +-------------+ | RFC2931, | | RFC3007, | +-------------+
| NO] | | RFC3008, | | NO, DSIG] | | RFC3008, |
+------------+ | RFC3090, | +------------+ | RFC3090, |
| SIZE ] | | SIZE ] |
| OKBIT, | | OKBIT, |
| ADBIT, | | ADBIT, |
| OPTIN, | | OPTIN, |
| PARSIG ] | | PARSIG, |
| PARKEY ] |
+-----------+ +-----------+
| |
| |
@@ -224,16 +225,15 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
| Algorithm | | Transactions | * Notes * | Algorithm | | Transactions | * Notes *
| Impl. | | | | | | Impl. | | | | |
| [RFC2536, | | [RFC2845, | * [CAIRN, * | [RFC2536, | | [RFC2845, | * [CAIRN, *
| RFC2537 | | RFC2930] | | ROLLOVER ] | | RFC2537 | | RFC2930] | | ROLLOVER, |
| RFC2539 | | | * * | RFC2539 | | | * RESROLLOVER ] *
| GSS-TSIG, | | | +-*-*-*-*-*-*-*-*-+ | GSS-TSIG, | | | +-*-*-*-*-*-*-*-*-+
| RSA-SHA] | +---------------+ | RFC3110] | +---------------+
+------------+ +------------+
Figure 1 DNSSEC Document Roadmap Figure 1 DNSSEC Document Roadmap
Rose [Page 4] Rose [Page 4]
@@ -259,8 +259,8 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
of the specification to be modified SHOULD be synopsized in the new of the specification to be modified SHOULD be synopsized in the new
document for the benefit of the reader. The "DNSSEC protocol" set document for the benefit of the reader. The "DNSSEC protocol" set
includes the documents [RFC2535], [RFC3007], [RFC3008], [RFC3090], includes the documents [RFC2535], [RFC3007], [RFC3008], [RFC3090],
[SIZE], [OKBIT], [ADBIT], [OPTIN], [PARSIG] and their derivative [SIZE], [OKBIT], [ADBIT], [OPTIN], [PARSIG], [PARKEY] and their
documents. derivative documents.
The "New Security RRs" set refers to the group of documents that seek The "New Security RRs" set refers to the group of documents that seek
to add additional Resource Records to the set of base DNS Record to add additional Resource Records to the set of base DNS Record
@@ -272,7 +272,7 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
that describe how a specific digital signature algorithm is imple- that describe how a specific digital signature algorithm is imple-
mented to fit the DNSSEC Resource Record format. Each one of these mented to fit the DNSSEC Resource Record format. Each one of these
documents deals with one specific digital signature algorithm. Exam- documents deals with one specific digital signature algorithm. Exam-
ples of this set include [RFC2536], [RFC2537], [RFC2539], [RSA-SHA] ples of this set include [RFC2536], [RFC2537], [RFC2539], [RFC3110]
and [GSS-TSIG]. and [GSS-TSIG].
The "Transactions" document set refers to the group of documents that The "Transactions" document set refers to the group of documents that
@@ -316,9 +316,10 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
tions, but can also point to places in the protocol specifications tions, but can also point to places in the protocol specifications
that need improvement. Documents in this set may be offspring of that need improvement. Documents in this set may be offspring of
both the DNSEXT and/or DNSOP Working Groups. Currently, there are both the DNSEXT and/or DNSOP Working Groups. Currently, there are
two Internet Drafts that fall under this category: the report on the three Internet Drafts that fall under this category: the report on
CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover the CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
[ROLLOVER]. These documents were submitted through the DNSOP Working [ROLLOVER] and the draft on resolver configured key rollover [RES-
ROLLOVER]. These documents were submitted through the DNSOP Working
Group, however the main concern of these documents is the implementa- Group, however the main concern of these documents is the implementa-
tion and limitations of the DNS security extensions, hence their tion and limitations of the DNS security extensions, hence their
interest to the DNS security community. The CAIRN draft deals with interest to the DNS security community. The CAIRN draft deals with
@@ -350,7 +351,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
SHOULD be interpreted as a minimum set of information required/needed SHOULD be interpreted as a minimum set of information required/needed
in a document, any additional information regarding the specific in a document, any additional information regarding the specific
extension should also be included in the document. These criteria extension should also be included in the document. These criteria
are not officially part of the IETF guidelines regarding RFC/Internet
@@ -363,6 +363,7 @@ Rose [Page 6]
INTERNET-DRAFT DNS Security Document Roadmap April 2001 INTERNET-DRAFT DNS Security Document Roadmap April 2001
are not officially part of the IETF guidelines regarding RFC/Internet
Drafts, but should be considered as guidance to promote uniformity to Drafts, but should be considered as guidance to promote uniformity to
Working Group documents. Working Group documents.
@@ -410,7 +411,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
In addition, authors are encouraged to include any necessary descrip- In addition, authors are encouraged to include any necessary descrip-
tion of the algorithm itself, as well as any know/suspected tion of the algorithm itself, as well as any know/suspected
weaknesses as an appendix to the document. This is for reference weaknesses as an appendix to the document. This is for reference
only, as the goals of the DNSEXT working group is to propose
@@ -423,7 +423,8 @@ Rose [Page 7]
INTERNET-DRAFT DNS Security Document Roadmap April 2001 INTERNET-DRAFT DNS Security Document Roadmap April 2001
extensions to the DNS protocol, not cryptographic research. only, as the goals of the DNSEXT working group is to propose exten-
sions to the DNS protocol, not cryptographic research.
4.3 Refinement of Security Procedures 4.3 Refinement of Security Procedures
@@ -470,7 +471,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
6. Acknowledgements 6. Acknowledgements
In addition to the RFCs mentioned in this document, there are also
@@ -483,6 +483,7 @@ Rose [Page 8]
INTERNET-DRAFT DNS Security Document Roadmap April 2001 INTERNET-DRAFT DNS Security Document Roadmap April 2001
In addition to the RFCs mentioned in this document, there are also
numerous Internet drafts that fall in one or more of the categories numerous Internet drafts that fall in one or more of the categories
of DNS Security documents mentioned above. Depending on where (and of DNS Security documents mentioned above. Depending on where (and
if) these documents are on the IETF standards track, the reader may if) these documents are on the IETF standards track, the reader may
@@ -505,8 +506,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
with Minimum Disclosure". <draft-ietf-dnsext-not-existing-rr-NN.txt> with Minimum Disclosure". <draft-ietf-dnsext-not-existing-rr-NN.txt>
* OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC". * OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC".
<draft-ietf-dnsext-dnssec-okbit-NN.txt> <draft-ietf-dnsext-dnssec-okbit-NN.txt>
* RSA-SHA: D. Eastlake. "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)" <draft-ietf-dnsext-rsa-NN.txt>
* ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS) * ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS)
Security Key Rollover" <draft-ietf-dnsopt-rollover-NN.txt>. Security Key Rollover" <draft-ietf-dnsopt-rollover-NN.txt>.
* ADBIT: B. Wellington. "Redefinition of DNS AD bit" <draft- * ADBIT: B. Wellington. "Redefinition of DNS AD bit" <draft-
@@ -515,8 +514,15 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
kosters-dnsext-dnssec-opt-in-NN.txt> kosters-dnsext-dnssec-opt-in-NN.txt>
* SSH-DNS: W. Griffin. "Storing SSH Host Keys in DNS" <draft- * SSH-DNS: W. Griffin. "Storing SSH Host Keys in DNS" <draft-
griffin-ssh-host-keys-in-dns-NN.txt> griffin-ssh-host-keys-in-dns-NN.txt>
* PARSIG: R. Geiben, T. Lindgreen. "Parent's SIG Over Child's * PARKEY: R. Geiben, T. Lindgreen. "Parent stores the child's
KEY" <draft-ietf-dnsext-parent-sig-NN.txt> zone KEYs" <draft-ietf-dnsext-parent-stores-zone-keys-NN.txt>
* PARSIG: R. Geiben, T. Lindgreen. "Parent's SIG over Child's KEY"
<draft-ietf-dnsext-parent-sig-NN.txt>
* DSIG: O. Gudmundsson. "Delegation Signer Record in Parent".
<draft-ietf-dnsext-delegation-signer-NN.txt>
* RESROLLOVER: O. Kolkman, M. Gieben, R. Arends. "Rollover of
statically configured resolver keys". <draft-ietf-dnsop-resolver-
rollover-NN.txt>
7. References 7. References
@@ -524,13 +530,7 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
[RFC2535] D. Eastlake, "Domain Name System Security Extensions", RFC [RFC2535] D. Eastlake, "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name Sys- [RFC2537] D. Eastlake, "RSA/MD5 KEYs and SIGs in the Domain Name
tem (DNS)", RFC 2537, March 1999.
[RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update",
@@ -543,6 +543,12 @@ Rose [Page 9]
INTERNET-DRAFT DNS Security Document Roadmap April 2001 INTERNET-DRAFT DNS Security Document Roadmap April 2001
System (DNS)", RFC 2537, March 1999.
[RFC2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update",
RFC 2137, April 1997. RFC 2137, April 1997.
[RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain [RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
@@ -554,9 +560,12 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
[RFC2930] D. Eastlake, "Secret Key Establishment for DNS" RFC 2930, [RFC2930] D. Eastlake, "Secret Key Establishment for DNS" RFC 2930,
September 2000. September 2000.
[RFC2931] D. Eastlake "DNS Request and Transaction Signatures [RFC2931] D. Eastlake, "DNS Request and Transaction Signatures
(SIG(0))" RFC 2931, September 2000. (SIG(0))" RFC 2931, September 2000.
[RFC3110] D. Eastlake, "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", May 2001.
[RFC3090] E. Lewis "DNS Security Extensions Clarification on Zone [RFC3090] E. Lewis "DNS Security Extensions Clarification on Zone
Status" RFC 3090, March 2001. Status" RFC 3090, March 2001.
@@ -585,15 +594,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001
8. Authors' Addresses
Scott Rose
National Institute for Standards and Technology
Gaithersburg, MD
Email: scott.rose@nist.gov
Rose [Page 10] Rose [Page 10]
@@ -603,9 +603,18 @@ Rose [Page 10]
INTERNET-DRAFT DNS Security Document Roadmap April 2001 INTERNET-DRAFT DNS Security Document Roadmap April 2001
8. Author's Addresses
Scott Rose
National Institute for Standards and Technology
Gaithersburg, MD
Email: scott.rose@nist.gov
Expiration and File Name: Expiration and File Name:
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-03.txt> expires November This draft, titled <draft-ietf-dnsext-dnssec-roadmap-04.txt> expires January 2001.
@@ -642,15 +651,6 @@ Full Copyright Statement
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
@@ -663,6 +663,15 @@ Rose [Page 11]
INTERNET-DRAFT DNS Security Document Roadmap April 2001 INTERNET-DRAFT DNS Security Document Roadmap April 2001
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
@@ -695,15 +704,6 @@ INTERNET-DRAFT DNS Security Document Roadmap April 2001

112
doc/draft/draft-ietf-dnsext-rfc2782bis-00.txt → doc/draft/draft-ietf-dnsext-rfc2782bis-01.txt
View File

@@ -5,10 +5,10 @@
Network Working Group A. Gulbrandsen Network Working Group A. Gulbrandsen
Category: INTERNET-DRAFT Trolltech AS Category: INTERNET-DRAFT Trolltech AS
Obsoletes: 2052 P. Vixie Obsoletes: 2782 P. Vixie
draft-ietf-dnsext-rfc2782bis-00.txt Internet Software Consortium draft-ietf-dnsext-rfc2782bis-01.txt Internet Software Consortium
November 16, 2000 L. Esibov June 6, 2001 L. Esibov
Expires: May 16, 2001 Microsoft Corp. Expires: December 6, 2001 Microsoft Corp.
@@ -35,7 +35,7 @@ Status of this Memo
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
@@ -63,9 +63,9 @@ Overview and rationale
Expires May 2001 [Page 1] Expires December 2001 [Page 1]
INTERNET-DRAFT DNS SRV RR Novemeber 2000 INTERNET-DRAFT DNS SRV RR June 2001
Definitions Definitions
@@ -119,9 +119,9 @@ The format of the SRV RR
Expires May 2001 [Page 2] Expires December 2001 [Page 2]
INTERNET-DRAFT DNS SRV RR Novemeber 2000 INTERNET-DRAFT DNS SRV RR June 2001
Some widely used services, notably POP, don't have a single Some widely used services, notably POP, don't have a single
@@ -175,9 +175,9 @@ INTERNET-DRAFT DNS SRV RR Novemeber 2000
Expires May 2001 [Page 3] Expires December 2001 [Page 3]
INTERNET-DRAFT DNS SRV RR Novemeber 2000 INTERNET-DRAFT DNS SRV RR June 2001
specified by the SRV RRs, will be contacted. The following specified by the SRV RRs, will be contacted. The following
@@ -231,9 +231,9 @@ Domain administrator advice
Expires May 2001 [Page 4] Expires December 2001 [Page 4]
INTERNET-DRAFT DNS SRV RR Novemeber 2000 INTERNET-DRAFT DNS SRV RR June 2001
suboptimal) fallback hosts for Telnet, NNTP and other protocols suboptimal) fallback hosts for Telnet, NNTP and other protocols
@@ -287,9 +287,9 @@ The "Weight" field
Expires May 2001 [Page 5] Expires December 2001 [Page 5]
INTERNET-DRAFT DNS SRV RR Novemeber 2000 INTERNET-DRAFT DNS SRV RR June 2001
The only way the authors can see of getting a "better" load figure is The only way the authors can see of getting a "better" load figure is
@@ -337,15 +337,17 @@ Usage rules
the reply: the reply:
If there is precisely one SRV RR, and its Target is "." If there is precisely one SRV RR, and its Target is "."
(the root domain), abort. (the root domain), abort and do not attempt lookup for
QNAME=domain, QCLASS=IN, QTYPE=A.
Expires May 2001 [Page 6]
INTERNET-DRAFT DNS SRV RR Novemeber 2000 Expires December 2001 [Page 6]
INTERNET-DRAFT DNS SRV RR June 2001
Else, for all such RR's, build a list of (Priority, Weight, Else, for all such RR's, build a list of (Priority, Weight,
@@ -399,9 +401,9 @@ Notes:
Expires May 2001 [Page 7] Expires December 2001 [Page 7]
INTERNET-DRAFT DNS SRV RR Novemeber 2000 INTERNET-DRAFT DNS SRV RR June 2001
- Future protocols could be designed to use SRV RR lookups as the - Future protocols could be designed to use SRV RR lookups as the
@@ -455,9 +457,9 @@ Fictional example
Expires May 2001 [Page 8] Expires December 2001 [Page 8]
INTERNET-DRAFT DNS SRV RR Novemeber 2000 INTERNET-DRAFT DNS SRV RR June 2001
In this example, a client of the "foobar" service in the In this example, a client of the "foobar" service in the
@@ -483,22 +485,40 @@ IANA Considerations
The IANA has assigned RR type value 33 to the SRV RR. No other IANA The IANA has assigned RR type value 33 to the SRV RR. No other IANA
services are required by this document. services are required by this document.
Changes from RFC 2052 Changes from RFC 2782
This document obsoletes RFC 2782
Only editorial clarifications were made to this document. Namely
- it was clarified that "Weight" subsection refers to real "random
number" rather than integer number;
- it was clarified that the "Name" used in the owner name of the SRV
record used in "The format of the SRV RR" section is a "Domain"
name;
- the "QNAME=_service._protocol.target" was replaced by
"QNAME=_service._protocol.domain" in "Usage rules" section to
eliminate a possibility of confusion with the Target field of the
SRV record.
- client's behavior when response to a query contains a single SRV
RR and its Target is "." is clarified in "Usage rules" section.
This document obsoletes RFC 2052. The major change from that
previous, experimental, version of this specification is that now the
protocol and service labels are prepended with an underscore, to
lower the probability of an accidental clash with a similar name used
for unrelated purposes. Aside from that, changes are only intended
to increase the clarity and completeness of the document. This
document especially clarifies the use of the Weight field of the SRV
records.
Security Considerations Security Considerations
The authors believe this RR to not cause any new security problems. The authors believe this RR to not cause any new security problems.
Some problems become more visible, though. Some problems become more visible, though.
Expires December 2001 [Page 9]
INTERNET-DRAFT DNS SRV RR June 2001
- The ability to specify ports on a fine-grained basis obviously - The ability to specify ports on a fine-grained basis obviously
changes how a router can filter packets. It becomes impossible changes how a router can filter packets. It becomes impossible
to block internal clients from accessing specific external to block internal clients from accessing specific external
@@ -510,18 +530,14 @@ Security Considerations
as servers. This could lead to denial of service. as servers. This could lead to denial of service.
Expires May 2001 [Page 9]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
- With SRV, DNS spoofers can supply false port numbers, as well as - With SRV, DNS spoofers can supply false port numbers, as well as
host names and addresses. Because this vulnerability exists host names and addresses. Because this vulnerability exists
already, with names and addresses, this is not a new already, with names and addresses, this is not a new
vulnerability, merely a slightly extended one, with little vulnerability, merely a slightly extended one, with little
practical effect. practical effect.
References References
STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
@@ -557,19 +573,9 @@ References
Expires December 2001 [Page 10]
INTERNET-DRAFT DNS SRV RR June 2001
Expires May 2001 [Page 10]
INTERNET-DRAFT DNS SRV RR Novemeber 2000
Acknowledgements Acknowledgements
@@ -623,14 +629,14 @@ Authors' Addresses
Expires May 2001 [Page 11] Expires December 2001 [Page 11]
INTERNET-DRAFT DNS SRV RR Novemeber 2000 INTERNET-DRAFT DNS SRV RR June 2001
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
@@ -679,4 +685,4 @@ Acknowledgement
Expires May 16, 2001 [Page 12] Expires December 6, 2001 [Page 12]

22
doc/draft/draft-ietf-idn-aceid-01.txt → doc/draft/draft-ietf-idn-aceid-02.txt
View File

@@ -1,7 +1,8 @@
Internet Draft Naomasa Maruyama Internet Draft Naomasa Maruyama
draft-ietf-idn-aceid-01.txt Yoshiro Yoneya draft-ietf-idn-aceid-02.txt Yoshiro Yoneya
Dec 11, 2000 JPNIC Jun 19, 2000 JPNIC
Expires June 11, 2001 Expires Dec 19, 2001
Proposal for a determining process of ACE identifier Proposal for a determining process of ACE identifier
@@ -87,14 +88,15 @@ domain name and those which have an ACE suffix identifier candidate at
the tail of at least one label of the name. These domain names are the tail of at least one label of the name. These domain names are
collectively called "relevant domain names". collectively called "relevant domain names".
This suspension should be continued until March 1, 2001 00:00:00 UTC. This suspension should be continued until September 1, 2001
00:00:00 UTC.
2.2 Survey of relevant domain name registration 2.2 Survey of relevant domain name registration
All registries recognized by ICANN SHOULD conduct a survey about All registries recognized by ICANN SHOULD conduct a survey about
relevant domain names registered in their zone, and report, no later relevant domain names registered in their zone, and report, no later
than February 10, 2001 00:00:00 UTC, all of the ACE identifier than August 11, 2001 00:00:00 UTC, all of the ACE identifier
candidates which are used by relevant domain names. candidates which are used by relevant domain names.
@@ -103,7 +105,7 @@ candidates which are used by relevant domain names.
The IDN WG or other organ of IETF or ICANN MUST summarize the The IDN WG or other organ of IETF or ICANN MUST summarize the
reports and list ACE identifier candidates that are not reported to be reports and list ACE identifier candidates that are not reported to be
used in registered domain names by February 17, 2001 00:00:00 UTC, and used in registered domain names by August 18, 2001 00:00:00 UTC, and
select ten to twenty ACE prefix identifier candidates and ten to select ten to twenty ACE prefix identifier candidates and ten to
twenty ACE suffix identifier candidates for ACE identifiers. Among twenty ACE suffix identifier candidates for ACE identifiers. Among
these twenty to forty ACE identifiers, one prefix identifier and one these twenty to forty ACE identifiers, one prefix identifier and one
@@ -111,7 +113,7 @@ suffix identifier will be used for experiments. Others will be used,
one by one as ACE standard evolves. one by one as ACE standard evolves.
The list of ACE identifiers will be sent to IANA, and will be The list of ACE identifiers will be sent to IANA, and will be
maintained by IANA from February 24, 2001 00:00:00 UTC. Domain names maintained by IANA from August 25, 2001 00:00:00 UTC. Domain names
relevant to these identifiers SHOULD NOT be registered in any DNS relevant to these identifiers SHOULD NOT be registered in any DNS
zone, except for registration of multilingual domain names compliant zone, except for registration of multilingual domain names compliant
to one of future IDN standards. This new restriction about the domain to one of future IDN standards. This new restriction about the domain
@@ -125,13 +127,13 @@ immediately after it receives the list.
described in section 2.3 SHOULD NOT be registered in any zone of ICANN described in section 2.3 SHOULD NOT be registered in any zone of ICANN
recognized registries except for registration of multilingual domain recognized registries except for registration of multilingual domain
names compliant to one of future IDN standards. All ICANN recognized names compliant to one of future IDN standards. All ICANN recognized
registries SHOULD implement this restriction no later than March 1, registries SHOULD implement this restriction no later than September 1,
2001 00:00:00 UTC. 2001 00:00:00 UTC.
Registration for domain names relevant to ACE identifier Registration for domain names relevant to ACE identifier
candidates, tentatively suspended by 2.1, but not relevant to ACE candidates, tentatively suspended by 2.1, but not relevant to ACE
identifiers selected by section 2.3 MAY be reopened from March 1, 2001 identifiers selected by section 2.3 MAY be reopened from September 1,
00:00:00 UTC. 2001 00:00:00 UTC.
3. Use of an ACE identifier in writing an ACE proposal 3. Use of an ACE identifier in writing an ACE proposal

173
doc/draft/draft-ietf-idn-idna-01.txt → doc/draft/draft-ietf-idn-idna-02.txt
View File

@@ -1,6 +1,6 @@
Internet Draft Patrik Faltstrom Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-01.txt Cisco draft-ietf-idn-idna-02.txt Cisco
Paul Hoffman June 16, 2001 Paul Hoffman
Expires in six months IMC & VPNC Expires in six months IMC & VPNC
Internationalizing Host Names In Applications (IDNA) Internationalizing Host Names In Applications (IDNA)
@@ -19,7 +19,6 @@ and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." 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
@@ -27,7 +26,6 @@ or to cite them other than as "work in progress."
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The current DNS infrastructure does not provide a way to use The current DNS infrastructure does not provide a way to use
@@ -58,8 +56,8 @@ the body of the message.
1.1 Design philosophy 1.1 Design philosophy
To date, the proposals for IDN protocols have required that DNS servers Many proposals for IDN protocols have required that DNS servers be
be updated to handle internationalized host names. Because of this, the updated to handle internationalized host names. Because of this, the
person who wanted to use an internationalized host name had to be sure person who wanted to use an internationalized host name had to be sure
that their request went to a DNS server that was updated for IDN. that their request went to a DNS server that was updated for IDN.
Further, that server could only send queries to other servers that had Further, that server could only send queries to other servers that had
@@ -69,13 +67,24 @@ these proposals require that resolvers must be updated to use the new
protocols, and in most cases the applications would need to be updated protocols, and in most cases the applications would need to be updated
as well. as well.
Updating all (or even a significant percentage) of the DNS servers in These proposals would require that the application protocols that use
the world will be difficult, to say the least. Because of this, we have host names as protocol elements to change. This is due to the
designed a protocol that requires no updating of any name servers. IDNA assumptions and requirements made in those protocols about the
still requires the updating of applications, but once a user has updated characters that have always been used for host names, and the encoding
these, she or he could immediately start using internationalized host of those characters. Other proposals for IDN protocols do not require
names. The cost of implementing IDN would thus be much lower, and the changes to DNS servers but still require changes to most application
speed of implementation will be much higher. protocols to handle the new names.
Updating all (or even a significant percentage) of the existing servers
in the world will be difficult, to say the least. Updating applications,
application gateways, and clients to handle changes to the application
protocols is also daunting. Because of this, we have designed a protocol
that requires no updating of any name servers. IDNA still requires the
updating of applications, but only for input and display of names, not
for changes to the protocols. Once a user has updated these, she or he
could immediately start using internationalized host names. The cost of
implementing IDN may thus be much lower, and the speed of implementation
could be much higher.
1.2 Terminology 1.2 Terminology
@@ -101,23 +110,26 @@ The interfaces in IDNA can be represented pictorially as:
^ ^
|Input and display: local interface methods |Input and display: local interface methods
|(pen, keyboard, glowing phosphorus, ...) |(pen, keyboard, glowing phosphorus, ...)
+--------------- v -------------------------------+ +-----------------|------------------------------+
| +-------------+ | | v |
| | Application | | End system | +--------------------------+ |
| +-------------+ | | Application | |
| ^ | +--------------------------+ |
| | API call and return: nameprepped ACE | ^ ^ |
| v | Call to resolver:| |Application-specific |
| +----------+ | nameprepped ACE| |protocol: |
| | Resolver | | v |predefined by the | End system
| +----------+ | | +----------+ |protocol or defaults |
+----------------^--------------------------------+ | | Resolver | |to nameprepped ACE |
| DNS query and response: nameprepped ACE | +----------+ | |
v | ^ | |
+-------------+ +---------------|----------|---------------------+
| DNS servers | DNS protocol:| |
+-------------+ nameprepped ACE| |
v v
+-------------+ +---------------------+
| DNS servers | | Application servers |
+-------------+ +---------------------+
This document uses the generic term "ACE" for an ASCII-compatible This document uses the generic term "ACE" for an ASCII-compatible
encoding. After the IDN Working Group has chosen a specific ACE, this encoding. After the IDN Working Group has chosen a specific ACE, this
@@ -125,7 +137,7 @@ document will be updated to refer to just that single ACE. Until that
time, an implementor creating experimental software must choose an ACE time, an implementor creating experimental software must choose an ACE
to use, such as RACE or LACE or DUDE. to use, such as RACE or LACE or DUDE.
2.1.1 Users and applications 2.1.1 Entry and display in applications
Applications can accept host names using any character set or sets Applications can accept host names using any character set or sets
desired by the application developer, and can display host names in any desired by the application developer, and can display host names in any
@@ -145,6 +157,23 @@ glyphs, the rendering engine for an application SHOULD have an option
for the user to select the preferred display; if it does, rendering the for the user to select the preferred display; if it does, rendering the
ACE SHOULD NOT be the default. ACE SHOULD NOT be the default.
Host names are often stored and transported in many places. For example,
they are part of documents such as mail messages and web pages. They are
transported in the many parts of many protocols, such as both the
control commands and the RFC 2822 body parts of SMTP, and the headers
and the body content in HTTP.
In protocols and document formats that define how to handle
specification or negotiation of charsets, IDN host name parts can be
given in any charset allowed by the protocol or document format. If a
protocol or document format only allows one charset, IDN host name parts
must be given in that charset.
All protocols that have host names as protocol elements already have the
capacity for handling host names in the ASCII charset. Thus, IDN host
name parts can be specified in those protocols in the ACE charset, which
is a superset of the ASCII charset that uses the same set of octets.
2.1.2 Applications and resolvers 2.1.2 Applications and resolvers
Applications communicate with resolver libraries through a programming Applications communicate with resolver libraries through a programming
@@ -193,6 +222,42 @@ possible in order to prevent users from seeing the ACE. However, this is
not considered a big problem because so few applications show this type not considered a big problem because so few applications show this type
of resolution to users. of resolution to users.
If an application decodes an ACE name but cannot show all of the
characters in the decoded name, such as if the name contains characters
that the output system cannot display, the application SHOULD show the
name in ACE format instead of displaying the name with the replacement
character (U+FFFD). This is to make it easier for the user to transfer
the name correctly to other programs using copy-and-paste techniques.
Programs that by default show the ACE form when they cannot show all the
characters in a name part SHOULD also have a mechanism to show the name
with as many characters as possible and replacement characters in the
positions where characters cannot be displayed.
2.1.5 Automatic detection of ACE
An application which receives a host name SHOULD verify whether or not
the host name is in ACE. This is possible by verifying the prefix in
each of the labels, and seeing whether or not the label is in ACE. This
MUST be done regardless of whether or not the communication channel used
(such as keyboard input, cut and paste, application protocol,
application payload, and so on) has negotiated ACE.
The reason for this requirement is that many applications are not
ACE-aware. Applications that are not ACE-aware will send host names in
ACE but mark the charset as being US-ASCII or some other charset which
has the characters that are valid in [STD13] as a subset.
2.1.6 Bidirectional text
In IDNA, bidirectional text is entered and displayed exactly as it is
specified in ISO/IEC 10646. Both ISO/IEC 10646 and the Unicode standard
have extensive discussion of how to deal with bidirectional text. Any
input mechanism and display mechanism that handles characters from
bidirectional scripts should already conform to those specifications.
Note that the formatting characters that manually change the direction
of display are prohibited by nameprep, thus making the task for input
and display mechanisms easier.
3. Name Server Considerations 3. Name Server Considerations
@@ -209,6 +274,8 @@ passed to an application, it will result in an error being passed to the
application with no error being reported to the name server. Further, no application with no error being reported to the name server. Further, no
application will ever ask for a name that is not legal in [NAMEPREP] application will ever ask for a name that is not legal in [NAMEPREP]
because requests always go through [NAMEPREP] before getting to the DNS. because requests always go through [NAMEPREP] before getting to the DNS.
Note that [NAMEPREP] describes how to handle versioning of unallocated
codepoints.
The host name data in zone files (as specified by section 5 of RFC 1035) The host name data in zone files (as specified by section 5 of RFC 1035)
MUST be both nameprepped and ACE encoded. MUST be both nameprepped and ACE encoded.
@@ -217,7 +284,7 @@ MUST be both nameprepped and ACE encoded.
4. Root Server Considerations 4. Root Server Considerations
Because there are no changes to the DNS protocols, adopting this Because there are no changes to the DNS protocols, adopting this
protocol has no effect on the root servers. protocol has no effect on the DNS root servers.
5. Security Considerations 5. Security Considerations
@@ -226,6 +293,17 @@ Much of the security of the Internet relies on the DNS. Thus, any change
to the characteristics of the DNS can change the security of much of the to the characteristics of the DNS can change the security of much of the
Internet. Internet.
This memo describes an algorithm which encodes characters that are not
valid according to STD3 and STD13 into octet values that are valid. No
security issues such as string length increases or new allowed values
are introduced by the encoding process or the use of these encoded
values, apart from those introduced by the ACE encoding itself.
When detecting an ACE-encoded host name, and decoding the ACE, care must
be taken that the resulting value(s) are valid characters which can be
handled by the application. This is described in more detail in section
2.1.4.
Host names are used by users to connect to Internet servers. The Host names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers single internationalized name could be connected to different servers
@@ -243,9 +321,6 @@ Internationalized Host Names", draft-ietf-idn-nameprep.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119. Requirement Levels", March 1997, RFC 2119.
[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
10646", January 1998, RFC 2279.
[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication [STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
and Support" (RFC 1123), STD 3, October 1989. and Support" (RFC 1123), STD 3, October 1989.
@@ -255,26 +330,23 @@ and Support" (RFC 1123), STD 3, October 1989.
STD 13, November 1987. STD 13, November 1987.
B. Changes from the -00 draft B. Changes from the -01 draft
Throughout: Changed "RACE" to "ACE" and removed RACE-specific wording. 1.1: Revised whole section to deal with more proposals.
1: Added pointer to the mailing list. 2.1: Clarified the ASCII art
1.3: Removed the [IDNCOMP] comparison section. 2.1.1: Changed the section title. Added the last three paragraphs.
2.1: Added the last paragraph discussing ACEs. 2.1.4: Added the second paragraph.
2.1.2: Changed the discussion of IPv6 APIs to say they are not 2.1.6: Added this section.
standards. Added reference to [STD3].
2.1.3: Added reference to [STD3]. Removed the sentence about making 2.1.5: Added this section.
things smaller.
3: Added reference to [STD3]. 3: Added note in the last sentence of second paragraph.
6: Added [STD3], and updated the reference info for [STD13]. 5: Added second and third paragraphs.
Removed [IDNCOMP].
C. Authors' Addresses C. Authors' Addresses
@@ -291,10 +363,3 @@ Internet Mail Consortium and VPN Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 USA Santa Cruz, CA 95060 USA
phoffman@imc.org phoffman@imc.org
--
Patrik F„ltstr÷m <paf@cisco.com> Cisco Systems
Consulting Engineer Office of the CSO
Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-8509
PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC