Commit a653c8b3 authored by Andreas Gustafsson's avatar Andreas Gustafsson
Browse files

updated drafts

parent 1adb182c
......@@ -4,10 +4,9 @@
DNSEXT Working Group Brian Wellington (Nominum)
INTERNET-DRAFT Olafur Gudmundsson (NAI Labs)
<draft-ietf-dnsext-ad-is-secure-00.txt> November 2000
<draft-ietf-dnsext-ad-is-secure-01.txt> January 2001
Updates: RFC 2535
......@@ -38,33 +37,33 @@ Status of this Memo
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
This draft expires on May 17, 2001.
This draft expires on July 19, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All rights reserved.
Copyright (C) The Internet Society (2001). All rights reserved.
Abstract
Based on implementation experience, the current definition of the AD
bit in the DNS header is not useful. This draft changes the
bit in the DNS header is not useful. This draft changes the
specification so that the AD bit is only set on answers where
signatures have been cryptographically verified.
Expires May 2001 [Page 1]
Expires July 2001 [Page 1]
INTERNET-DRAFT AD bit set on secure answers November 2000
INTERNET-DRAFT AD bit set on secure answers January 2001
1 - Introduction
Familiarity with the DNS system [RFC1034, RFC1035] and DNS security
extensions [RFC2535] is helpful but not necessary.
Familiarity with the DNS system [RFC1035] and DNS security extensions
[RFC2535] is helpful but not necessary.
As specified in RFC 2535 (section 6.1), the AD bit indicates in a
response that all the data included in the answer and authority
......@@ -112,9 +111,9 @@ INTERNET-DRAFT AD bit set on secure answers November 2000
Expires May 2001 [Page 2]
Expires July 2001 [Page 2]
INTERNET-DRAFT AD bit set on secure answers November 2000
INTERNET-DRAFT AD bit set on secure answers January 2001
If the answer section contains any data, the server MUST NOT include
......@@ -129,11 +128,11 @@ INTERNET-DRAFT AD bit set on secure answers November 2000
resolver policy is that it can trust the server.
A DNS server following this modified specification will only set the
AD bit when it has verified the data in the answer. In the case of a
primary server for a secure zone, the data MAY be considered
Authenticated, depending on local policy. Secondary servers SHOULD
NOT consider data Authenticated unless the zone was transfered
securely or the data was verified.
AD bit when it has cryptographically verified the data in the answer.
In the case of a primary server for a secure zone, the data MAY be
considered Authenticated, depending on local policy. Secondary
servers SHOULD NOT consider data Authenticated unless the zone was
transfered securely or the data was verified.
3 - Interpretation of the AD bit
......@@ -155,7 +154,7 @@ INTERNET-DRAFT AD bit set on secure answers November 2000
6 - Acknowledgments:
The following people have provided input on this document: Andreas
Gustafsson, Bob Halley, Steven Jacob,
Gustafsson, Bob Halley, Steven Jacob.
References:
......@@ -168,9 +167,9 @@ References:
Expires May 2001 [Page 3]
Expires July 2001 [Page 3]
INTERNET-DRAFT AD bit set on secure answers November 2000
INTERNET-DRAFT AD bit set on secure answers January 2001
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
......@@ -194,7 +193,7 @@ Authors Addresses
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
others, and derivative works that comment on or otherwise explain it
......@@ -224,4 +223,4 @@ Full Copyright Statement
Expires May 2001 [Page 4]
Expires July 2001 [Page 4]
IDN Working Group Edmon Chung & David Leung
Internet Draft Neteka Inc.
<draft-ietf-idn-dnsii-mdnp-01.txt> August 2000
<draft-ietf-idn-dnsii-mdnp-02.txt> February 2001
DNSII Multilingual Domain Name Protocol
The DNSII Multilingual Domain Name Protocol
STATUS OF THIS MEMO
......@@ -29,9 +29,21 @@ STATUS OF THIS MEMO
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
A copy of this particular draft is also archived at
http://www.dnsii.org.
Abstract
The core thinking for DNSII is that multilingual DNS requests SHOULD
be signaled within a DNS label whether by way of a binary tag or an
alphanumeric prefix, and that compatibility to legacy client
applications SHOULD be taken into concern alongside legacy server
implementations.
Besides the original specifications, four alternatives including the
use of EDNS are included for discussion purposes in this document.
Historically, the DNS is capable of handling only names within the
basic English alphanumeric character set (plus the hyphen), yet the
standards were so elegantly and openly designed that the extension of
......@@ -41,30 +53,25 @@ Abstract
These adjustments will be made on both the client side and the server
side. However, DNSII works on the principal that it is preferable to
make the transition to multilingual domain names seamless and
transparent to the end-user. Which means initially the server, or
more specifically, the resolver, SHOULD take the primary
responsibility for the technical implementation of the changes
required for a multilingual Internet.
DNSII-MDNP Multilingual Domain Name Protocol August 2000
transparent to the end-user. Which means initially the server SHOULD
take the primary responsibility for the technical implementation of
the changes required for a multilingual Internet.
The DNSII protocol is designed to allow the preservation of
interoperability, consistency and simplicity of the original DNS,
while being expandable and flexible for the handling of any character
or symbol used for the naming of an Internet domain. DNSII intends
to provide a platform for the implementation of multilingual domain
names. Besides the original specifications therefore, four
alternatives are included for discussion purposes in this document.
Chung & Leung [Page 1]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
This draft forms the introduction of a series of draft including
intended resolution processes and other DNSII documents.
names.
Table Of Contents
1. Introduction....................................................2
1.1 Terminology....................................................2
1.2 DNSII..........................................................2
1.2 DNSII..........................................................3
2. DNSII Protocol..................................................3
2.1 InPacket DNSII Identifier......................................3
2.2 InPacket Label Encoding Type (ILET)............................4
......@@ -102,19 +109,12 @@ Table Of Contents
A number of multilingual characters are used in this document for
examples. Please select your view encoding type to UTF-8 for it to
be displayed properly.
1.2 DNSII
Many of the current proposals for a multilingual domain name system
involve working around the current ANSI based DNS. So doing either
affects the integrity of the original spirit of the DNS or does not
well address the encoding conflict issues apparent in different
character encoding schemes.
Chung & Leung [Page 2]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
1.2 DNSII
The DNSII specifications takes a radically different approach: it
successfully identifies the difference between original DNS and DNSII
packets within the labels and at the same time allows the use of
......@@ -165,10 +165,7 @@ Chung & Leung [Page 2]
scheme.
Chung & Leung [Page 3]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
2.2 InPacket Label Encoding Type (ILET)
......@@ -398,7 +395,7 @@ Chung & Leung [Page 6]
Chung & Leung [Page 7]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
Although this takes away some of the benefits of keeping the local
encoding scheme which includes the issues of case folding,
canonicalization and other related concerns, it creates a system that
......@@ -512,7 +509,7 @@ Chung & Leung [Page 8]
Chung & Leung [Page 9]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
The OPT RR could be used not only for version control but also as a
notification for the destination server on the level of conformance
of the inquirer. This is especially beneficial when considering the
......@@ -682,7 +679,7 @@ Chung & Leung [Page 11]
Chung & Leung [Page 12]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
: :
/ /
+---------------------------------------------------------------+
......@@ -712,7 +709,7 @@ Chung & Leung [Page 12]
http://www.dnsii.org.
8. References
[DNSII-MDNR] E. Chung, D. Leung, _DNSII Multilingual Domain Name
Resolution_, August 2000
......@@ -739,10 +736,10 @@ Chung & Leung [Page 12]
Chung & Leung [Page 13]
DNSII-MDNP Multilingual Domain Name Protocol August 2000
[RFC2277] H. Alvestrand, _IETF Policy on Character Sets and
Languages_ RFC 2277, January 1998
[RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)",
August 1999, RFC 2671.
......@@ -795,5 +792,3 @@ Chung & Leung [Page 13]
Chung & Leung [Page 14]
IDN Working Group Edmon Chung & David Leung
Internet Draft Neteka Inc.
<draft-ietf-idn-dnsii-mdnr-00.txt> August 2000
<draft-ietf-idn-dnsii-mdnr-01.txt> February 2001
......@@ -30,33 +30,37 @@ STATUS OF THIS MEMO
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
A copy of this particular draft is also archived at
http://www.dnsii.org.
Abstract
This document outlines a resolution process that forms a framework
for the resolution of multilingual domain names. Additionally, a
tunneling mechanism utilizing additional RRs is introduced for the
transition to a fully multilingual capable name space.
The Internet-Draft for DNSII-MDNP was focused purely on discussing
the ultimate packet protocol that is being sent around the Internet
for multilingual domain names. This paper complements the previous
paper by outlining the contemplated resolution process with the DNSII
protocol throughout the DNS name resolution process.
The DNSII-MDNR outlines a resolution process that forms a framework
for the resolution of multilingual domain names. Whether the DNSII
protocol is implemented exactly as specified in DNSII-MDNP is less
relevant, rather it is the idea of having a multilingual packet
identifier and the fall back process that matters. The DNSII-MDNR
successfully addresses the transitional issues at each node of the
DNS resolution process providing a clear migration path and strategy
for the deployment of a multilingual enabled DNS system. It also
outlines the conformance levels required for basic or complete
implementations for applications, resolvers and name servers.
This document also introduces a tunneling mechanism for the short-run
to transition the system through to a truly multilingual capable name
space.
Whether the DNSII protocol is implemented exactly as specified in
DNSII-MDNP is less relevant, rather it is the idea of having a
multilingual packet identifier and the fall back process that
matters. The DNSII-MDNR successfully addresses the transitional
issues at each node of the DNS resolution process providing a clear
migration path and strategy for the deployment of a multilingual
Chung & Leung [Page 1]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
enabled DNS system. It also outlines the conformance levels required
for basic or complete implementations for applications, resolvers and
name servers.
Table of Contents
1. Introduction....................................................2
......@@ -103,6 +107,11 @@ Table of Contents
and "MAY" in this document are to be interpreted as described in RFC
2119 [RFC2119].
DNSII-MDNR Multilingual Domain Name Resolution August 2000
A number of multilingual characters are used in this document for
examples. Please select your view encoding type to Big-5
(Traditional Chinese) for them to be displayed properly.
......@@ -110,10 +119,6 @@ Table of Contents
Chung & Leung [Page 2]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
1.2 Multilingual Domain Name Resolution
The original specifications for the DNS were designed to be open
......@@ -160,15 +165,7 @@ Chung & Leung [Page 2]
Chung & Leung [Page 3]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
+---------------+
......@@ -225,7 +222,6 @@ Chung & Leung [Page 3]
Chung & Leung [Page 4]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Case folding for multilingual domain names should follow the existing
......@@ -282,7 +278,6 @@ Chung & Leung [Page 4]
Eventually, an ISO 10646 UCS without transformation is desired as the
common format. The benefits of having a uniform byte length encoding
Chung & Leung [Page 5]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
far exceeds the seemingly easier transformation solution. Especially
......@@ -320,7 +315,7 @@ Chung & Leung [Page 5]
| | (3) Upon the detection | |
| | of the DNSII Flag | |
| | resolver will reply | |
| | with "Format Error" | |
| | with _Format Error_ | |
| | | |
| |----------------------->| | (5) Current resolu-
| | (4) Send QNAME using | | tion process begins
......@@ -339,7 +334,6 @@ Chung & Leung [Page 5]
Chung & Leung [Page 6]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
It is not feasible to have a new RR type just for DNSII because the
......@@ -358,7 +352,7 @@ Chung & Leung [Page 6]
It is possible to use ACE/RACE type translations at this level,
however it is more advisable to use a truly arbitrary label such as
"-for-tunneling-only-". So doing requires only reserving one
_-for-tunneling-only-_. So doing requires only reserving one
arbitrary name while ACE/RACE creates one more arbitrary name for
each new multilingual name registered, which will eventually
contribute to the fracturing of the DNS.
......@@ -396,7 +390,6 @@ Chung & Leung [Page 6]
Chung & Leung [Page 7]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
(The Additional DNSII RR Tunneled in TXT RR form)
......@@ -414,7 +407,7 @@ Chung & Leung [Page 7]
+---------------------------------------------------------------+
96| t |1 0|0 0| UCS-2=1000 | 4 |
+---------------------------------------------------------------+
100|1 1| 13 |1 0|z| ILET=2 | 4 |
100|1 1| 13 |1 0|z| ILET=2 | 4 |
+---------------------------------------------------------------+
104| —Œ (U+57DF) | ªW (U+540D) |
+---------------------------------------------------------------+
......@@ -453,7 +446,6 @@ Chung & Leung [Page 7]
Chung & Leung [Page 8]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Following the example given in 3.2.1, the QNAME would be in UTF-8
......@@ -491,7 +483,7 @@ Chung & Leung [Page 8]
resolution strategy for resolvers would simply be to pass along the
labels in their 8-bit format and determine the existence of the
requested name as usual. If a tunneled DNSII RR is detected, by way
of a label constituting entirely of "-for-tunneling-only-" and the
of a label constituting entirely of _-for-tunneling-only-_ and the
existence of a valid DNSII RR, the resolver should attempt to resolve
the name according to the DNSII specification and tunnel the answer
back to the inquirer.
......@@ -508,9 +500,8 @@ Chung & Leung [Page 8]
Continuing on the example given in Section 3.2, suppose an A record
is requested and the IP address returned for the domain host.—ŒªW¿t™ð
Chung & Leung [Page 9]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
.tld. is 123.4.5.6, then an additional DNSII ANS RR (TXT) in the
......@@ -567,9 +558,10 @@ Chung & Leung [Page 9]
necessary for all servers and applications to be switched to
multilingual capable before starting the deployment.
Chung & Leung [Page 10]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
4.1 Application Conformance Levels
The BASIC compliancy for applications would be to remove validity
......@@ -622,8 +614,6 @@ Chung & Leung [Page 10]
should however prepare for the transition towards a multilingual name
space even if they do not intend to deploy it right away.
Chung & Leung [Page 11]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
......@@ -680,7 +670,6 @@ Chung & Leung [Page 11]
resolution.
Chung & Leung [Page 12]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
6.1 Client/Application Resolution Strategy
......@@ -689,7 +678,7 @@ Chung & Leung [Page 12]
IF RCODE = Format Error
THEN send query in UTF-8/Local Encoding AND append DNSII RR
IF RCODE = Format Error
THEN send Query in ASCII with "-for-tunneling-only-" label
THEN send Query in ASCII with _-for-tunneling-only-_ label
AND append DNSII RR
AND check for DNSII ANS RR in response
ELSE proceed and check for DNSII ANS RR in response
......@@ -703,7 +692,7 @@ Chung & Leung [Page 12]
IF encounter RCODE = Format Error
THEN send query in UTF-8 AND append DNSII RR
IF RCODE = Format Error
THEN send query in ASCII with "-for-tunneling-only-"
THEN send query in ASCII with _-for-tunneling-only-_
label
AND append DNSII RR
AND check for DNSII ANS RR in response
......@@ -737,7 +726,6 @@ Chung & Leung [Page 12]
ELSE use InZone DNSII mechanisms AND use 8-bit clean approach
Chung & Leung [Page 13]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
7. Security Considerations
......@@ -794,8 +782,7 @@ Chung & Leung [Page 13]
Chung & Leung [Page 14]
DNSII-MDNR Multilingual Domain Name Resolution August 2000
DNSII-MDNR Multilingual Domain Name Resolution August 2000
Authors:
......@@ -848,8 +835,7 @@ DNSII-MDNR Multilingual Domain Name Resolution August 2000
Chung & Leung [Page 15]
\ No newline at end of file
Internet Draft Paul Hoffman
draft-ietf-idn-idna-00.txt IMC & VPNC
September 12, 2000 Patrik Faltstrom
Expires in six months Cisco
Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-01.txt Cisco
Paul Hoffman
Expires in six months IMC & VPNC
Internationalizing Host Names In Applications (IDNA)
Internationalizing Host Names In Applications (IDNA)
Status of this Memo
......@@ -20,11 +20,11 @@ time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
......@@ -51,6 +51,11 @@ proposal is that only user applications be updated; no changes are
needed to the DNS protocol or any DNS servers or the resolvers on user's
computers.
This document is being discussed on the ietf-idna@mail.apps.ietf.org
mailing list. To subscribe, send a message to
ietf-idna-request@mail.apps.ietf.org with the single word "subscribe" in
the body of the message.
1.1 Design philosophy
To date, the proposals for IDN protocols have required that DNS servers
......@@ -67,10 +72,10 @@ as well.
Updating all (or even a significant percentage) of the DNS servers in
the world will be difficult, to say the least. Because of this, we have
designed a protocol that requires no updating of any name servers. IDNA
still requires the updating of applications, but once a
user has updated these, she or he could immediately start using
internationalized host names. The cost of implementing IDN would thus be
much lower, and the speed of implementation will be much higher.
still requires the updating of applications, but once a user has updated
these, she or he could immediately start using internationalized host
names. The cost of implementing IDN would thus be much lower, and the
speed of implementation will be much higher.
1.2 Terminology
......@@ -78,15 +83,6 @@ The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
1.3 IDN summary
Using the terminology in [IDNCOMP], this protocol specifies an IDN
architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE),
and the method for distinguishing ACE name parts from current name parts
is ace-2.1.1 (add hopefully-unique legal tag). Because there is no
changes needed to the DNS, the transition strategy is trans-1 (always do
current plus new architecture).
2. Structural Overview
......@@ -99,29 +95,35 @@ and process the inputs and outputs from the DNS.
The interfaces in IDNA can be represented pictorially as:
+------+
| User |
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
+--------------- v -------------------------------+
| +-------------+ |
| | Application | | End system
| +-------------+
| ^
| | API call and return: nameprepped RACE
| v
| +----------+
| | Resolver |
| +----------+ |
+----------------^--------------------------------+
| DNS query and response: nameprepped RACE
v
+-------------+
| DNS servers |
+-------------+
+------+
| User |
+------+
^
| Input and display: local interface methods
| (pen, keyboard, glowing phosphorus, ...)
+--------------- v -------------------------------+
| +-------------+ |
| | Application | | End system
| +-------------+
| ^
| | API call and return: nameprepped ACE
| v
| +----------+
| | Resolver |
| +----------+ |
+----------------^--------------------------------+
| DNS query and response: nameprepped ACE