ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2001-03-08 15:54:40 +00:00
parent 590233519e
commit 9b850d4bd0
8 changed files with 7366 additions and 644 deletions
Download Patch File Download Diff File Expand all files Collapse all files

106
doc/draft/draft-ietf-dnsext-apl-rr-01.txt → doc/draft/draft-ietf-dnsext-apl-rr-02.txt
View File

@@ -1,9 +1,15 @@
INTERNET-DRAFT Peter Koch
Expires: December 2000 Universitaet Bielefeld
Updates: RFC 1035 June 2000
Expires: September 2001 Universitaet Bielefeld
Updates: RFC 1035 March 2001
A DNS RR Type for Lists of Address Prefixes (APL RR)
draft-ietf-dnsext-apl-rr-01.txt
draft-ietf-dnsext-apl-rr-02.txt
Status of this Memo
@@ -28,7 +34,7 @@ Status of this Memo
http://www.ietf.org/shadow.html.
Comments should be sent to the author or the DNSEXT WG mailing list
<namedroppers@internic.net>.
<namedroppers@OPS.IETF.ORG>.
Abstract
@@ -49,9 +55,9 @@ Abstract
Koch Expires December 2000 [Page 1]
Koch Expires September 2001 [Page 1]
INTERNET-DRAFT DNS APL RR June 2000
INTERNET-DRAFT DNS APL RR March 2001
2. Background
@@ -59,7 +65,7 @@ INTERNET-DRAFT DNS APL RR June 2000
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
associate addresses and other Internet infrastructure elements with
hierarchically built domain names. Various types of resource records
have been defined, especially those for IPv4 and IPv6 [RFCxxxx]
have been defined, especially those for IPv4 and IPv6 [RFC2874]
addresses. In [RFC1101] a method is described to publish information
about the address space allocated to an organisation. In older BIND
versions, a weak form of controlling access to zone data was
@@ -76,8 +82,8 @@ INTERNET-DRAFT DNS APL RR June 2000
4. APL RDATA format
The RDATA section consists of zero or more strings (<apstring>) of
the form
The RDATA section consists of zero or more items (<apitem>) of the
form
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
@@ -105,9 +111,9 @@ INTERNET-DRAFT DNS APL RR June 2000
Koch Expires December 2000 [Page 2]
Koch Expires September 2001 [Page 2]
INTERNET-DRAFT DNS APL RR June 2000
INTERNET-DRAFT DNS APL RR March 2001
This document defines the AFDPARTs for address families 1 (IPv4) and
@@ -161,9 +167,9 @@ INTERNET-DRAFT DNS APL RR June 2000
Koch Expires December 2000 [Page 3]
Koch Expires September 2001 [Page 3]
INTERNET-DRAFT DNS APL RR June 2000
INTERNET-DRAFT DNS APL RR March 2001
immediately followed by the "/" character, immediately followed by a
@@ -174,27 +180,26 @@ INTERNET-DRAFT DNS APL RR June 2000
5.1. Textual Representation of IPv4 Addresses
An IPv4 address in the <address> part of an <apstring> is in dotted
An IPv4 address in the <address> part of an <apitem> is in dotted
quad notation, just as in an A RR. The <prefix> has values from the
interval 0..32 (decimal).
5.2. Textual Representation of IPv6 Addresses
The representation of an IPv6 address in the <address> part of an
<apstring> follows [RFC2373], section 2.2. Legal values for <prefix>
<apitem> follows [RFC2373], section 2.2. Legal values for <prefix>
are from the interval 0..128 (decimal).
6. APL RR usage
An APL RR with empty RDATA is valid and implements an empty list.
Multiple occurrences of the same <apstring> in a single APL RR are
allowed and MUST NOT be merged by a DNS server or resolver.
<apstrings> MUST be kept in order and MUST NOT be rearranged or
aggregated.
Multiple occurrences of the same <apitem> in a single APL RR are
allowed and MUST NOT be merged by a DNS server or resolver. <apitems>
MUST be kept in order and MUST NOT be rearranged or aggregated.
A single APL RR may contain <apstrings> belonging to different
address families. The maximum number of <apstrings> is upper bounded
by the available RDATA space.
A single APL RR may contain <apitems> belonging to different address
families. The maximum number of <apitems> is upper bounded by the
available RDATA space.
RRSets consisting of more than one APL RR are legal but the
interpretation is left to the particular application.
@@ -217,9 +222,10 @@ INTERNET-DRAFT DNS APL RR June 2000
Koch Expires December 2000 [Page 4]
Koch Expires September 2001 [Page 4]
INTERNET-DRAFT DNS APL RR June 2000
INTERNET-DRAFT DNS APL RR March 2001
o which address families are expected to appear in the APL RRs for
@@ -246,20 +252,20 @@ INTERNET-DRAFT DNS APL RR June 2000
application does exist now or will exist in the future.
; RFC 1101-like announcement of address ranges for foo.example
foo.example APL 1:192.168.32.0/21 !1:192.168.38.0/28
foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
; CIDR blocks covered by classless delegation
42.168.192.IN-ADDR.ARPA APL ( 1:192.168.42.0/26 1:192.168.42.64/26
1:192.168.42.128/25 )
42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
1:192.168.42.128/25 )
; Zone transfer restriction
_axfr.sbo.example APL 1:127.0.0.1/32 1:172.16.64.0/22
_axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
; List of address ranges for multicast
multicast.example APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
Note that since trailing zeroes are ignored in the first APL RR the
AFDLENGTH of both <apstrings> is three.
AFDLENGTH of both <apitems> is three.
9. Security Considerations
@@ -273,9 +279,9 @@ INTERNET-DRAFT DNS APL RR June 2000
Koch Expires December 2000 [Page 5]
Koch Expires September 2001 [Page 5]
INTERNET-DRAFT DNS APL RR June 2000
INTERNET-DRAFT DNS APL RR March 2001
10. IANA Considerations
@@ -284,14 +290,15 @@ INTERNET-DRAFT DNS APL RR June 2000
This document does not define any new namespaces. It uses the 16 bit
identifiers for address families maintained by IANA in
ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers.
http://www.iana.org/numbers.html.
IANA is asked to assign a numeric RR type value for APL.
11. Acknowledgements
The author would like to thank Mark Andrews for his review and
constructive comments.
The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
and constructive comments.
12. References
@@ -305,10 +312,6 @@ INTERNET-DRAFT DNS APL RR June 2000
[RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other
Types", RFC 1101, April 1989
[RFCxxxx] Crawford,M., Huitema,C., Thomson,S., "DNS Extensions to
Support IPv6 Address Aggregation and Renumbering", work in
progress
[RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997
@@ -325,18 +328,18 @@ INTERNET-DRAFT DNS APL RR June 2000
Considerations Section in RFCs", RFC 2434, BCP 26, October
1998
Koch Expires December 2000 [Page 6]
INTERNET-DRAFT DNS APL RR June 2000
[RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
2535, March 1999
Koch Expires September 2001 [Page 6]
INTERNET-DRAFT DNS APL RR March 2001
[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
RFC 2606, BCP 32, June 1999
@@ -344,6 +347,10 @@ INTERNET-DRAFT DNS APL RR June 2000
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000
[RFC2874] Crawford,M., Huitema,C., "DNS Extensions to Support IPv6
Address Aggregation and Renumbering", RFC 2874, July 2000
13. Author's Address
@@ -384,5 +391,4 @@ INTERNET-DRAFT DNS APL RR June 2000
Koch Expires December 2000 [Page 7]
Koch Expires September 2001 [Page 7]

190
doc/draft/draft-ietf-dnsext-dhcid-rr-01.txt → doc/draft/draft-ietf-dnsext-dhcid-rr-02.txt
View File

@@ -1,15 +1,15 @@
Network Working Group M. Stapp
DNSEXT Working Group M. Stapp
Internet-Draft Cisco Systems, Inc.
Expires: June 1, 2001 T. Lemon
Expires: August 31, 2001 T. Lemon
A. Gustafsson
Nominum, Inc.
December 2000
March 2, 2001
A DNS RR for Encoding DHCP Information
<draft-ietf-dnsext-dhcid-rr-01.txt>
<draft-ietf-dnsext-dhcid-rr-02.txt>
Status of this Memo
@@ -32,17 +32,17 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2001.
This Internet-Draft will expire on August 31, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
A situation can arise where multiple DHCP clients request the same
DNS name from their (possibly distinct) DHCP servers. To resolve
such conflicts, 'Resolution of DNS Name Conflicts'[5] proposes
such conflicts, 'Resolution of DNS Name Conflicts'[6] proposes
storing client identifiers in the DNS to unambiguously associate
domain names with the DHCP clients "owning" them. This memo defines
a distinct RR type for use by DHCP servers, the "DHCID" RR.
@@ -52,9 +52,9 @@ Abstract
Stapp, et. al. Expires June 1, 2001 [Page 1]
Stapp, et. al. Expires August 31, 2001 [Page 1]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
Table of Contents
@@ -65,10 +65,10 @@ Table of Contents
4. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Appendix A: Base 64 Encoding . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Appendix A: Base 64 Encoding . . . . . . . . . . . . . . . . . 5
References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
@@ -108,9 +108,9 @@ Table of Contents
Stapp, et. al. Expires June 1, 2001 [Page 2]
Stapp, et. al. Expires August 31, 2001 [Page 2]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
1. Terminology
@@ -122,12 +122,12 @@ Internet-Draft A DNS RR for Encoding DHCP Information December 2000
2. Introduction
A set of procedures to allow DHCP[2] clients and servers to
automatically update the DNS (RFC1034[3], RFC1035[4]) is proposed in
"Resolution of DNS Name Conflicts"[5].
automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in
"Resolution of DNS Name Conflicts"[6].
A situation can arise where multiple DHCP clients wish to use the
same DNS name. To resolve such conflicts, Resolution of DNS Name
Conflicts[5] proposes storing client identifiers in the DNS to
Conflicts[6] proposes storing client identifiers in the DNS to
unambiguously associate domain names with the DHCP clients using
them. In the interest of clarity, it would be preferable for this
DHCP information to use a distinct RR type.
@@ -146,46 +146,55 @@ Internet-Draft A DNS RR for Encoding DHCP Information December 2000
interpretation by DHCP servers and clients are described below.
DNS software should consider the RDATA section to be opaque. In DNS
master files, the RDATA is represented in base 64 (see Appendix A)
and may be divided up into any number of white space separated
substrings, down to single base 64 digits, which are concatenated to
obtain the full signature. These substrings can span lines using
the standard parenthesis. This format is identical to that used for
representing binary data in DNSSEC (RFC2535[6]).
master files, the RDATA is represented in base 64 encoding (see
Appendix A (Section 7)) and may be divided up into any number of
white space separated substrings, down to single base 64 digits,
which are concatenated to obtain the full signature. These
substrings can span lines using the standard parenthesis. This
format is identical to that used for representing binary data in
DNSSEC (RFC2535[7]).
DHCP clients or servers use the DHCID RR to associate a DHCP
client's identity with a DNS name, so that multiple DHCP clients and
servers may safely perform dynamic DNS updates to the same zone.
From the updater's perspective, the DHCID resource record consists
of a 16-bit identifier type, followed by one or more bytes
representing the actual identifier. There are two possible forms
for a DHCID RR - one that is used when the DHCP server is using the
client's link-layer address to identify it, and one that is used
when the DHCP server is using some DHCP option that the DHCP client
representing the actual identifier.
The type code can have one of three classes of values. The first
Stapp, et. al. Expires June 1, 2001 [Page 3]
Stapp, et. al. Expires August 31, 2001 [Page 3]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
sent to identify it. When the link-layer address is used as the
identifier, the first two bytes of the RRDATA are set to 0. When a
DHCP option is used as the identifier, the first two bytes of the
RRDATA contain the option number, in network byte order. The two
bytes 0xffff are reserved for future extensibility. In both cases,
the remainder of the RRDATA is the result of performing a one-way
hash across the identifier.
class contains just the value zero. This type indicates that the
remaining contents of the DHCID record encode an identifier that is
based on the client's link-layer network address.
The details of the method used to generate the data in the RR and
the use to which a DHCP client or server may put this association
are beyond the scope of this draft, and are discussed in the
specification of the DNS update behavior, 'Resolution of DNS Name
Conflicts'[5]. This RR MUST NOT be used for any purpose other than
that detailed in the DHC document. Althought this RR contains data
that is opaque to DNS servers, the data is meaningful to DHCP
updaters. Therefore, new data formats may only be defined through
actions of the DHC Working Group.
The second class of types contains just the value 0xFFFF. This type
code is reserved for future extensibility.
The third class of types contains all the values not included in the
first two - that is, every value other than zero or 0xFFFF. Types in
this class indicate that the remaining contents of the DHCID record
encode an identifier that is based on the DHCP option whose code is
the same as the specified type. The most common value in this class
at the time of the writing of this draft is 61, which is the DHCP
option code[3] for the Client Identifier option.
The data following the type code (for type codes other than 0xFFFF)
is derived by running a one-way hash across the identifying
information. The details of this are specified in "Resolution of
DNS Name Conflicts"[6].
This RR MUST NOT be used for any purpose other than that detailed in
"Resolution of DNS Name Conflicts"[6]. Althought this RR contains
data that is opaque to DNS servers, the data must be consistent
across all entities that update and interpret this record.
Therefore, new data formats may only be defined through actions of
the DHC Working Group, as a result of revising [6].
4.1 Example
@@ -194,14 +203,14 @@ Internet-Draft A DNS RR for Encoding DHCP Information December 2000
identify the client:
client.org.nil. A 10.0.0.1
client.org.nil. DHCID AAAY KREX Igqt wYgQ o93/ yNlJ
client.org.nil. DHCID AAAYKREXIgqtwYgQo93/yNlJ
A DHCP server allocating the IPv4 address 10.0.12.99 to a client
"chi.org.nil" might use the DHCP client identifier option to
identify the client:
chi.org.nil. A 10.0.12.99
chi.org.nil. DHCID AGGS cSLa AYjd OhGM HKD/ lJ2B
chi.org.nil. DHCID AGGScSLaAYjdOhGMHKD/lJ2B
5. Security Considerations
@@ -210,6 +219,12 @@ Internet-Draft A DNS RR for Encoding DHCP Information December 2000
information about DHCP clients to public scrutiny, a one-way-hash is
used to obscure all client information.
Stapp, et. al. Expires August 31, 2001 [Page 4]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
6. IANA Considerations
IANA is requested to allocate an RR type number for the DHCID record
@@ -217,14 +232,7 @@ Internet-Draft A DNS RR for Encoding DHCP Information December 2000
7. Appendix A: Base 64 Encoding
The following encoding technique is taken from RFC 2045[7] by N.
Stapp, et. al. Expires June 1, 2001 [Page 4]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
The following encoding technique is taken from RFC 2045[8] by N.
Borenstein and N. Freed. It is reproduced here in an edited form
for convenience.
@@ -266,6 +274,13 @@ Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Special processing is performed if fewer than 24 bits are available
Stapp, et. al. Expires August 31, 2001 [Page 5]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a quantity. When fewer than 24 input
bits are available in an input group, zero bits are added (on the
@@ -274,13 +289,6 @@ Internet-Draft A DNS RR for Encoding DHCP Information December 2000
base 64 input is an integral number of octets, only the following
cases can arise: (1) the final quantum of encoding input is an
integral multiple of 24 bits; here, the final unit of encoded output
Stapp, et. al. Expires June 1, 2001 [Page 5]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
will be an integral multiple of 4 characters with no "=" padding,
(2) the final quantum of encoding input is exactly 8 bits; here, the
final unit of encoded output will be two characters followed by two
@@ -296,23 +304,39 @@ References
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar
1997.
[3] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
[3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Mar 1997.
[4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, Nov 1987.
[4] Mockapetris, P., "Domain names - Implementation and
[5] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, Nov 1987.
[5] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
[6] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
(draft-ietf-dhc-dns-resolution-*)", July 2000.
[6] Eastlake, D., "Domain Name System Security Extensions", RFC
[7] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
Stapp, et. al. Expires August 31, 2001 [Page 6]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
Authors' Addresses
Mark Stapp
@@ -325,18 +349,6 @@ Authors' Addresses
EMail: mjs@cisco.com
Stapp, et. al. Expires June 1, 2001 [Page 6]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Ted Lemon
Nominum, Inc.
950 Charter St.
@@ -376,26 +388,14 @@ Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Stapp, et. al. Expires June 1, 2001 [Page 7]
Stapp, et. al. Expires August 31, 2001 [Page 7]
Internet-Draft A DNS RR for Encoding DHCP Information December 2000
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
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
@@ -444,5 +444,5 @@ Acknowledgement
Stapp, et. al. Expires June 1, 2001 [Page 8]
Stapp, et. al. Expires August 31, 2001 [Page 8]

365
doc/draft/draft-ietf-dnsext-gss-tsig-01.txt → doc/draft/draft-ietf-dnsext-gss-tsig-02.txt
View File

@@ -1,11 +1,13 @@
INTERNET-DRAFT Stuart Kwan
<draft-ietf-dnsext-gss-tsig-01.txt> Praerit Garg
James Gilroy
Levon Esibov
<draft-ietf-dnsext-gss-tsig-02.txt> Praerit Garg
March 1, 2001 James Gilroy
Expires September 1, 2001 Levon Esibov
Microsoft Corp.
November 22, 2000
Expires May 22, 2001
Randy Hall
Lucent Technologies
GSS Algorithm for TSIG (GSS-TSIG)
@@ -52,11 +54,9 @@ Application Program Interface (GSS-API) (RFC2743).
Expires September 1, 2001 [Page 1]
Expires May 2001 [Page 1]
INTERNET-DRAFT GSS-TSIG November 22, 2000
INTERNET-DRAFT GSS-TSIG March 1, 2001
Table of Contents
@@ -69,22 +69,23 @@ Table of Contents
3.1.2: Send TKEY Query to Server.................................6
3.1.3: Receive TKEY Query-Response from Server...................7
3.2: Context Established...........................................9
4: Server Protocol Details...........................................9
4.1: Negotiating Context...........................................9
3.2.1: Terminating a Context.....................................9
4: Server Protocol Details..........................................10
4.1: Negotiating Context..........................................10
4.1.1: Receive TKEY Query from Client...........................10
4.1.2: Call GSS_Accept_sec_context..............................10
4.1.3: Send TKEY Query-Response to Client.......................11
4.2: Context Established..........................................12
4.2.1: Terminating a Context....................................12
5: Sending and Verifying Signed Messages............................12
5.1: Sending a Signed Message - Call GSS_GetMIC...................12
5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............13
6: Example usage of GSS-TSIG algorithm..............................14
7: Security Considerations..........................................18
8: IANA Considerations..............................................18
9: Conformance......................................................18
10:Acknowledgements.................................................18
11:References.......................................................19
4.2.1: Terminating a Context....................................13
5: Sending and Verifying Signed Messages............................13
5.1: Sending a Signed Message - Call GSS_GetMIC...................13
5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............14
6: Example usage of GSS-TSIG algorithm..............................15
7: Security Considerations..........................................19
8: IANA Considerations..............................................19
9: Conformance......................................................19
10:Acknowledgements.................................................20
11:References.......................................................20
1. Introduction
@@ -111,9 +112,9 @@ over time. For example, a client and server may use Kerberos [RFC1964]
for one transaction, whereas that same server may use SPKM [RFC2025]
with a different client.
Expires May 22, 2001 [Page 2]
Expires September 1, 2001 [Page 2]
INTERNET-DRAFT GSS-TSIG November 22, 2000
INTERNET-DRAFT GSS-TSIG March 1, 2001
* The protocol developer is removed from the responsibility of
creating and managing a security infrastructure. For example, the
@@ -169,9 +170,9 @@ states of a context associated with a connection:
| |
+----------+
Expires May 22, 2001 [Page 3]
Expires September 1, 2001 [Page 3]
INTERNET-DRAFT GSS-TSIG November 22, 2000
INTERNET-DRAFT GSS-TSIG March 1, 2001
Every connection begins in the uninitialized state.
@@ -227,9 +228,9 @@ tokens between client and server. The TKEY record is a general
mechanism for establishing secret keys for use with TSIG. For more
information, see [RFC2930].
Expires May 22, 2001 [Page 4]
Expires September 1, 2001 [Page 4]
INTERNET-DRAFT GSS-TSIG November 22, 2000
INTERNET-DRAFT GSS-TSIG March 1, 2001
3.1.1 Call GSS_Init_sec_context
@@ -285,9 +286,9 @@ indicated with the output values below. Consult Sections 2.2.1
Expires May 22, 2001 [Page 5]
Expires September 1, 2001 [Page 5]
INTERNET-DRAFT GSS-TSIG November 22, 2000
INTERNET-DRAFT GSS-TSIG March 1, 2001
The client MUST abandon the algorithm if returned major_status is set to
@@ -312,9 +313,9 @@ GSS_S_COMPLETE. The exact success code is important during later
processing.
The values of replay_det_state and mutual_state indicate if the
security package provides replay detection and mutual
authentication, respectively. If one or both of these values
are FALSE, the client MUST abandon this algorithm.
security package provides replay detection and mutual authentication,
respectively. If returned major_status is GSS_S_COMPLETE AND one or both
of these values are FALSE, the client MUST abandon this algorithm.
Client's behavior MAY depend on other OUTPUT parameters according
to the policy local to the client.
@@ -335,17 +336,17 @@ owner name of the TKEY resource record set queried for and the owner
name of the supplied TKEY resource record in the additional records
section MUST be the same. This name uniquely identifies the security
context to both the client and server, and thus the client SHOULD use
a value which is globally unique as described in [RFC2930].
a value which is globally unique as described in [RFC2930]. To achieve
global uniqueness, the name MAY contain a UUID/GUID [ISO11578].
Expires September 1, 2001 [Page 6]
Expires May 22, 2001 [Page 6]
INTERNET-DRAFT GSS-TSIG November 22, 2000
INTERNET-DRAFT GSS-TSIG March 1, 2001
TKEY Record
@@ -401,9 +402,9 @@ is specified by the policy local to the client.
Expires May 22, 2001 [Page 7]
Expires September 1, 2001 [Page 7]
INTERNET-DRAFT GSS-TSIG November 22, 2000
INTERNET-DRAFT GSS-TSIG March 1, 2001
If the signature is verified the context state is advanced to Context
@@ -415,12 +416,21 @@ Established. Proceed to section 3.2 for usage of the security context.
If the last call to GSS_Init_sec_context yielded a major_status value
of GSS_S_CONTINUE, then the negotiation is not yet complete. The server
will return to the client a query-response with a TKEY record in the
Answer section. Since the message is not signed, the client MUST
disregard the error code of the DNS message and the TKEY record. The
client MUST pass a token specified in the Key Data field in the TKEY
resource record to GSS_Init_sec_context using the same parameters values
as in previous call except values for CONTEXT HANDLE
input_context_handle and OCTET STRING input_token as described below:
Answer section. If the DNS message error is not NO_ERROR or error field
in the TKEY record is not 0 (i.e. no error), then the client MUST
abandon this negotiation sequence. The client MUST delete an active
context by calling GSS_Delete_sec_context providing the associated
context_handle. The client MAY repeat the negotiation sequence starting
with the uninitialized state as described in section 3.1. To prevent
infinite looping the number of attempts to establish a security context
must be limited.
If the DNS message error is NO_ERROR and error filed in the TKEY record
is 0 (i.e. no error), then the client MUST pass a token specified in the
Key Data field in the TKEY resource record to GSS_Init_sec_context
using the same parameters values as in previous call except values for
CONTEXT HANDLE input_context_handle and OCTET STRING input_token as
described below:
INPUTS
CONTEXT HANDLE input_context_handle = context_handle (this is the
@@ -450,20 +460,22 @@ If OUTPUT major_status is set to one of the following values
GSS_S_BAD_MECH
GSS_S_FAILURE
then client MUST abandon this negotiation sequence. The client MAY
repeat the negotiation sequence starting with the uninitialized state as
described in section 3.1. To prevent infinite looping the number of
attempts to establish a security context must be limited.
Expires September 1, 2001 [Page 8]
INTERNET-DRAFT GSS-TSIG March 1, 2001
the client MUST abandon this negotiation sequence. The client MUST
delete an active context by calling GSS_Delete_sec_context providing
the associated context_handle. The client MAY repeat the negotiation
sequence starting with the uninitialized state as described in section
3.1. To prevent infinite looping the number of attempts to establish a
security context must be limited.
If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then
client MUST act as described below.
Expires May 22, 2001 [Page 8]
INTERNET-DRAFT GSS-TSIG November 22, 2000
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
finished. The token output_token MUST be passed to the server in a TKEY
record by repeating the negotiation sequence beginning with section
@@ -490,6 +502,27 @@ The procedures for sending and receiving signed messages are described
in section 5, Sending and Verifying Signed Messages.
3.2.1 Terminating a Context
When the client is not intended to continue using the established
security context, the client SHOULD delete an active context by
calling GSS_Delete_sec_context providing the associated context_handle,
AND client SHOULD delete the established context on the DNS server
by using TKEY RR with the Mode field set to 5, i.e. "key deletion"
[RFC2930].
Expires September 1, 2001 [Page 9]
INTERNET-DRAFT GSS-TSIG March 1, 2001
4. Server Protocol Details
As on the client-side, the result of a successful context negotiation
@@ -503,24 +536,13 @@ request. The server maintains a mapping of key names to handles:
(key_name, context_handle)
4.1 Negotiating Context
A server MUST recognize TKEY queries as security context negotiation
messages.
Expires May 22, 2001 [Page 9]
INTERNET-DRAFT GSS-TSIG November 22, 2000
4.1.1 Receive TKEY Query from Client
Upon receiving a query with QTYPE = TKEY, the server MUST examine
@@ -528,10 +550,14 @@ whether the Mode and Algorithm Name fields of the TKEY record in the
additional records section of the message contain values of 3 and
gss-tsig, respectively. If they do, then the (key_name, context_handle)
mapping table is searched for the key_name matching the owner name of
the TKEY record in the additional records section of the query. If the
name is found in the table, the corresponding context_handle is used in
subsequent GSS operations. If the name is not found, then the server
interprets this as a start of new security context negotiation.
the TKEY record in the additional records section of the query. If the
name is found in the table and the security context for this name is
established and not expired, then the server MUST respond to the query
with BADNAME error in the TKEY error field. If the name is found in the
table and the security context is not established, the corresponding
context_handle is used in subsequent GSS operations. If the name is not
found, then the server interprets this query as a start of new security
context negotiation.
4.1.2 Call GSS_Accept_sec_context
@@ -550,6 +576,12 @@ for syntax definitions.
field from TKEY RR (from Additional records Section of
the client's query)
Expires September 1, 2001 [Page 10]
INTERNET-DRAFT GSS-TSIG March 1, 2001
CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
default"). Server MAY instead specify some other valid handle
to its credentials.
@@ -575,11 +607,6 @@ for syntax definitions.
INTEGER lifetime_rec
CONTEXT_HANDLE delegated_cred_handle
Expires May 22, 2001 [Page 10]
INTERNET-DRAFT GSS-TSIG November 22, 2000
If this is the first call to GSS_Accept_sec_context in a new
negotiation, then output_context_handle is stored in the server's
key-mapping table as the context_handle that maps to the name of the
@@ -606,6 +633,13 @@ in the TKEY record set to BADKEY.
GSS_S_BAD_MECH
GSS_S_FAILURE
Expires September 1, 2001 [Page 11]
INTERNET-DRAFT GSS-TSIG March 1, 2001
If OUTPUT major_status is set to GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED then server MUST act as described below.
@@ -629,15 +663,6 @@ error field in the TKEY record is set to NOERROR. The server MUST limit
the number of times that a given context is allowed to repeat, to
prevent endless looping. Such limit SHOULD NOT exceed value of 10.
Expires May 22, 2001 [Page 11]
INTERNET-DRAFT GSS-TSIG November 22, 2000
In all cases except if major_status is GSS_S_COMPLETE and output_token
is NULL other TKEY record fields MUST contain the following values:
NAME = key_name
@@ -658,15 +683,25 @@ The handle is valid for a finite amount of time determined by the
underlying security mechanism. A server MAY unilaterally terminate
a context at any time (see section 4.2.1).
Server SHOULD limit the amount of memory used to cache established
contexts.
The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages.
Expires September 1, 2001 [Page 12]
INTERNET-DRAFT GSS-TSIG March 1, 2001
4.2.1 Terminating a Context
A server can terminate any established context at any time. The
server MAY hint to the client that the context is being deleted
by including a TKEY RR in a response with the Mode field set to 5, i.e.
server MAY hint to the client that the context is being deleted by
including a TKEY RR in a response with the Mode field set to 5, i.e.
"key deletion" [RFC2930].
An active context is deleted by calling GSS_Delete_sec_context
providing the associated context_handle.
@@ -690,12 +725,6 @@ TSIG variable values:
Assign the remaining fields in the TSIG RDATA appropriate values
as described in [RFC2845].
Expires May 22, 2001 [Page 12]
INTERNET-DRAFT GSS-TSIG November 22, 2000
The signature is generated by calling GSS_GetMIC. The following input
parameters MUST be used. The outcome of the call is indicated with the
output values specified below. Consult Sections 2.3.1 "GSS_GetMIC
@@ -719,6 +748,13 @@ If major_status is GSS_S_COMPLETE, then signature generation
succeeded. The signature in per_msg_token is inserted into the
Signature field of the TSIG RR and the message is transmitted.
Expires September 1, 2001 [Page 13]
INTERNET-DRAFT GSS-TSIG March 1, 2001
If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED or
GSS_S_FAILURE the caller MUST delete the security context, return to the
uninitialized state and SHOULD negotiate a new security context, as
@@ -744,16 +780,6 @@ does not map to an established context, the server MUST send a
standard TSIG error response to the client indicating BADKEY in the
TSIG error field (as described in [RFC2845]).
Expires May 22, 2001 [Page 13]
INTERNET-DRAFT GSS-TSIG November 22, 2000
For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
INPUTS
@@ -773,11 +799,20 @@ TSIG record MUST also be valid before considering the message to be
authentic. The caller MUST not act on the request or response in the
message until these checks are verified.
If major_status is set to one of the following values, the negotiated
context is no longer valid.
When a server is processing a client request,
the server MUST send a standard TSIG error response to the client
indicating BADKEY in the TSIG error field as described in [RFC2845],
if major_status is set to one of the following values
GSS_S_DEFECTIVE_TOKEN
GSS_S_BAD_SIG (GSS_S_BAD_MIC)
GSS_S_DUPLICATE_TOKEN
Expires September 1, 2001 [Page 14]
INTERNET-DRAFT GSS-TSIG March 1, 2001
GSS_S_OLD_TOKEN
GSS_S_UNSEQ_TOKEN
GSS_S_GAP_TOKEN
@@ -785,9 +820,6 @@ context is no longer valid.
GSS_S_NO_CONTEXT
GSS_S_FAILURE
If this failure occurs when a server is processing a client request,
the server MUST send a standard TSIG error response to the client
indicating BADKEY in the TSIG error field as described in [RFC2845].
If the timer values of the TSIG record are invalid, the message MUST
NOT be considered authentic. If this error checking fails when a server
@@ -802,15 +834,6 @@ and a Server, server.example.com, establish a security context according
to the algorithm described above.
Expires May 22, 2001 [Page 14]
INTERNET-DRAFT GSS-TSIG November 22, 2000
I. Client initializes security context negotiation
To establish a security context with a server, server.example.com, the
Client calls GSS_Init_sec_context with the following parameters
@@ -841,6 +864,13 @@ INTERNET-DRAFT GSS-TSIG November 22, 2000
Query contains a TKEY record in its Additional records section with
the following fields (Note that some fields not specific to this
algorithm are not specified)
Expires September 1, 2001 [Page 15]
INTERNET-DRAFT GSS-TSIG March 1, 2001
NAME = 789.client.example.com.server.example.com.
RDATA
Algorithm Name = gss-tsig
@@ -861,14 +891,6 @@ INTERNET-DRAFT GSS-TSIG November 22, 2000
is not listed in its (key_name, context_handle) mapping table.
Expires May 22, 2001 [Page 15]
INTERNET-DRAFT GSS-TSIG November 22, 2000
IV. Server calls GSS_Accept_sec_context
To continue security context negotiation server calls
GSS_Accept_sec_context with the following parameters (Note that some
@@ -897,6 +919,16 @@ INTERNET-DRAFT GSS-TSIG November 22, 2000
0. The RCODE in the query response is set to NOERROR.
Expires September 1, 2001 [Page 16]
INTERNET-DRAFT GSS-TSIG March 1, 2001
VI. Client processes token returned by server
When the client receives the TKEY query response from the server, the
client calls GSS_Init_sec_context with the following parameters (Note
@@ -923,10 +955,6 @@ INTERNET-DRAFT GSS-TSIG November 22, 2000
security context is established, but since the output_token is not
NULL client MUST send a TKEY query to the server as described below.
Expires May 22, 2001 [Page 16]
INTERNET-DRAFT GSS-TSIG November 22, 2000
VII. Client sends a query with QTYPE = TKEY to server
Client sends to the server a TKEY query for the
@@ -950,6 +978,16 @@ INTERNET-DRAFT GSS-TSIG November 22, 2000
listed in its (key_name, context_handle) mapping table.
Expires September 1, 2001 [Page 17]
INTERNET-DRAFT GSS-TSIG March 1, 2001
IX. Server calls GSS_Accept_sec_context
To continue security context negotiation server calls
GSS_Accept_sec_context with the following parameters (Note that some
@@ -974,18 +1012,6 @@ INTERNET-DRAFT GSS-TSIG November 22, 2000
state is advanced to Context Established.
Expires May 22, 2001 [Page 17]
INTERNET-DRAFT GSS-TSIG November 22, 2000
X. Server responds to the TKEY query
Since the major_status = GSS_S_COMPLETE in the last server's call to
GSS_Accept_sec_context and the output_token is NULL, the server
@@ -1009,6 +1035,16 @@ INTERNET-DRAFT GSS-TSIG November 22, 2000
Signature field in the TSIG record is set to per_msg_token.
Expires September 1, 2001 [Page 18]
INTERNET-DRAFT GSS-TSIG March 1, 2001
XI. Client processes token returned by server
Client receives the TKEY query response from the server. Since the
major_status was GSS_S_COMPLETE in the last client's call to
@@ -1039,11 +1075,6 @@ The security provided by this protocol is only as effective as the
security provided by the underlying GSS mechanisms.
Expires May 22, 2001 [Page 18]
INTERNET-DRAFT GSS-TSIG November 22, 2000
8. IANA Considerations
The authors request that the IANA reserve the TSIG Algorithm name
@@ -1063,6 +1094,15 @@ support such flexibility, DNS clients and servers SHOULD specify SPNEGO
mech_type in their GSS API calls. At the same time, in order to
guarantee interoperability between DNS clients and servers that support
GSS-TSIG it is required that
Expires September 1, 2001 [Page 19]
INTERNET-DRAFT GSS-TSIG March 1, 2001
- DNS servers specify SPNEGO mech_type
- GSS APIs called by DNS client support Kerberos v5
- GSS APIs called by DNS server support SPNEGO [RFC2478] and
@@ -1095,14 +1135,6 @@ Ram Viswanathan, Olafur Gudmundsson and Donald E. Eastlake 3rd.
[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
RFC 2535, IBM, March 1999.
Expires May 22, 2001 [Page 19]
INTERNET-DRAFT GSS-TSIG November 22, 2000
[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
RFC 2137, CyberCash, April 1997.
@@ -1124,6 +1156,16 @@ INTERNET-DRAFT GSS-TSIG November 22, 2000
[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, Bull, December 1998.
Expires September 1, 2001 [Page 20]
INTERNET-DRAFT GSS-TSIG March 1, 2001
[ISO11578]"Information technology", "Open Systems
Interconnection", "Remote Procedure Call",
ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html.
12. Author's Addresses
@@ -1143,16 +1185,13 @@ USA USA
levone@microsoft.com
Randy Hall
Lucent Technologies
400 Lapp Road
Malvern PA 19355
USA
randyhall@lucent.com
Expires May 22, 2001 [Page 20]
Expires September 1, 2001 [Page 21]

159
doc/draft/draft-ietf-idn-jpchar-00.txt
View File

@@ -1,159 +0,0 @@
Internet Draft Yoshiro Yoneya
draft-ietf-idn-jpchar-00.txt Yasuhiro Morishita
November 17, 2000 JPNIC
Expires May 17, 2001
Japanese characters in multilingual domain name label
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
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 Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document explains about Japanese characters and its canonicalization
rules in multilingual domain name labels. This document is based on
discussions and examinations in JPNIC.
Despite of IDN WG rough consensus that character set in multilingual
domain name is UCS [UCS], most popular Japanese character set used in
Japan is Japanese Industrial Standards X 0208 -- hereafter abbreviated
as "JIS" -- [JISX0208]. This means that many of PCs and most of PDAs
including handy phones in Japan can display only JIS and ASCII.
Therefore, Japanese characters used in multilingual domain name are
strongly recommended as common part of JIS, ASCII and UCS.
Furthermore, for historical reasons, JIS have many compatible code
points in Kana and Alpha-numericals. Such compatible code points are
still used widely, so that these characters SHOULD be acceptable
especially in user interface, and MUST be canonicalized before
transmission to the wire. The former half should be implemented for
localization, and the latter half must be implemented for
internationalization.
1. Japanese characters in multilingual domain name labels
In principle domain name is a symbolic name of resources on the
Internet for understanding and memorizing easily to the Internet
users. Internationalization or multilingualization of domain name
MUST obey this principle. That is, characters in multilingualized
domain name labels SHOULD be unambiguous.
JIS has a lot of characters including graphical and compatible
characters. But as for domain name, significant characters to
represent names are Kanji, Hiragana and Katakana [CJK]. Therefore,
according to the principle, Japanese characters in multilingual domain
name MUST be Kanji, Hiragana and Katakana in JIS.
The file "idntabjp10.txt" defines Japanese characters in the format of
[VERSION], with additional corresponding JIS code points as 3rd field,
that can be used in multilingual domain name labels. Some of them,
such as PROLONGED SOUND MARK (U+30FC), are categorized into graphical
character in JIS, but usage of them are part of Kanji, Hiragana or
Katakana. These characters are in canonicalized form.
2. Canonicalization rules of Japanese characters in multilingual
domain name labels
In this section, this document describes two parts of canonicalization
rules. One explains "localization", and the other comments on
"internationalization". In other words, one is for Input/Display
level, and another is for API level [IDNA].
2.1 Localization: Characters to be canonicalized before NAMEPREP
As mentioned above, JIS has a lot of compatible characters that are
regarded alpha-numeric or Katakana. The former is so called
FULL-WIDTH Alpha-numeric, and the latter is so called HALF-WIDTH kana.
These characters are prohibited in [NAMEPREP], but still widely used
in many PCs and most PDAs in Japan. Hence, application softwares that
treat Japanese characters in multilingual domain name label SHOULD
accept these compatible characters as input and canonicalize them
before [NAMEPREP].
The file "idntabjpcanon10.txt" defines compatible characters, with
additional canonicalized character code as 3rd field; that is, mapping
table of FULL-WIDTH Alpha-numeric to ASCII, and HALF-WIDTH kana to
Katakana.
The file "idntabjpcomp10.txt" defines compatible character sequences
as composed, with additional canonicalized characters code as 3rd
field; that is, composition table of Kana and voiced sound mark.
Recommended order of applying canonicalization rules is as follows:
(1) "idntabjpcanon10"
(2) "idntabjpcom10"
This part is a local part of canonicalization.
2.2 Internationalization: Characters to be canonicalized in NAMEPREP
Japanese characters in multilingual domain name labels MUST be
characters defined in "idntabjp10". Another characters except for
"idntabjp10" SHOULD be canonicalized at [NAMEPREP].
[NAMEPREP] is common and recommended rule for IDN.
This part is an international part of canonicalization.
3. Security considerations
None in particular.
4. References
[UCS] "Universal Multiple-Octet Coded Character Set",
ISO/IEC 10646-1:1993, ISBN 0-201-61633-5
[JISX0208] "Japanese Industrial Standards",
Information Technology (Terms/Code/Date elements)-99,
ISBN4-542-12976-4
[IDNREQ] "Requirements of Internationalized Domain Names",
draft-ietf-idn-requirements-03.txt, Jun 2000, Z Wenzel, J Seng
[NAMEPREP] "Preparation of Internationalized Host Names",
draft-ietf-idn-nameprep-00.txt, Jul 2000, P Hoffman, M Blanchet
[CJK] "Han Ideograph (CJK) for Internationalized Domain Names",
draft-ietf-idn-cjk-00.txt, Sep 2000, J Seng, Y Yoneya,
K Huang, K Kyongsok
[VERSION] "Handling versions of internationalized domain names protocols",
draft-ietf-idn-version-00.txt, Nov 2000, M Blanchet
5. Acknowledgements
JPNIC IDN-TF members.
6. Author's Address
Yoshiro Yoneya
Japan Network Information Center
Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
Chiyoda-ku Tokyo 101-0052, Japan
yone@nic.ad.jp
Yasuhiro Morishita
Japan Network Information Center
Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
Chiyoda-ku Tokyo 101-0052, Japan
yasuhiro@nic.ad.jp

6735
doc/draft/draft-ietf-idn-jpchar-01.txt Normal file
View File

File diff suppressed because it is too large Load Diff

219
doc/draft/draft-ietf-idn-nameprep-02.txt → doc/draft/draft-ietf-idn-nameprep-03.txt
View File

@@ -1,6 +1,6 @@
Internet Draft Paul Hoffman
draft-ietf-idn-nameprep-02.txt IMC & VPNC
January 17, 2001 Marc Blanchet
draft-ietf-idn-nameprep-03.txt IMC & VPNC
February 24, 2001 Marc Blanchet
Expires in six months ViaGenie
Preparation of Internationalized Host Names
@@ -26,20 +26,21 @@ http://www.ietf.org/shadow.html.
Abstract
This document describes how to prepare internationalized host names for
for use in the DNS. The steps include:
- mapping characters to other characters, such as to change their case
- normalizing the characters
- excluding characters that are prohibited from appearing in
internationalized host names
use in the DNS. The steps include:
- mapping characters to other characters, such as to change their case
- normalizing the characters
- excluding characters that are prohibited from appearing in
internationalized host names
This document does not specify a wire protocol. This preparation should
be done before the DNS request.
1. Introduction
When expanding today's DNS to include internationalized host names,
those new names will be handled in many parts of the DNS. The IDN
Working Group's requirements document [IDNReq] describes a framework for
domain name handling as well as requirements for the new names. The IDN
Working Group's comparison document [IDNComp] gives a framework for how
various parts of the IDN solution work together.
those new names will be handled in many parts of the DNS. The
Internationalized Domain Name (IDN) Working Group's requirements
document [IDNReq] describes a framework for domain name handling as well
as requirements for the new names.
A user can enter a domain name into an application program in a myriad
of fashions. Depending on the input method, the characters entered in
@@ -49,19 +50,27 @@ the user's input before the name is resolved in the DNS.
It is a design goal of this document to allow users to enter host names
in applications and have the highest chance of getting the name correct.
This means that the user should not be limited to only entering exactly
the characters that might have been used, but to instead be able to
enter characters that unambiguously normalize to characters in the
desired host name. At the same time, this process must not introduce any
chance that two host names could be represented by two distinct strings
of characters that look identical to typical users. It is also a design
goal to have all preprocessing of IDN done before going on the wire, so
that no transformation is done in the DNS server space. Name preparation
can be done in other places, such as in the registration process.
Another, often conflicting, design goal is to allow as wide of a range
of characters as possible to be allowed in host names. The user should
not be limited to only entering exactly the characters that might have
been used, but to instead be able to enter characters that unambiguously
normalize to characters in the desired host name. Although it would be
easy to use the process in this step to "correct" perceived mis-features
or bugs in the current character standards, this document expressly does
not do so.
This document describes the steps needed to convert a name part from one
that is entered by the user to one that can be used in the DNS.
Within a fully-qualified domain name, some labels may be
internationalized, while others are not. This specification should be
applied to all internationalized labels. An application must be able to
recognize which part is internationalized; the method for such
recognition is outside of the scope of this document. Note that this
specification is harmless to the non-internationalized labels: when the
steps described here are applied to non-internationalized labels, the
label will not change.
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
@@ -69,15 +78,15 @@ The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
[RFC2119].
Examples in this document use the notation for code points and names
from the Unicode Standard [Unicode3] and ISO 10646 [ISO10646]. For
from the Unicode Standard [Unicode3] and ISO/IEC 10646 [ISO10646]. For
example, the letter "a" may be represented as either "U+0061" or "LATIN
SMALL LETTER A". In the lists of prohibited characters, the "U+" is left
off to make the lists easier to read. The names of character ranges are
shown in square brackets (such as "[SYMBOLS]") and do not come from the
standards.
Note: A glossary of terms used in Unicode and ISO 10646 can be found in
[Glossary]. Information on the 10646/Unicode character model can be
Note: A glossary of terms used in Unicode and ISO/IEC 10646 can be found
in [Glossary]. Information on the 10646/Unicode character model can be
found in [CharModel].
@@ -90,10 +99,11 @@ many ways and is not specified in this document
2) Map -- For each character in the input, check if it has a mapping
and, if so, replace it with its mapping. The mappings are a combination
of folding uppercase characters to lowercase and hyphen mapping. This
is described in Section 4.
of folding uppercase characters to lowercase and hyphen mapping. This is
described in Section 4.
3) Normalize -- Normalize the characters. This is described in Section 5.
3) Normalize -- Normalize the characters. This is described in Section
5.
4) Look for prohibited output -- Check for any characters that are not
allowed in the output. If any are found, return an error to the
@@ -125,9 +135,10 @@ table includes all the steps described in the subsections below.
The mappings can be one-to-none, one-to-one, or one-to-many. That is,
some characters may be eliminated or replaced by more than one
character, and the output of this step might be shorter or longer than
the input.
the input. Because of this, an application MUST be prepared to receive a
longer or shorter string than the one input in the nameprep algorithm.
Design note: Characters that are not wanted in internationalized name
Rationale: Characters that are not wanted in internationalized name
parts can either be mapped to nothing in the mapping step, or cause an
error in the prohibition step. The general guideline used to pick
between the two outcomes was that removing alphabetic, non-protocol
@@ -139,11 +150,13 @@ characters from the user.
3.1 Case mapping
For each character in the input, if there is a lowercase mapping for
that character, the input character is changed to the mapped lowercase
character(s). The entries in the mapping table are derived from [UTR21].
The input string is case folded according to [UTR21]. For most
characters, this is the same thing as changing the input character to a
lowercase character. For some characters, however, more complex
transformations occur. The mapping table in Appendix E is derived by
applying the rules for equivalence classes from [UTR21].
Design note: this step could have been "change all lowercase characters
Rationale: This step could have been "change all lowercase characters
into uppercase characters". However, the upper-to-lower folding was
chosen because most users of the Internet today enter host names in
lowercase.
@@ -155,12 +168,12 @@ need processing. These characters include a few Greek characters and
many symbols that contain Latin characters. The list of characters to
add to the mapping table were determined by the following algorithm:
b = Normalize(Fold(a));
c = Normalize(Fold(b));
b = NormalizeWithKC(Fold(a));
c = NormalizeWithKC(Fold(b));
if c is not the same as b, add a mapping for "a to c".
Because Normalize(Fold(c)) always equals c, the table is stable from
that point on.
Because NormalizeWithKC(Fold(c)) always equals c, the table is stable
from that point on.
3.3 Mapped out
@@ -191,12 +204,12 @@ do not bear semantics.
The output of the mapping step is normalized using form KC, as described
in [UTR15]. Using form KC instead of form C causes many characters that
are identical or near-identical to be converted into a single character.
Note that this specification refers to a specific vesion of [UTR15].
If a later version of [UTR15] changes the algorithm used for normalizing,
Note that this specification refers to a specific version of [UTR15]. If
a later version of [UTR15] changes the algorithm used for normalizing,
that later version MUST NOT be used with this specification. Note that
it is likely that this specification will be revised if UTR15 is changed,
but until that happens, only the specified version of [UTR15] must
be used.
it is likely that this specification will be revised if UTR15 is
changed, but until that happens, only the specified version of [UTR15]
must be used.
5. Prohibited Output
@@ -213,11 +226,6 @@ personal names, company names, and spoken phrases. A goal of this
section is to prohibit as few characters that might be used in these
contexts as possible.
Note that every code point listed in this section MUST NOT be transmitted
on the DNS service interface. If a DNS server receives a request
containing a prohibited code point, then the DNS server MUST NOT resolve
that name.
The collected list of prohibited code points can be found in Appendix F
of this document. The list in Appendix F MUST be used by implementations
of this specification. If there are any discrepancies between the list
@@ -231,7 +239,7 @@ F.
5.1 Currently-prohibited ASCII characters
Some of the ASCII characters that are currently prohibited in host names
by [STD13] are also used in protocol elements such as URIs. The other
by [STD13] are also used in protocol elements such as URIs [URI]. The other
characters in the range U+0000 to U+007F that are not currently allowed
are also prohibited in host name parts to reserve them for future use in
protocol elements.
@@ -274,7 +282,7 @@ when displayed.
007F; DELETE
0080-009F; [CONTROL CHARACTERS]
2028; LINE SEPARATOR
2029; PARAGRAPH SEPARATORS
2029; PARAGRAPH SEPARATOR
5.4 Private use and replacement characters
@@ -286,17 +294,17 @@ F0000-FFFFD; [PRIVATE USE, PLANE 15]
100000-10FFFD; [PRIVATE USE, PLANE 16]
The replacement character (U+FFFD) has no known semantic definition in a
name, and is often used in renderers to say "there would be some
name, and is often displayed by renderers to indicate "there would be some
character here, but it cannot be rendered". For example, on a computer
with no Asian fonts, a name with three katakana characters might be
rendered with three replacement characters.
FFFD; REPLACEMENT CHARACTER
5.5 Non-character codepoints
5.5 Non-character code points
Non-character code points are code points that have been assigned in
ISO 10646 but are not characters. Because they are already assigned,
ISO/IEC 10646 but are not characters. Because they are already assigned,
they are guaranteed not to later change into characters.
FFFE-FFFF; [NONCHARACTER CODE POINTS]
@@ -344,7 +352,7 @@ for host names that must have a single canonical order.
5.9 Change display properties
The following characters, some of which are deprecated in ISO 10646,
The following characters, some of which are deprecated in ISO/IEC 10646,
can cause changes in display or the order in which characters appear
when rendered.
@@ -362,10 +370,20 @@ when rendered.
206E; NATIONAL DIGIT SHAPES
206F; NOMINAL DIGIT SHAPES
5.10 Inappropriate characters from common input mechanisms
U+3002 is used as if it were U+002E in many input mechanisms,
particularly in Asia. This prohibition allows input mechanisms to safely
map U+3002 to U+002E before doing nameprep without worrying about
preventing users from accessing legitimate host name parts.
3002; IDEOGRAPHIC FULL STOP
6. Unassigned Code Points
All code points not yet assigned in ISO 10646 are called "unassigned
All code points not assigned in ISO/IEC 10646 are called "unassigned
code points". Authoritative name servers MUST NOT have internationalized
name parts that contain any unassigned code points. DNS requests MAY
contain name parts that contain unassigned code points. Note that this
@@ -373,19 +391,19 @@ is the only part of this document where the requirements for queries
differs from the requirements for names in DNS zones.
Using two different policies for where unassigned code points can appear
in the DNS prevents the need for versioning the IDNprotocol [IDNrev].
in the DNS prevents the need for versioning the IDN protocol [IDNrev].
This is very useful since it makes the overall processing simpler and do
not impose a "protocol" to handle versioning. It is expected that ISO
not impose a "protocol" to handle versioning. It is expected that ISO/IEC
10646 will be updated fairly frequently; recently, it has happened
approximately once a year. Each time a new version of ISO 10646 appears,
approximately once a year. Each time a new version of ISO/IEC 10646 appears,
a new version of this document can be created. Some end users will want
to use the new code points as soon as they are defined.
The list of unassigned code points can be found in Appendix G of this
document. The list in Appendix G MUST be used by implementations of this
specification. If there are any discrepancies between the list in
Appendix G and the ISO 10646 specification, the list Appendix G always
takes precedence.
Appendix G and the ISO/IEC 10646 specification, the list Appendix G
always takes precedence.
Due to the way that versioning is handled in this section, host names
that are embedded in structures that cannot be changed (such as the
@@ -394,7 +412,7 @@ name parts that contain any unassigned code points.
6.1 Categories of code points
Each code point in ISO 10646 can be categorized by how it acts in the
Each code point in ISO/IEC 10646 can be categorized by how it acts in the
process described in earlier sections of this document:
AO Code points that may be in the output
@@ -409,7 +427,7 @@ D Code points that cannot be in the output because they are
U Unassigned code points
A subsequent version of this document that references a newer version of
ISO 10646 with new code points will inherently have some code points
ISO/IEC 10646 with new code points will inherently have some code points
move from category U to either D, MN, or AO. For backwards
compatibility, no future version of this document will move code points
from any other category. That is, no current AO, MN, or D code points
@@ -539,11 +557,8 @@ specification.
[Glossary] Unicode Glossary, <http://www.unicode.org/glossary/>.
[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name
Proposals", draft-ietf-idn-compare
[IDNReq] James Seng, "Requirements of Internationalized Domain Names",
draft-ietf-idn-requirement
[IDNReq] Zita Wenzel and James Seng, "Requirements of Internationalized
Domain Names", draft-ietf-idn-requirements
[IDNRev] Marc Blanchet, "Handling versions of internationalized domain
names protocols", draft-ietf-idn-version
@@ -564,13 +579,18 @@ Generic Syntax", August 1998, RFC 2396.
[RFC2732] Robert Hinden, et. al., Format for Literal IPv6 Addresses in
URL's, December 1999, RFC 2732.
[STD13] Paul Mockapetris, "Domain names - implementation and
specification", November 1987, STD 13 (RFC 1034 and 1035).
[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
1034) and "Domain names - implementation and specification" (RFC 1035,
STD 13, November 1987.
[Unicode3] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Described at
<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
[URIs] For example: Roy Fielding et. al., "Uniform Resource Identifiers:
Generic Syntax", August 1998, RFC 2396; Robert Hinden et. al, "IPv6
Literal Addresses in URL's", December 1999, RFC 2732.
[UTR15] Mark Davis and Martin Duerst. Unicode Normalization Forms.
Unicode Technical Report;15.
<http://www.unicode.org/unicode/reports/tr15/>.
@@ -605,37 +625,52 @@ Jonathan Rosenne
Kent Karlsson
Scott Hollenbeck
B. Differences Between -01 and -01 Drafts
Throughout: changed the format of lines with character names to make
the document easier to review.
B. Differences Between -02 and -03 Drafts
1.1: Added non-normative reference to [ISO10646]. Also added note about
range names.
Throughout: Changed "ISO 10646" to "ISO/IEC 10646". Changed "codepoint"
to "code point".
3.2: Changed "CaseFold" to "Fold" in last sentence.
Abstract: Added last sentence.
4: Corrected spelling in title.
1: Removed the sentence about [IDNComp] in the first paragraph.
Clarified the design goals in the third paragraph. Added new last
paragraph about processing name parts.
5: Changed "character" to "code point" in many places because some of
the things that are prohibited are not chraracters. Changed the last
sentence in the fifth paragraph.
3: Added sentence at the end of the second paragraph about accepting
shorter or longer responses. Changed "Design note" to "Rationale".
6: Changed "character" to "code point" in many places, including the
title of the section.
3.1: Revised the first paragraph to make it clearer that the mapping is
not simple lowercasing. Changed "Design note" to "Rationale".
A: Added Kent Karlsson and Scott Hollenbeck to the commenters list.
3.2: Made it clearer that the normalization is with form KC.
F: Corrected an error in the table (hyphen was called prohibited
when it obviously is not). Changed title.
5: Removed the previous third paragraph, which discussed the DNS service
interface.
G: Fixed the table to use the proper format for the code points.
Changed title.
5.1: Added references for URIs.
5.4: Changed the sentence about the replacement character to read
"...and is often displayed by renderers to indicate...".
5.10: Added this section, which prohibits U+3002.
6: Removed "yet" from the first sentence.
8: Fixed the reference for [IDNReq] and [STD13]. Removed the reference
to [IDNComp]. Added the reference for [URIs].
C: Changed wording of the section.
E, F, G: Added tags to the beginning and end of the tables.
F: Added 3002 (from section 5.10). Added FDD0-FDEF, which were omitted
in error.
C. IANA Considerations
[[[ We probably won't have any. ]]]
None.
D. Author Contact Information
@@ -664,6 +699,7 @@ The columns are separated by semicolons. Note that the second column may
be empty, or it may have one character, or it may have more than one
character, with each character separated by a space.
----- Start Mapping Table -----
0041; 0061; Case map
0042; 0062; Case map
0043; 0063; Case map
@@ -1541,10 +1577,12 @@ FF37; FF57; Case map
FF38; FF58; Case map
FF39; FF59; Case map
FF3A; FF5A; Case map
----- End Mapping Table -----
F. Prohibited Code Point List
----- Start Prohibited Table -----
0000-002C
002E-002F
003A-0040
@@ -1583,6 +1621,7 @@ F. Prohibited Code Point List
206F
2FF0-2FFF
3000
3002
D800-DFFF
E000-F8FF
FFF9
@@ -1609,6 +1648,7 @@ F0000-FFFFD
FFFFE-FFFFF
100000-10FFFD
10FFFE-10FFFF
----- End Prohibited Table -----
NOTE WELL: Software that follows this specification that will be used to
check names before they are put in authoritative name servers MUST add
@@ -1618,6 +1658,7 @@ See Section 6 for more details.
G. Unassigned Code Point List
----- Start Unassigned Table -----
0220-0221
0234-024F
02AE-02AF
@@ -1953,7 +1994,7 @@ FB45
FBB2-FBD2
FD40-FD4F
FD90-FD91
FDC8-FDCF
FDC8-FDEF
FDFC-FE1F
FE24-FE2F
FE45-FE48
@@ -1985,4 +2026,6 @@ A0000-AFFFD
B0000-BFFFD
C0000-CFFFD
D0000-DFFFD
E0000-EFFFD
E0000-EFFFD
----- End Unassigned Table -----

206
doc/draft/draft-kosters-dnsext-dnssec-opt-in-00.txt → doc/draft/draft-kosters-dnsext-dnssec-opt-in-01.txt
View File

@@ -2,11 +2,11 @@
Network Working Group M. Kosters
Internet-Draft Network Solutions, Inc.
Expires: May 18, 2001 November 17, 2000
Expires: August 31, 2001 March 2, 2001
DNSSEC Opt-in for Large Zones
draft-kosters-dnsext-dnssec-opt-in-00.txt
draft-kosters-dnsext-dnssec-opt-in-01.txt
Status of this Memo
@@ -29,11 +29,11 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 18, 2001.
This Internet-Draft will expire on August 31, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
@@ -52,9 +52,9 @@ Abstract
Kosters Expires May 18, 2001 [Page 1]
Kosters Expires August 31, 2001 [Page 1]
Internet-Draft DNSSEC Opt In November 2000
Internet-Draft DNSSEC Opt In March 2001
Table of Contents
@@ -62,12 +62,12 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9
@@ -108,9 +108,9 @@ Table of Contents
Kosters Expires May 18, 2001 [Page 2]
Kosters Expires August 31, 2001 [Page 2]
Internet-Draft DNSSEC Opt In November 2000
Internet-Draft DNSSEC Opt In March 2001
1. Introduction
@@ -119,11 +119,12 @@ Internet-Draft DNSSEC Opt In November 2000
can also be its chief weaknesses. One feature is the facility to
delegate branches of information from one set of servers to another.
Currently, this is done in a non-cryptographically verified way that
allows spoofing attacks. For example, Eugene Kashpureff exploited
this vulnerability to redirect www.netsol.com and www.internic.net
to his own website. If this delegated information had been
cryptographically verified, this attack would not have been able to
occur.
allows spoofing attacks. For example, an alternative domain registry
called AlterNIC exploited this vulnerability to redirect
www.netsol.com and www.internic.net websites to their own website in
July 1997 that gained widespread exposure. If this delegated
information had been cryptographically verified, this attack would
not have been able to occur.
In recent years, there has been much work within the IETF regarding
DNS security. There are a number of RFCs that integrate public key
@@ -148,24 +149,27 @@ Internet-Draft DNSSEC Opt In November 2000
KEY RR
At a delegation point, the zone maintainer needs to place a NULL
key and accompanying SIG RR's when the child zone is not known to
be secure.
be secure.
NXT RR
Each delegation needs to be lexigraphically ordered so that a NXT
RR can be generated and signed with SIG RR's. For large zone
operators, generating the zone file is a very time consuming
process. In the resolution process, NXT lookups require that the
server replace efficient hash structures with a lexigraphically
ordered search structure which degrades lookup performance. This
ordered search structure that degrades lookup performance. This
lookup performance is a critical element for a high-query rate
DNS server.
Thus, the net effect is when one initially secures a zone as defined
in RFC2535[4], the net overhead is massive because of the following
factors:
Kosters Expires May 18, 2001 [Page 3]
Kosters Expires August 31, 2001 [Page 3]
Internet-Draft DNSSEC Opt In March 2001
factors:
1. Zone ordering and maintenance for large zones is difficult and
expensive.
@@ -207,38 +211,78 @@ Kosters Expires May 18, 2001 [Page 3]
with the added benefit of no longer having to maintain NULL KEY RRs
for unsecure delegations.
On the server side, identification of the zone being opt-in will be
identified by using one of the reserved bits of the flags section
within the KEY RR for that particular zone [note - the actual bit
needs yet to be selected out of reserved bits 4-5 or 8-11].
On the client side, the client MUST be identified by sending a
option-code of RETRY-NO-SEC-AWARE within the OPT RR RDATA to ensure
Kosters Expires August 31, 2001 [Page 4]
Internet-Draft DNSSEC Opt In March 2001
that it can accept and understand the RETRY-NO-SEC RCODE. The
RETRY-NO-SEC-AWARE option-code MUST have an option-length value of
zero with no option-data. The RETRY-NO-SEC-AWARE option-code will be
determined by IANA.
To determine which view each DNS query packet is to be queried
against, there is a simple algorithm to be followed:
1. The DNSSEC view is to be queried when the DO bit is set within
the EDNS0 OPT meta RR as indicated in [6].
the EDNS0 OPT meta RR as indicated in [6] Additionally,
2. The DNSSEC view is to be queried when the query type is SIG,
KEY, or NXT and the RRs added match the query name and query
type.
If the query does not follow either case (1) or (2), the non-DNSSEC
view MUST be consulted by default.
Kosters Expires May 18, 2001 [Page 4]
Internet-Draft DNSSEC Opt In November 2000
Since the DNSSEC view will have a subset of the actual delegations
of that zone, it will not be able to respond to an unsecured
delgation. To that end, a new extended RCODE MUST be set within the
EDNS OPT RR for the resolver to retry again with the DO bit not set.
This RCODE is referred to as "RETRY-NO-SEC" (RS). In the context of
the EDNS0 OPT meta-RR, the RS value will be determined by IANA.
delegation. To that end, one of two things will happen:
1) If the client has been identified as RETRY-NO-SEC-AWARE, a new
extended RCODE MUST be set within the EDNS OPT RR for the resolver
to retry again with the DO bit not set. This RCODE is referred to
as "RETRY-NO-SEC" (RS). In the context of the EDNS0 OPT meta-RR,
the RS value will be determined by IANA.
Setting the RS RCODE in a response indicates to the resolver that
the resolver is retrying the query again without the DO bit set. The
behavior of the authority and additional records section being
populated should be the same using the RS RCODE as the the RCODE
being set to NXDOMAIN. Therefore, the resolver will be able to
verify that the answer does not exist within the secure zone since
the NXT RR will be sent in the Authority section. To avoid caching,
the server SHOULD set the TTL on the NXT RR to 0.
populated should be the same using the RS RCODE as the RCODE being
set to NXDOMAIN. Therefore, the resolver will be able to verify that
the answer does not exist within the secure zone since the NXT RR
will be sent in the Authority section. To avoid caching, the server
SHOULD set the TTL on the NXT RR to 0.
2) If the client has been identified as not being
RETRY-NO-SEC-AWARE, the server itself MUST consult the non-secure
view to compile the answer and respond back to the client. If the
RR exists, the answer will show up normally with in the Answer and
Additional sections and the NXT RR's within the Authority section
along with the KEY RR and its SIG in the Additional section. If the
RR does not exist, RCODE will be set to NXDOMAIN with the NXT RR
will be sent in the Authority section along with the KEY RR and its
SIG in the Additional section . Again, to avoid caching, the server
SHOULD set the TTL on the NXT RR to 0.
Note that latter case should be used during the transition of moving
to clients that understand the RS RCODE only. It should not be
Kosters Expires August 31, 2001 [Page 5]
Internet-Draft DNSSEC Opt In March 2001
viewed as a permanent solution and may deprecated in a short period
of time.
Example:
@@ -263,8 +307,9 @@ Internet-Draft DNSSEC Opt In November 2000
6 NS, SIG NS, NXT(9), SIG NXT
9 NS, SIG NS, NXT(@), SIG NXT
1. Query for 5 RR type A with EDNS0 DO bit set, the response would
return with the extended RCODE RS bit set:
1. Query for 5 RR type A with EDNS0 DO bit set along with the
RETRY-NO-SEC-AWARE option code, the response would return with
the extended RCODE RS bit set:
RCODE=RS
@@ -274,18 +319,33 @@ Internet-Draft DNSSEC Opt In November 2000
KEY, SIG KEY
The source would then retry without the EDNS0 DO bit set which
would return an answer as defined in RFC1035[2].
2. Query for 5 RR type A with EDNS0 DO bit only, the response would
return with the following:
Kosters Expires May 18, 2001 [Page 5]
RCODE=NOERROR
Answer Section:
5 NS
Authority Section:
Kosters Expires August 31, 2001 [Page 6]
Internet-Draft DNSSEC Opt In November 2000
Internet-Draft DNSSEC Opt In March 2001
The source would then retry without the EDNS0 DO bit set which
would return an answer as defined in RFC1035[2].
3 NXT(6), SIG NXT
Additional Section:
KEY, SIG KEY
2. Query for 55 RR type A with EDNS0 DO bit set, the response would
return with the extended RCODE RS bit set:
3. Query for 55 RR type A with EDNS0 DO bit set along with the
RETRY-NO-SEC-AWARE option code, the response would return with
the extended RCODE RS bit set:
RCODE=RS
@@ -296,12 +356,14 @@ Internet-Draft DNSSEC Opt In November 2000
The source would then retry without the EDNS0 DO bit set which
would return an answer as defined in RFC1035[2].
would return an answer as defined in RFC1035[2]. The subsequent
1035 answer would contain a RCODE of NXDOMAIN since the domain
55 does not exist.
3. Query for 33 RR type KEY without EDNS DO bit set. The response
4. Query for 3 RR type KEY without EDNS DO bit set. The response
would return with an answer as defined in RFC2535[4].
4. Query for 3 RR type A, with EDNS0 DO bit set, the response would
5. Query for 3 RR type A, with EDNS0 DO bit set, the response would
be the same as defined in RFC2535[4].
@@ -315,9 +377,22 @@ Internet-Draft DNSSEC Opt In November 2000
5. IANA Considerations
Allocation of the most significant bit of the RCODE field in the
1) Allocation of a bit within the reserved portion of the KEY RR to
indicate that the zone is an opt-in zone.
2) Allocation of the most significant bit of the RCODE field in the
EDNS0 OPT meta-RR is required.
3) Allocation of an option-code within the OPT RR to indicate that
the client can understand the new RCODE.
Kosters Expires August 31, 2001 [Page 7]
Internet-Draft DNSSEC Opt In March 2001
6. Acknowledgements
This document is based on a rough draft by Brian Wellington, and
@@ -331,12 +406,6 @@ References
[2] Mockapetris, P.V., "Domain names - implementation and
specification", RFC 1035, STD 13, Nov 1987.
Kosters Expires May 18, 2001 [Page 6]
Internet-Draft DNSSEC Opt In November 2000
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
@@ -375,27 +444,14 @@ Author's Address
Kosters Expires May 18, 2001 [Page 7]
Kosters Expires August 31, 2001 [Page 8]
Internet-Draft DNSSEC Opt In November 2000
Internet-Draft DNSSEC Opt In March 2001
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
@@ -444,5 +500,5 @@ Acknowledgement
Kosters Expires May 18, 2001 [Page 8]
Kosters Expires August 31, 2001 [Page 9]

30
doc/draft/draft-skwan-utf8-dns-04.txt → doc/draft/draft-skwan-utf8-dns-05.txt
View File

@@ -1,8 +1,9 @@
INTERNET-DRAFT Stuart Kwan
James Gilroy
Levon Esibov
Microsoft Corp.
July 2000
<draft-skwan-utf8-dns-04.txt> Expires January 2001
March 2001
<draft-skwan-utf8-dns-05.txt> Expires September 2001
Using the UTF-8 Character Set in the Domain Name System
@@ -48,11 +49,10 @@ superset of ASCII and a translation of the UCS-2 character encoding.
Expires January 2001 [Page 1]
Expires September 2001 [Page 1]
INTERNET-DRAFT UTF-8 DNS July 2000
INTERNET-DRAFT UTF-8 DNS March 2001
1. Introduction
@@ -105,10 +105,10 @@ UTF-8 characters before transmitting those names in any message.
Expires January 2001 [Page 2]
Expires September 2001 [Page 2]
INTERNET-DRAFT UTF-8 DNS July 2000
INTERNET-DRAFT UTF-8 DNS March 2001
For consistency, UTF-8-aware DNS servers must compare names that
@@ -162,10 +162,10 @@ Cliff Van Dyke and Bjorn Rettig.
Expires January 2001 [Page 3]
Expires September 2001 [Page 3]
INTERNET-DRAFT UTF-8 DNS July 2000
INTERNET-DRAFT UTF-8 DNS March 2001
6. References
@@ -203,6 +203,12 @@ Redmond, WA 98052 Redmond, WA 98052
USA USA
<skwan@microsoft.com> <jamesg@microsoft.com>
Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
<levone@microsoft.com>
@@ -213,14 +219,10 @@ USA USA
Expires September 2001 [Page 4]
Expires January 2001 [Page 4]