mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-29 13:38:26 +00:00
Code Issues Releases Wiki Activity

added and updated some drafts

Browse Source
This commit is contained in:
Andreas Gustafsson 1999-11-08 19:04:51 +00:00
parent f3d4453c9a
commit d8eee1b955
5 changed files with 1495 additions and 1077 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

132
doc/draft/draft-ietf-dnsind-apl-rr-02.txt → doc/draft/draft-ietf-dnsind-apl-rr-03.txt
View File

@ -1,9 +1,9 @@
INTERNET-DRAFT Peter Koch
Expires: December 1999 Universitaet Bielefeld
Updates: RFC 1035 June 1999
Expires: April 2000 Universitaet Bielefeld
Updates: RFC 1035 October 1999
A DNS RR Type for Lists of Address Prefixes (APL RR)
draft-ietf-dnsind-apl-rr-02.txt
draft-ietf-dnsind-apl-rr-03.txt
Status of this Memo
@ -45,20 +45,20 @@ Abstract
Domain names herein are for explanatory purposes only and should not
be expected to lead to useful information in real life [RFC2606].
Koch Expires December 1999 [Page 1]
Koch Expires April 2000 [Page 1]
INTERNET-DRAFT DNS APL RR June 1999
INTERNET-DRAFT DNS APL RR October 1999
2. Background
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
assign addresses and other internet infrastructure elements to
hierarchically built domain names. Various types of resource records
have been defined, especially those for IPv4 and IPv6 [RFC1886],
[A6DNSRR] 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 implemented using TXT RRs describing address ranges.
have been defined, especially those for IPv4 and IPv6 [RFC1886]
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
implemented using TXT RRs describing address ranges.
This document specifies a new RR type for address prefix lists.
@ -96,9 +96,9 @@ INTERNET-DRAFT DNS APL RR June 1999
This document defines the AFDPARTs for address families 1 (IPv4) and
Koch Expires December 1999 [Page 2]
Koch Expires April 2000 [Page 2]
INTERNET-DRAFT DNS APL RR June 1999
INTERNET-DRAFT DNS APL RR October 1999
2 (IPv6). Future revisions may deal with additional address
families.
@ -131,12 +131,15 @@ INTERNET-DRAFT DNS APL RR June 1999
The textual representation of an APL RR in a DNS zone file is as
follows:
<owner> IN <TTL> APL {[!]address/prefix}*
<owner> IN <TTL> APL {[!]afi:address/prefix}*
The data consists of zero or more strings of an address, immediately
followed by the "/" character, immediately followed by a decimal
numeric value for the prefix length. Any such string may be preceeded
by a "!" character. The strings are separated by whitespace.
The data consists of zero or more strings of the address family
indicator <afi>, immediately followed by a colon ":", an address,
immediately followed by the "/" character, immediately followed by a
decimal numeric value for the prefix length. Any such string may be
preceeded by a "!" character. The strings are separated by
whitespace. The <afi> is the decimal numeric value of that
particular address family.
5.1. Textual Representation of IPv4 Addresses
@ -146,13 +149,12 @@ INTERNET-DRAFT DNS APL RR June 1999
5.2. Textual Representation of IPv6 Addresses
Koch Expires April 2000 [Page 3]
INTERNET-DRAFT DNS APL RR October 1999
The representation of an IPv6 address in the <address> part of an
<apstring> follows [RFC2373], section 2.2. Legal values for <prefix>
Koch Expires December 1999 [Page 3]
INTERNET-DRAFT DNS APL RR June 1999
are from the interval 0..128 (decimal).
6. APL RR usage
@ -168,63 +170,92 @@ INTERNET-DRAFT DNS APL RR June 1999
by the available RDATA space.
RRSets consisting of more than one APL RR are legal but the
interpretation is left to the particular application. It may choose
to join the lists or treat them as alternatives.
interpretation is left to the particular application.
7. Applicability Statement
The APL RR defines a framework without specifying any particular
meaning for the list of prefixes. It is expected that APL RRs will
be used in different application scenarios which have to be
documented separately. Those scenarios may be distinguished by
characteristic prefixes placed in front of the DNS owner name.
An APL application specification MUST include information on
o the characteristic prefix, if any
o how to interpret APL RRSets consisting of more than one RR
o how to interpret an empty APL RR
o which address families are expected to appear in the APL RRs for
that application
o how to deal with APL RR list elements which belong to other
address families, including those not yet defined
Possible applications include the publication of address ranges
similar to [RFC1101], description of zones built following [RFC2317]
and in-band access control to limit general access or zone transfer
(AXFR) availability for zone data held in DNS servers.
7. Examples
The specification of particular application scenarios is out of the
Example usages otlined in the prevois section are shown here. The
line continuation symbol in the second APL RR appears for editorial
purposes only, it is not valid in zone files.
Koch Expires April 2000 [Page 4]
foo.example APL 192.168.32.0/21 !192.168.38.0/28
INTERNET-DRAFT DNS APL RR October 1999
42.168.192.IN-ADDR.ARPA APL 192.168.42.0/26 192.168.42.64/26 \
192.168.42.128/25
scope of this document.
_axfr.sbo.example APL 127.0.0.1/32 172.16.64.0/22
8. Examples
multicast.example APL 224.0.0.0/4 FF00:0:0:0:0:0:0:0/8
The following examples only illustrate some of the possible usages
outlined in the previous section. None of those applications are
hereby specified nor is it implied that any particular APL RR based
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
; 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 )
; Zone transfer restriction
_axfr.sbo.example 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
Note that since trailing zeroes are ignored in the first APL RR the
AFDLENGTH of both <apstrings> is three.
8. Security Considerations
9. Security Considerations
Any information obtained from the DNS should be regarded as unsafe
unless techniques specified in [RFC2535] or [TSIGRR] were used. The
definition of a new RR type does not introduce security problems into
the DNS, but usage of information made available by APL RRs may
compromise security. This includes disclosure of network topology
Koch Expires December 1999 [Page 4]
INTERNET-DRAFT DNS APL RR June 1999
information and in particular the use of APL RRs to construct access
control lists.
9. IANA Considerations
10. IANA Considerations
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.
10. Acknowledgements
11. Acknowledgements
The author would like to thank Mark Andrews for his review and
constructive comments.
11. References
12. References
[A6DNSRR] Crawford,M., Huitema,C., Thomson,S., "DNS Extensions to
Support IPv6 Address Aggregation and Renumbering",
<draft-ietf-ipngwg-dns-lookups-XX.txt>, work in progress
Koch Expires April 2000 [Page 5]
INTERNET-DRAFT DNS APL RR October 1999
[RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
RFC 1034, STD 13, November 1987
@ -244,6 +275,9 @@ INTERNET-DRAFT DNS APL RR June 1999
[RFC2181] Elz,R., Bush,R., "Clarifications to the DNS
Specification", RFC 2181, July 1997
[RFC2317] Eidnes,H., de Groot,G., Vixie,P., "Classless IN-ADDR.ARPA
delegation", RFC 2317, March 1998
[RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998
@ -253,15 +287,11 @@ INTERNET-DRAFT DNS APL RR June 1999
[RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
RFC 2606, BCP 32, June 1999
Koch Expires December 1999 [Page 5]
INTERNET-DRAFT DNS APL RR June 1999
[TSIGRR] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B.,
"Secret Key Transaction Signatures for DNS (TSIG)",
<draft-ietf-dnsind-tsig-XX.txt>, work in progress
12. Author's Address
13. Author's Address
Peter Koch
Universitaet Bielefeld
@ -272,4 +302,4 @@ INTERNET-DRAFT DNS APL RR June 1999
+49 521 106 2902
<pk@TechFak.Uni-Bielefeld.DE>
Koch Expires December 1999 [Page 6]
Koch Expires April 2000 [Page 6]

755
doc/draft/draft-ietf-dnsind-iana-dns-00.txt
View File

@ -1,755 +0,0 @@
INTERNET-DRAFT Donald E. Eastlake 3rd (IBM)
Eric Brunner (Nokia)
Bill Manning (ISI)
Expires: February 2000 August 1999
draft-ietf-dnsind-iana-dns-00.txt
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
Status of This Document
This draft, file name draft-ietf-dnsind-iana-dns-00.txt, is intended
to become a Best Current Practice RFC. Distribution of this document
is unlimited. Comments should be sent to the DNS Working Group
mailing list <namedroppers@internic.com> or to the authors.
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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories as listed at <http://www.ietf.org/shadow.html>.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 1]
INTERNET-DRAFT DNS IANA Considerations August 1999
Abstract
Internet Assigned Number Authority (IANA) considerations are given
for the allocation of Domain Name System (DNS) classes, RR types,
operation codes, error codes, etc.
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Header Structure.....................3
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................4
2.3 RCODE Assignment.......................................4
3. DNS Resource Record Structure...........................5
3.1 RR TYPE IANA Considerations............................7
3.1.1 Special Note on the OPT RR...........................7
3.1.2 Special Note on the SINK RR..........................8
3.2 RR CLASS IANA Considerations...........................8
3.3 IANA DNS Name Considerations...........................9
3.3.1 Becoming Root........................................9
3.3.1 Reserved TLDs in the IN CLASS........................9
3.3.2 'Country Code' TLDs in the IN CLASS.................10
3.3.3 Other TLDs in the IN CLASS..........................10
4. Security Considerations................................11
References................................................12
Authors Addresses.........................................13
Expiration and File Name..................................13
D. Eastlake 3rd, E. Brunner, B. Manning [Page 2]
INTERNET-DRAFT DNS IANA Considerations August 1999
1. Introduction
The Domain Name System (DNS) provides a replicated distributed secure
hierarchical database which stores "resource records" (RRs) by CLASS
under hierarchical domain names. This data is structured into
CLASSes and zones which can be independently maintained. See [RFC
1034, 1035, 2136, 2181, 2535, etc.] familiarity with which is
assumed.
This document covers general IANA considerations applying across DNS
query and response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or
query/response opcode. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been
defined.
The terms of art used herein with respect to IANA Considerations are
as defined in [RFC 2434].
2. DNS Query/Response Header Structure
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136/2535]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
D. Eastlake 3rd, E. Brunner, B. Manning [Page 3]
INTERNET-DRAFT DNS IANA Considerations August 1999
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous and such meanings
may only be assigned by an IETF standards action.
The QDCOUNT, ANCOUNT, NSCOUNT, and ARCOUNT fields give the number of
queries in the Query section, answer RRs in the Answer section, RRs
in the Authority section, and informational RRs in the Additional
Information section, respectively, for all opcodes except Update.
These fields have the same structure and data type for update but are
instead the counts for the Zone, Prerequisite, Update, and Additional
Information sections.
2.1 One Spare Bit?
While it would appear that the "Z" bit is spare, there have been DNS
implementations for which that bit being on in a query meant that
only a response from the primary server for a zone is acceptable. It
is believed that modern DNS implementations ignore this bit.
Assigning a meaning to this bit requires an IETF standards action.
2.2 Opcode Assignment
IANA DNS OpCode assignments are shown at <ftp://ftp.isi.edu/in-
notes/iana/assignments/dns-parameters>.
Currently the following OpCodes are assigned.
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
New OpCode assignments require an IETF consensus.
2.3 RCODE Assignment
Current IANA DNS RCODE assignments are shown at
<ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters>...
D. Eastlake 3rd, E. Brunner, B. Manning [Page 4]
INTERNET-DRAFT DNS IANA Considerations August 1999
The range of RCODEs is extended beyond four bits to twelve bits for
implementations of DNS supporting the OPT RR (see Section 3.1.1).
RCODEs can appear both at the top level of a DNS response in the
header or inside TSIG RRs [RFC XXX3]. The TSIG RR has a 16 bit RCODE
error field.
RCODE Name Reference
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADSIG Signature Failure [RFC XXX3]
17 BADKEY Key not recognized [RFC XXX3]
18 BADTIME Signature out of time window [RFC XXX3]
19-0xFFFF available for assignment
Since it is important that RCODEs be understood for interoperability,
new RCODE assignment requires an IETF consensus.
3. DNS Resource Record Structure
All RRs have the same top level format shown in the figure below
taken from RFC 1035:
D. Eastlake 3rd, E. Brunner, B. Manning [Page 5]
INTERNET-DRAFT DNS IANA Considerations August 1999
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. Names are specific to a CLASS as described
in section 3.2. Names consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035]. The last label in
each name is "root" which is wire encoded as a single zero octet.
New label types are assigned as provided in [RFC XXX1].
TYPE is two octets containing one of the RR TYPE codes. See section
3.1.
CLASS is two octets containing one of the RR CLASS codes. See
section 3.2.
TTL is a 32 bit unsigned integer that specifies the time interval
that the resource record may be cached before the source of the
information should again be consulted. Zero is interpreted to mean
that the RR can only be used for the transaction in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATA is a variable length string of octets that describes the
resource. The format of this information varies according to the
TYPE and in some cases the CLASS of the resource record.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 6]
INTERNET-DRAFT DNS IANA Considerations August 1999
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and Meta-TYPEs. QTYPES can only be used in queries. Meta-TYPEs
designate transient data associate with an particular DNS message and
in some cases can also be used in queries. Thus far, data types have
been assigned from 1 upwards plus the block from 100 through 103
while Q and Meta Types have been assigned from 255 downwards. IANA
RR TYPE assignments are documented at <ftp://ftp.isi.edu/in-
notes/iana/assignments/dns-parameters>.
There are currently three Meta-types: TSIG [RFC XXX3], TKEY, and OPT
[RFC XXX1].
There are currently five Qtypes: * (all), MAILA, MAILB, AXFR, and
IXFR.
RR TYPE zero is used as a special indicator for the SIG RR [RFC 2535]
and in other circumstances and must never be allocated for ordinary
use.
Remaining types in the range 0x0001 to 0x7FFF are assigned by
authority of IETF consensus. The current pattern of assigning
regular data types from 1 upwards and Q and Meta types from 255
downward should continue until that range is exhausted.
Types from 0x8000 through 0xFEFF are assigned based on RFC
publication.
Types from 0xFF00 through 0xFFFF are for private experimental use.
Because their use is not coordinated, it may conflict between
different experiments.
3.1.1 Special Note on the OPT RR
The OPT (OPTion) RR, number (TBD), is specified in [RFC XXX1]. Its
primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
IANA considerations for label types are given in [RFC XXX1].
D. Eastlake 3rd, E. Brunner, B. Manning [Page 7]
INTERNET-DRAFT DNS IANA Considerations August 1999
3.1.2 Special Note on the SINK RR
The (Kitchen) SINK RR, number 40, is specified in RFC [XXX2]. It is
designed to accommodate demands for proprietary RRs and provides
flexible encoding and semantic labeling of the RDATA potion. This
should virtually eliminate the need to allocate RR types codes for
private or proprietary purposes.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the namespace or roots servers for one CLASS and
those for another CLASS. A name can have completely different
meanings in different CLASSes. However, as global networking and DNS
have evolved, the IN, or Internet, CLASS has dominated DNS use.
IANA DNS CLASS assignments are shown at <ftp://ftp.isi.edu/in-
notes/iana/assignments/dns-parameters>. There are two subcategories
of DNS CLASSes: normal data containing classes and QCLASSes that are
only meaningful in queries or updates. The current data class
assignments are as follows: 1 - Internet (IN), 3 - Chaos (CH), and 4
- Hesiod (HS). The currently assigned Q classes are as follows: 255
- Any and 254 - None.
Allocation of CLASS 0x0000 requires an IETF standards action.
Allocation of remaining CLASSes in the range of 0x0001-0x00FF are by
IETF consensus with data classes given the lowest available value and
QCLASSes the highest available value in that range until that range
is exhausted.
Allocation of CLASSes in the range 0x0100 through 0x7FFF is by IETF
consensus.
Allocation of CLASSes in the range 0x8000 through 0xFEFF is by RFC
publication.
CLASSes in the range 0xF000 through 0xFFFE are for private
experimental use. Because their use is not coordinated, it may
conflict between different experiments.
CLASS 0xFFFF can only be assigned by an IETF standards action.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 8]
INTERNET-DRAFT DNS IANA Considerations August 1999
3.3 IANA DNS Name Considerations
TheHesiod [Dyer 87] and Chaos CLASSes are essentially for local use.
(Chaos was a network system implemented at MIT.) The IN CLASS is the
only DNS CLASS in global use on the Internet at this time.
3.3.1 Becoming Root
In practice, it is quite easy to put up a set of root servers. DNS
resolvers which use those root servers will see the namespace they
support. DNS has only downward pointers from zone to subzone and no
upward pointers going from zone to superzone. Thus, in creating a
root zone, it works technically to pick whatever top level domains
(TLDs) you want including, if you wish, TLDs that are not generally
recognized.
Setting up your own root zone like this is commonly done within local
enclaves to hide some local names, for security and efficiency. In
some cases, local TLDs are added. But for the global Internet, the
use of variant root zones would lead to non-interoperability at the
application level. Users would find that email addresses didn't work
or addressed different accounts for those using different root zone
contents. Links in web pages wouldn't work or would address
different web resources for those using different root zone contents.
As a result, despite strenuous attempts to promote alternatives, no
significant portion of the global Internet has ever used other than
the IETF recommended root zone contents except, in some cases, for
strictly local names.
3.3.1 Reserved TLDs in the IN CLASS
All single octet length top level domain (TLD) names in the IN class
are reserved as are all TLDs containing any octets that are not ASCII
letters or digits. One reason for reserving single octet TLDs is
that, should the root zone ever get very large, there are technical
solutions which would be eased by having the single byte TLDs
available.
[For like reasons, it is recommended that within TLDs or indeed
within any zone that is or might become very large, all single octet
names be reserved. However, this decision is up to the authority for
each non-root zone.]
Binary label TLDs [RFC XXX4] and other new TLD label data types are
reserved.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 9]
INTERNET-DRAFT DNS IANA Considerations August 1999
The above reservations also provides a means of escape should other
name allocation paint the IN CLASS namespace into a corner.
Assignment of the above reserved names requires an IETF consensus.
Finally, the four TLDs "example", "invalid", "localhost", and "test"
are reserved as described in [RFC 2606].
3.3.2 'Country Code' TLDs in the IN CLASS
All two octet length TLDs in the IN class consisting of letters are
reserved for assignment to territories. Those (1) allocated by [ISO
3166] and (2) allocated by the Universal Postal Union [UPU] and
reserved in [ISO 3166] even though not formally assigned by [ISO
3166] (e.g., a few British Channel Islands), are assigned as so
allocated by the generally recognized acting government of the area
associated with the "country code" or on a first come first served
basis to a designated registry if there is no such government or the
government has not exercised control. In addition, due to historical
factors and consistent with the normal diplomatic usage of special
consideration for founders, the United States of America, as founder
of the Internet, is also assigned the three letter TLDs "gov" and
"mil". A country code for a territory with a generally recognized
acting government should be considered part of the territory of that
government. Decisions by said government as to who should control
the DNS for that TLD are final and unappealable.
Country codes consisting of a letter and a digit or two digits are
not currently used by [ISO 3166] or the [UPU]. However, to permit
possible expansion of the two octet country codes, they are reserved
for future allocation as described in the previous paragraph.
3.3.3 Other TLDs in the IN CLASS
IANA manages the "arpa" and "int" TLDs. The "arpa" TLD is assigned
for use in the IPv4 inverse mapping and IANA delegates /8 subzones to
holders of a /8 chunk of address space, including the regional
address registries. "int" includes the IPv6 inverse address mapping
which is at "ip6.int", international registrations at "reg.int", and
also provides for recognized international organizations. IANA
considerations for IP address assignment are given elsewhere.
Control and assignment of various other existing or prospective IN
CLASS TLDs is currently in a state of flux being transfered to the
ICANN (www.icann.org) DNSO (Domain Name Support Organization,
www.dnso.org). Traditionally "edu" was used for educational
D. Eastlake 3rd, E. Brunner, B. Manning [Page 10]
INTERNET-DRAFT DNS IANA Considerations August 1999
institutions, "net" for network infrastructure organizations, "com"
for commercial organizations, and "org" for other non-profit
organizations.
New registrations in "edu" are currently restricted to four year or
longer institutions of higher learning.
4. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 2535] for secure DNS
considerations.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 11]
INTERNET-DRAFT DNS IANA Considerations August 1999
References
[Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987,
[ISO 3166] - Codes for the representation of names of countries.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
Facilities", STD 13, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
Specification", July 1997.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
[RFC XXX1] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", xxx
1999 (draft-ietf-dnsind-edns0-*.txt).
[RFC XXX2] - D. Eastlake, "The Kitchen Sink DNS Resource Record", xxx
1999 (draft-ietf-dnsind-kitchen-sink-*.txt).
[RFC XXX3] - P. Vixie, O. Gundmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Signatures for DNS (TSIG)" xxx 1999 (draft-
ietf-dnsind-tsig-*.txt).
[RFC XXX4] - M. Crawford, "Binary Labels in the Domain Name System",
xxx 1999 (draft-ietf-dnsind-binary-labels-*.txt).
[UPU] - <http://www.upu/int>
D. Eastlake 3rd, E. Brunner, B. Manning [Page 12]
INTERNET-DRAFT DNS IANA Considerations August 1999
Authors Addresses
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road
Carmel, NY 10512 USA
Telephone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
fax: +1-914-784-3833 (w)
email: dee3@us.ibm.com
Eric Brunner
Mokia Research Center
3 Burlington Woods Drive, Suite 250
Burlington, MA 01803 USA
Telephone: +1 781-359-5159
fax: +1 781-359-5196
email: brunner@maine.rr.com
Bill Manning
USC/ISI
4676 Admiralty Way, #1001
Marina del Rey, CA 90292 USA
Telephone: +1 310 822 1511
email: bmanning@isi.edu
Expiration and File Name
This draft expires February 2000.
Its file name is draft-ietf-dnsind-iana-dns-00.txt.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 13]

927
doc/draft/draft-ietf-dnsind-iana-dns-02.txt Normal file
View File

@ -0,0 +1,927 @@
INTERNET-DRAFT Donald E. Eastlake 3rd (IBM)
Eric Brunner (Nokia)
Bill Manning (ISI)
Expires: April 2000 October 1999
draft-ietf-dnsind-iana-dns-02.txt
Domain Name System (DNS) IANA Considerations
------ ---- ------ ----- ---- --------------
Status of This Document
Distribution of this draft <draft-ietf-dnsind-iana-dns-02.txt> is
unlimited. Comments should be sent to the DNS Working Group mailing
list <namedroppers@internic.net> or to the authors.
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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 1]
INTERNET-DRAFT DNS IANA Considerations October 1999
Abstract
Internet Assigned Number Authority (IANA) considerations are given
for the allocation of Domain Name System (DNS) classes, RR types,
operation codes, error codes, etc.
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Table of Contents..........................................2
1. Introduction............................................3
2. DNS Query/Response Headers..............................4
2.1 One Spare Bit?.........................................4
2.2 Opcode Assignment......................................5
2.3 RCODE Assignment.......................................5
3. DNS Resource Records....................................7
3.1 RR TYPE IANA Considerations............................8
3.1.1 Special Note on the OPT RR...........................8
3.1.2 Special Note on the SINK RR..........................9
3.2 RR CLASS IANA Considerations...........................9
3.3 RR NAME IANA Considerations...........................10
3.3.1 Reserved TLDs in the Internet CLASS.................10
3.3.2 'Country Code' TLDs in the Internet CLASS...........11
3.3.3 Other TLDs in the Internet CLASS....................12
4. Security Considerations................................13
References................................................13
Appendix: Single Letter or Digit Labels...................15
Authors Addresses.........................................16
Expiration and File Name..................................16
D. Eastlake 3rd, E. Brunner, B. Manning [Page 2]
INTERNET-DRAFT DNS IANA Considerations October 1999
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchially store "resource records"
(RRs) by CLASS under domain names.
This data is structured into CLASSes and zones which can be
independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]
familiarity with which is assumed.
This document covers, either directly or by reference, general IANA
considerations applying across DNS query and response headers and all
RRs. There may be additional IANA considerations that apply to only
a particular RR type or query/response opcode. See the specific RFC
defining that RR type or query/response opcode for such
considerations if they have been defined.
IANA presently maintains a web page of DNS parameters at
<http://www.isi.edu/in-notes/iana/assignments/dns-parameters>.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
The terms of art used herein with respect to IANA Considerations are
as defined in [RFC 2434].
D. Eastlake 3rd, E. Brunner, B. Manning [Page 3]
INTERNET-DRAFT DNS IANA Considerations October 1999
2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2535]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF
standards action.
The QDCOUNT, ANCOUNT, NSCOUNT, and ARCOUNT fields give the number of
queries in the Query section, answer RRs in the Answer section, RRs
in the Authority section, and informational RRs in the Additional
Information section, respectively, for all opcodes except Update.
These fields have the same structure and data type for update but are
instead the counts for the Zone (ZOCOUNT), Prerequisite (PRCOUNT),
Update (UPCOUNT), and Additional Information (ARCOUNT) sections.
2.1 One Spare Bit?
It would appear that the "Z" bit is spare and [RFC 1035] says that it
must be zero in all queries and responses. However, there have been
DNS implementations for which that bit being on in a query meant that
D. Eastlake 3rd, E. Brunner, B. Manning [Page 4]
INTERNET-DRAFT DNS IANA Considerations October 1999
only a response from the primary server for a zone is acceptable.
It is believed that modern DNS implementations ignore this bit.
Assigning a meaning to this bit requires an IETF standards action.
2.2 Opcode Assignment
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
New OpCode assignments require an IETF consensus.
2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
TSIG RRs [RFC XXX3] and OPT RRs [RFC 2671]. The OPT RR provides an
eight bit extension resulting in a 12 bit RCODE field and the TSIG RR
has a 16 bit RCODE field.
RCODE Name Reference
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADSIG Signature Failure [RFC XXX3]
D. Eastlake 3rd, E. Brunner, B. Manning [Page 5]
INTERNET-DRAFT DNS IANA Considerations October 1999
17 BADKEY Key not recognized [RFC XXX3]
18 BADTIME Signature out of time window [RFC XXX3]
19-0xFFFF available for assignment
Since it is important that RCODEs be understood for interoperability,
new RCODE assignment requires an IETF consensus.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 6]
INTERNET-DRAFT DNS IANA Considerations October 1999
3. DNS Resource Records
All RRs have the same top level format shown in the figure below
taken from [RFC 1035]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035, 2671]. See also
IANA NAME considerations in section 3.3.
TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
TTL is a four octet (32 bit) bit unsigned integer that specifies the
number of seconds that the resource record may be cached before the
source of the information should again be consulted. Zero is
interpreted to mean that the RR can only be used for the transaction
in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the
TYPE and in some cases the CLASS of the resource record.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 7]
INTERNET-DRAFT DNS IANA Considerations October 1999
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and MetaTYPEs.
Data TYPEs are the primary means of storing data QTYPES can only be
used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
the block from 100 through 103 while Q and Meta Types have been
assigned from 255 downwards (??? except for the OPT RR which is
assigned TYPE 41 ???).
There are currently three Meta-TYPEs: TSIG [RFC XXX3], TKEY [RFC
XXX5], and OPT [RFC 2671].
There are currently five QTYPEs: * (all), MAILA, MAILB, AXFR, and
IXFR.
Considerations for the allocation of new RR TYPEs are as follows:
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs only by IETF consensus.
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs only by IETF consensus.
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
consensus.
0x8000 - 0xFEFF - assigned based on RFC publication.
0xFF00 - 0xFFFF - this block is assigned for private experimental
use. Because their use is not coordinated, values/uses may
conflict between different experiments.
3.1.1 Special Note on the OPT RR
The OPT (OPTion) RR, number 41 (???), is specified in [RFC 2671].
Its primary purpose is to extend the effective field size of various
DNS fields including RCODE, label type, OpCode, flag bits, and RDATA
size. In particular, for resolvers and servers that recognize it, it
extends the RCODE field from 4 to 12 bits.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 8]
INTERNET-DRAFT DNS IANA Considerations October 1999
3.1.2 Special Note on the SINK RR
The (Kitchen) SINK RR, number 40, is specified in RFC [XXX2]. It is
designed to accommodate requirements for proprietary RRs and provides
flexible encoding and semantic labeling of the RDATA potion. This
should virtually eliminate the need to allocate RR types codes for
private or proprietary purposes.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the namespace or roots servers for one CLASS and
those for another CLASS. The same name can have completely different
meanings in different CLASSes. However, as global networking and DNS
have evolved, the IN, or Internet, CLASS has dominated DNS use.
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current data class assignments and considerations for future
assignments are as follows:
0x0000 - assignment requires an IETF standards action.
0x0001 - Internet (IN).
0x0002 - available for assignment by IETF consensus as a data CLASS.
0x0003 - Chaos (CH) [Moon 81].
0x0004 - Hesiod (HS) [Dyer 87].
0x0005 - 0x007F - available for assignment by IETF consensus as data
CLASSes only.
0x0080 - 0xFFFD - available for assignment by IETF consensus as
QCLASSes only.
0x00FE - QCLASS None [RFC 2136].
0x00FF - QCLASS Any [RFC 1035].
0x0100 - 0x7FFF - assigned by IETF consensus.
0x8000 - 0xFEFF - assigned by RFC publication.
0xFF00 through 0xFFFE are assigned for private experimental use.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 9]
INTERNET-DRAFT DNS IANA Considerations October 1999
Because their use is not coordinated, it values/uses may
conflict between different experiments.
0xFFFF - can only be assigned by an IETF standards action.
3.3 RR NAME IANA Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
NAME is "ROOT" which is the zero length label. By definition, the
null or ROOT label can not be used for any other NAME purpose.
At the present time, there are two categories of label types, data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs. The two existing data label
types will be referred to as ASCII and Binary. ASCII labels can, in
fact, include any octet value including zero octets but most current
uses involve only [US-ASCII] For retrieval ASCII labels are defined
to treat upper and lower case letters the same. Binary labels are
bit sequences [RFC 2673].
IANA considerations for label types are given in [RFC 2671].
NAMEs are local to a CLASS. The Hesiod [Dyer 87] and Chaos [Moon 81]
CLASSes are essentially for local use. The IN or Internet CLASS is
thus the only DNS CLASS in global use on the Internet at this time.
The following subsections give IANA considerations for the allocation
of names in the IETF recommended root zone. See also [RFC 1591].
3.3.1 Reserved TLDs in the Internet CLASS
[NOTE: Reserved Top Level DNS Names are BCP 32. The material here
and in the Appendix needs to be made into an update/supplement to BCP
32.]
All Binary label TLDs [RFC 2673] and other new non-ASCII TLD label
data types are reserved.
The remainder of this subsection and 3.3.2 and 3.3.3 refer only to
ASCII labels.
All TLDs including any octets that are not letters, digits, or hyphen
are reserved. Expression of internationalized names in the DNS is an
active area of investigation within the IETF at this time and may
make use of these reserved TLD octet values.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 10]
INTERNET-DRAFT DNS IANA Considerations October 1999
All numeric TLDs from "0" through "4294967295" ( 2**32 -1 ) are
reserved to avoid conflict with IPv4 integer and dotted quad address
notations. While many standards distinguish readable addresses by
surrounding them with square brackets ("[]"), other widely used
standards such as URIs [RFC 2396] do not provide any syntactic way to
distinguish these.
All single octet length top level domain (TLD) names are reserved.
Should the root zone ever get very large, there are technical
solutions involving referral to servers providing splits of the zone
based on the first name octet, which would be eased by having the
single byte TLDs available. In addition, these provide a potential
additional axis for DNS expansion. For like reasons, it is
recommended that within TLD zones or indeed within any zone that is
or might become very large, in the absence of a strong reason to the
contrary, all single octet names be reserved. See Appendix.
Finally, the four ASCII TLDs "example", "invalid", "localhost", and
"test" are reserved as described in [RFC 2606].
Assignment of any of the above reserved names requires an IETF
consensus.
3.3.2 'Country Code' TLDs in the Internet CLASS
Two octet length ASCII label TLDs in the Internet CLASS consisting of
letters are for assignment to geo-political territories. Those (1)
allocated by [ISO 3166-1] and (2) allocated by the Universal Postal
Union [UPU] and reserved in [ISO 3166-1] even though not formally
assigned by [ISO 3166-1], are assigned as so allocated. Two letter
codes reserved by [ISO 3166-1] for local use or the like are also
reserved as TLDs as are two letter TLDs not yet allocated or reserved
by [ISO 3166-1]. A generally recognized acting government of the
territory associated with a "country code" has priority to act as or
designate the registrar for such TLDs. If no such government has
exercised its authority, non-governmental entities may act as the
registrar (see www.iana.org).
Normal diplomatic usage recognizes that special consideration can be
given to founders. For example, at every Olympics, three flags are
equally honored: the Olympic flag, the host nation flag, and the
Greek flag because Greece was the founder of the modern Olympics.
The Universal Postal Union [UPU] requires all stamps used
internationally to indicate the country issuing them except for the
stamps of Great Britain. As the first nation to issue stamps, it is
exempt from this restriction. Similarly, as the founder of the
Internet and due to historical factors, the United States of America
is assigned the three letter TLDs ".gov" and ".mil" in addition to
D. Eastlake 3rd, E. Brunner, B. Manning [Page 11]
INTERNET-DRAFT DNS IANA Considerations October 1999
".us".
Two byte codes consisting of other than letters and not reserved in
3.3.1 above are not currently used by [ISO 3166-1] or the [UPU].
However, to permit possible expansion of the two octet country codes,
they are reserved for future allocation with priority to be given for
usage by [ISO 3166-1]
3.3.3 Other TLDs in the Internet CLASS
IANA manages the ".arpa" and ".int" TLDs. The "arpa" TLD is assigned
for use in the IPv4 inverse mapping and IANA delegates /8 subzones to
holders of a /8 chunk of address space, including the regional
address registries. "int" includes the IPv6 inverse address mapping
which is at "ip6.int", international treaty organizations, and
international registrations at "reg.int". IANA considerations for IP
address assignment are given elsewhere.
Control and assignment of various other existing or prospective
Internet CLASS TLDs and the authority for the creation of new TLDs is
being transferred to the ICANN (www.icann.org) and the DNSO (Domain
Name Support Organization, www.dnso.org). Traditionally ".edu" was
used for educational institutions, ".net" for network infrastructure
organizations, "com" for commercial organizations, and ".org" for
other non-profit organizations.
New registrations in ".edu" are currently restricted to four year or
longer institutions of higher learning.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 12]
INTERNET-DRAFT DNS IANA Considerations October 1999
4. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 2535] for secure DNS
considerations.
References
[Dyer 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987,
[ISO 3166-1] - "Codes for the representation of names of countries",
<http://www.din.de/gremien/nas/nabd/iso3166ma/>.
[Moon 81] - D. moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence Laboratory, June
1981.
[RFC 1034] - P. Mockapetris, "Domain Names - Concepts and
Facilities", STD 13, November 1987.
[RFC 1035] - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
[RFC 1591] - J. Postel, "Domain Name System Structure and
Delegation", March 1994.
[RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", August 1996.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.
[RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS
Specification", July 1997.
[RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", August 1998.
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
in RFCs", T. Narten, H. Alvestrand, October 1998.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 13]
INTERNET-DRAFT DNS IANA Considerations October 1999
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
1999.
[RFC 2672] - M. Crawford, " Non-Terminal DNS Name Redirection",
August 1999.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
August 1999.
[RFC XXX2] - D. Eastlake, "The Kitchen Sink DNS Resource Record", xxx
1999 (draft-ietf-dnsind-kitchen-sink-*.txt).
[RFC XXX3] - P. Vixie, O. Gundmundsson, D. Eastlake, B. Wellington,
"Secret Key Transaction Signatures for DNS (TSIG)", xxx 1999 (draft-
ietf-dnsind-tsig-*.txt).
[RFC XXX5] - D. Eastlake, "Secret Key Establishment for DNS (TKEY
RR)", xxx 1999 (draft-ietf-dnsind-tkey-00.txt).
[UPU] - Universal Postal Union, <http://www.upu.int>
[US-ASCII - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 14]
INTERNET-DRAFT DNS IANA Considerations October 1999
Appendix: Single Letter or Digit Labels
As described in Section 3.3.1, single octet ASCII labels should
generally be reserved.
In furtherance of this, on December 1st, 1993, IANA explicitly
reserved all available single letter and single digit second level
domain names in ".com", ".net", and ".org". Existing assignments,
listed below, were not disturbed.
q.com JG (Q225-DOM)
x.com Weinstein & DePaolis (X-DOM)
z.com HomePage.com, Inc (Z87-DOM)
i.net inet solutions pty.ltd. (I274-DOM)
q.net Q Net (Q-DOM)
x.org The Open Group (X57-DOM)
There was no need to explicitly reserve other single octet second
level domain names in these TLDs because such non-letter non-digit
names were not being assigned. There was no need to explicitly
reserve single octet top level domain names because those required
IANA approval in any case.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 15]
INTERNET-DRAFT DNS IANA Considerations October 1999
Authors Addresses
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road
Carmel, NY 10512 USA
Telephone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
fax: +1-914-784-3833 (w)
email: dee3@us.ibm.com
Eric Brunner
Nokia Research Center
3 Burlington Woods Drive, Suite 250
Burlington, MA 01803 USA
Telephone: +1 781-359-5159
fax: +1 781-359-5196
email: brunner@world.std.com
Bill Manning
USC/ISI
4676 Admiralty Way, #1001
Marina del Rey, CA 90292 USA
Telephone: +1 310 822 1511
email: bmanning@isi.edu
Expiration and File Name
This draft expires April 2000.
Its file name is draft-ietf-dnsind-iana-dns-02.txt.
D. Eastlake 3rd, E. Brunner, B. Manning [Page 16]

164
doc/draft/draft-ietf-dnsind-sigalgopt-00.txt Normal file
View File

@ -0,0 +1,164 @@
Network Working Group R. Austein
draft-ietf-dnsind-sigalgopt-00.txt On Sabbatical
P. Vixie
Internet Software Consortium
October 1999
DNS SIGALGOPT
Status of this document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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>
Distribution of this document is unlimited. Please send comments to
the namedroppers@internic.net mailing list.
Abstract
This document describes a mechanism for conserving packet space in a
DNS response message in the presence of multiple DNSSEC signature
algorithms.
Motivation and Scope
DNSSEC [DNSSEC] specifies a general framework for attaching
cryptographic signatures to DNS resource records. The framework
includes provisions for multiple signature protocols, possibly even
on a per-name basis. While this open-ended framework is good and
useful, it poses a problem when multiple signature protocols are in
use and DNS message sizes are limited by the underlying UDP transport
packet size. EDNS0 [EDNS0] provides a way to specify a larger
Austein & Vixie Expires 18 April 2000 [Page 1]
draft-ietf-dnsind-sigalgopt-00.txt October 1999
payload size, but this still does not entirely solve the problem for
large RRsets. Worse, in cases where multiple signature algorithms
generate a response packet so large that it must be truncated, the
signatures that fit into the truncated response will be useless if
the resolver doesn't know how to verify signatures generated with
that algorithm.
This note proposes a way for a resolver to indicate which signature
algorithms it understands to a name server in the form of an ordered
list. When this mechanism is in use, the name server can conserve
packet space by (a) not sending signatures with algorithms that the
resolver will not understand, and (b) not sending multiple signatures
for the same resource records.
Mechanism
[DNSSEC] SIG RRs include a one-octet code indicating the algorithm
associated with a particular signature. The SIGALGOPT option defined
below allows the resolver to specify an ordered list of signature
algorithms using the same one-octet codes that DNSSEC uses.
SIGALGOPT is encoded n the variable RDATA part of the OPT pseudo-RR
in the DNS request (see [EDNS0]).
The OPTION-CODE for SIGALGOPT is [TBD].
The OPTION-DATA for SIGALGOPT is an ordered list of the one-octet
codes used by DNSSEC.
If the SIGALGOPT option in a query specifies multiple signature
algorithms and signatures using more than one of those algorithms are
available in the zone, the server must respond with the signatures
corresponding to the first algorithm on the SIGALGOPT list that
matches, omitting any signatures corresponding to the remaining
algorithms.
We have deliberately not provided a mechanism to return all the
matching signatures, because the purpose of the SIGALGOPT mechanism
is to minimize packet size. If the resolver wants to see all
available signatures, it should just leave off the SIGALGOPT option
entirely.
Security Considerations
Good question. What horrible things could a bad guy do by
creating/altering/deleting SIGALGOPT? Are any of the possible
attacks more interesting than denial of service?
Austein & Vixie Expires 18 April 2000 [Page 2]
draft-ietf-dnsind-sigalgopt-00.txt October 1999
IANA Considerations
SIGALGOPT will need an option code.
The signature algorithm codes themselves are borrowed from DNSSEC and
do not create any new issues for IANA.
References
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
facilities", RFC 1034, November 1987.
[DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
and specification", RFC 1035, November 1987.
[EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
Author's addresses:
Rob Austein
On Sabbatical
sra@hactrn.net
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
vixie@isc.org
Austein & Vixie Expires 18 April 2000 [Page 3]

594
doc/draft/draft-ietf-dnsind-tkey-00.txt → doc/draft/draft-ietf-dnsind-tkey-01.txt
View File

@ -1,7 +1,7 @@
DNS Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT IBM
Expires: November 1999 May 1999
Expires: April 2000 October 1999
draft-ietf-dnsind-tkey-01.txt
Secret Key Establishment for DNS (TKEY RR)
@ -13,7 +13,7 @@ Expires: November 1999 May 1999
Status of This Document
This draft, file name draft-ietf-dnsind-tkey-00.txt, is intended to
This draft, file name draft-ietf-dnsind-tkey-01.txt, is intended to
be become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the DNS working group mailing
list <namedroppers@internic.net> or to the author.
@ -36,12 +36,6 @@ Status of This Document
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
@ -62,7 +56,7 @@ Status of This Document
Donald E. Eastlake, 3rd [Page 1]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
Abstract
@ -83,11 +77,11 @@ Acknowledgments
in alphabetic order) have been incorporated herein and are gratefully
acknowledged:
Olafur Gudmundsson <ogud@tislabs.com>
Stuart Kwan <skwan@microsoft.com>
Olafur Gudmundsson
Stuart Kwan
Brian Wellington
@ -120,7 +114,7 @@ Acknowledgments
Donald E. Eastlake, 3rd [Page 2]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
Table of Contents
@ -135,27 +129,27 @@ Table of Contents
1. Introduction............................................4
1.1 General Principles.....................................4
1.2 Overview of Contents...................................5
2. The TKEY Resource Record................................5
2. The TKEY Resource Record................................6
3. Exchange via Resolver Query.............................7
3.1 Query for Server Assigned Keying.......................8
3.2 Query for Diffie-Hellman Exchanged Keying..............9
3.3 Query for GSS-API Established..........................9
4. Spontaneous Server Inclusion...........................10
4.1 Spontaneous Server Assigned Keying....................10
4.2 Spontaneous Diffie-Hellman Keying.....................10
4.3 Spontaneous GSS-API Exchange..........................11
4.4 Spontaneous Key Deletion..............................11
5. TKEY Dynamic Update Requests...........................11
5.1 Exchange via TKEY 'Add'...............................11
5.2 TKEY Deletion.........................................12
6. Methods of Encryption..................................12
7. IANA Considerations....................................13
8. Security Considerations................................13
3.3 Query for GSS-API Established.........................10
3.4 Query for Querier Assigned Keying.....................10
3.5 Query for TKEY Deletion...............................11
4. Spontaneous Server Inclusion...........................11
4.1 Spontaneous GSS-API Exchange..........................11
4.2 Spontaneous Key Deletion..............................12
5. Methods of Encryption..................................12
6. IANA Considerations....................................12
7. Security Considerations................................13
References................................................14
Changes from Previous Draft...............................14
References................................................15
Author's Address..........................................16
Expiration and File Name..................................16
Author's Address..........................................15
Expiration and File Name..................................15
@ -178,7 +172,7 @@ Table of Contents
Donald E. Eastlake, 3rd [Page 3]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
1. Introduction
@ -187,7 +181,8 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
available database used for mapping between domain names and
addresses, for email routing, and for other information [RFC 1034,
1035]. It has been extended to provide for public key security and
dynamic update [RFC 2136, RFC 2535].
dynamic update [RFC 2136, RFC 2535]. Familiarity with these RFCs is
assumed.
[draft-ietf-dnsind-tsig-*.txt] provides a means of more efficiently
authenticating and securing DNS messages using shared secret keys via
@ -211,8 +206,9 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
requires that state be maintained at both the resolver and the server
and the allocation of the resources to maintain such state may
require mutual agreement. In the absence of such agreement, servers
are free to return errors for any attempt to use TKEY and resolvers
are free to ignore any TKEY RRs they receive.
are free to return errors such as NotImp or Refused for any attempt
to use TKEY and resolvers are free to ignore any TKEY RRs they
receive.
In all cases herein, the term "resolver" includes that part of a
server which makes full and incremental [RFC 1995] zone transfer
@ -220,33 +216,54 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
Servers are not required to implement any particular mode or modes of
the defined modes of TKEY shared secret key establishment or deletion
and may return errors for any they do not support. Based on
experience, in the future more modes may be added or some modes
described herein may be deprecated.
and may return errors such as NotImp for any they do not support. In
the future, based on experience, more modes may be added or some
modes described herein may be made mandatory or deprecated.
The means by which the shared secret keying material, exchanged via
TKEY, is actually used in any particular TSIG algorithm is algorithm
dependent and is defined in connection with that algorithm.
Note that this keying material and TSIGs that use it are associated
with DNS hosts. They are not tied to zones. They may be used to
authenticate queries and responses but they do not provide zone
Note that TKEY established keying material and TSIGs that use it are
Donald E. Eastlake, 3rd [Page 4]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
stored DNS data origin authentication [RFC 2535].
associated with DNS hosts. They are not necessairly associated with
zones. They may be used to authenticate queries and responses but
they do not provide zone stored DNS data origin or denial
authentication [RFC 2535].
Two modes of TKEY, the server assigned and resolver assigned modes,
perform encryption which may effect their export or
import status for some countries. All other aspects of DNS security,
including the SIG, KEY, NXT, and TSIG RRs and all other defined modes
of TKEY perform authentication (signatures and signature
verification) only.
including the SIG, KEY, NXT, and TSIG RRs and all other currently
defined modes of TKEY perform authentication (signatures and
signature verification) only.
General protection against denial of service via the use of TKEY is
not provided.
Only one TKEY RR may occur in a queryr or response. Between any pair
of hosts, only one set of keying material may be in place at the same
time for any particulary key name. An attempt to establish another
set of keying material at a server for an existing name should return
a BADNAME error.
A reasonable key naming strategy is as follows:
If the key is generated as the result of a query with root as
its owner name, they the server can create a name consisting of
a hash of the key plus the server host name. For example
89n3mdg072pp.host.example.com.
If the key is generated as the result of a query with a non-root
name, say foo.example.net, the use the concatenation of that
with the server host name. For example
foo.example.net.host.example.com.
@ -255,25 +272,28 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
Section 2 below specifies the TKEY resource record (RR) and provides
a high level description of its constituent fields.
Section 3 discusses key exchange via queries for type TKEY. This is
applicable to the server assigned, Diffie-Hellman exchange, and GSS-
API establishment modes.
Section 3 discusses key exchange via requests with the Query opcode
for type TKEY. This is applicable to all currently defined TKEY
modes and in some cases in not what would intuitively be called a
"query".
Section 4 discusses spontaneous inclusion of TKEY RRs in responses by
servers. This is applicable to key deletion and to server assigned
and Diffie-Hellman exchange key establishment.
modes.
Section 5 discusses use of dynamic update requests for type TKEY.
This supports optional key exchange via resolver update request,
which is applicable to key deletion and to the resolver assigned
mode.
Section 6 describes encryption methods for transmitting secret key
Section 5 describes encryption methods for transmitting secret key
information.
Section 7 covers IANA considerations in assignment of TKEY modes.
Finally, Section 8 touches on some security considerations.
Donald E. Eastlake, 3rd [Page 5]
INTERNET-DRAFT The DNS TKEY RR October 19999
Section 6 covers IANA considerations in assignment of TKEY modes.
Finally, Section 7 touches on some security considerations.
@ -282,21 +302,6 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
The TKEY resource record (RR) has the structure given below. Its RR
type code is 249.
Donald E. Eastlake, 3rd [Page 5]
INTERNET-DRAFT The DNS TKEY RR May 1999
Field Type Comment
----- ---- -------
@ -332,29 +337,22 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
DNS resolver to a DNS server where these fields are meaningful, they
are either the requested validity interval for the keying material
asked for or specify the validity interval of keying material
provided. To avoid replay attacks, to keying material used to
authenticate TKEY keying material MUST NOT have a lifetime of more
then 2**31 seconds. This applies to keying material used in either a
TSIG or a SIG(0) transaction or request signature.
The mode field specifies the general scheme for key agreement. Note
that implementation of TKEY as a whole and of any particular mode is
optional. The following values of the Mode octet are defined or
reserved:
provided. See Security Considerations section in reference to replay
attacks.
The mode field specifies the general scheme for key agreement or
Donald E. Eastlake, 3rd [Page 6]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
purpose of the TKEY DNS message. Note that implementation of TKEY as
a whole and of any particular mode is optional. The following values
of the Mode octet are defined, available, or reserved:
Value Description
----- -----------
0 - reserved
@ -389,50 +387,45 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
3. Exchange via Resolver Query
One method for a resolver and a server to establish a shared secret
key for use in TSIG is through queries from the resolver for type
TKEY. Such queries MUST either be accompanied by one or more TKEY
RRs in the additional information section to indicate the mode(s) in
use and other information where required or the resolver and server
must have a prior agreement that supplies any information that would
otherwise have had to be conveyed by TKEY RR(s) in the query.
One method for a resolver and a server to negotiate about shared
secret key for use in TSIG is through DNS requests from the resolver
which are syntactically queries for type TKEY. Such queries MUST be
accompanied by a TKEY RR in the additional information section to
indicate the mode in use and other information where required or the
resolver and server must have a prior agreement that supplies any
information that would otherwise have had to be conveyed by a TKEY RR
in the query.
For TKEY(s) appearing in a query, the TKEY RR name SHOULD be a domain
locally unique at the resolver (or globally unique), less than 128
octets long, and meaningful to the resolver to distinguish keys
and/or key agreement sessions. (For resolvers not wishing to make
this use of the name, it may be specified as root to minimize
length.) For TKEY(s) appearing in a response to a query, the TKEY RR
name SHOULD be a globally unique server assigned domain. If the TKEY
in a response is the result of a query containing a TKEY with a non-
Donald E. Eastlake, 3rd [Page 7]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
root name, that query TKEY name SHOULD be incorporated as the prefix
of the response TKEY name.
and/or key agreement sessions. (For resolvers not wishing to make
this use of the name, it may be specified as root to minimize
length.) For TKEY(s) appearing in a response to a query, the TKEY RR
name SHOULD be a globally unique server assigned domain. If the TKEY
in a response is the result of a query containing a TKEY with a non-
root name, that query TKEY name SHOULD be incorporated in the
response TKEY name. Specific suggestions are given under some modes
below.
Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
ignore the recursive header bit in TKEY queries they receive.
For every mode defined below, the inception and expiration times in a
query TKEY are set to the time interval for which the resolver wishes
the requested key to be valid and they are set in a successful
response to the actual time interval during which the server will
consider the key valid. Future modes may be defined which ignore the
inception and expiration time fields.
3.1 Query for Server Assigned Keying
In server assigned keying, the DNS server host generates the keying
material and it is sent to the resolver encrypted under a resolver
host key. See section 6 for description of encryption methods.
host key. See section 5 for description of encryption methods.
A resolver sends a query for type TKEY accompanied by a TKEY RR
specifying the "server assignment" mode and a resolver host KEY RR to
@ -459,21 +452,32 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
require such a query to be signed and MAY rate limit responses.
The server response contains a TKEY in its answer section with the
server assigned mode. If the error field is non-zero, the query
failed for the reason given. If the error field is zero, the KEY RR
provided in the query will be echoed back and the key data portion of
the response TKEY RR will be the server assigned keying data
server assigned mode and echoes back the KEY RR provided in the query
in its additional information section
If the error field of the response TKEY is non-zero, the query failed
for the reason given. FORMERR is given if the query specified no
Donald E. Eastlake, 3rd [Page 8]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
encrypted under the public key in the resolver provided KEY RR. The
name of the TKEY RR will be the server assigned name of the key and
SHOULD be globally unique.
encryption key.
If the error field is zero, the key data portion of the response TKEY
RR will be the server assigned keying data encrypted under the public
key in the resolver provided KEY RR. In this case, the name of the
answer TKEY RR will be the server assigned name of the key and SHOULD
be globally unique.
The inception and expiry times in the query TKEY are those requested
for the keying material. The inception and expiry times in the
response TKEY are the maximum period the server will consider the
keying material valid. Servers may pre-expire keys so this is not a
guarantee.
@ -488,8 +492,8 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
additional information section specifying the "Diffie-Hellman" mode
and accompanied by a KEY RR specifying a client host Diffie-Hellman
key. The TKEY algorithm field is set to the signature algorithm the
resolver plans to use and any "key data" provided in the TKEY is
ignored by the server.
resolver plans to use. Any "key data" provided in the TKEY is ignored
by the server.
Accepting and responding to an unsigned query of this sort may use
significant computation at the server; however, if the server
@ -500,15 +504,30 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
The server response contains a TKEY in its answer section with the
Diffie-Hellman mode. If the error field is non-zero, the query failed
for the reason given. If the error field is zero, the client host
supplied Diffie-Hellman KEY should be echoed back and a server host
Diffie-Hellman KEY RR will also be present in the response.
for the reason given. FORMERR is given if the query included no DH
KEY and BADKEY is given if the query included an incompatible DH KEY.
If the error field is zero, the client host supplied Diffie-Hellman
KEY should be echoed back and a server host Diffie-Hellman KEY RR
will also be present in the response.
Both parties can then calculate the same shared secret quantity from
the pair of Diffie-Hellman keys used [Schneier] provided they use the
same modulus. If the server host does not have an appropriate
Diffie-Hellman key to use for the exchange, it should return the
BADKEY error.
the pair of Diffie-Hellman keys used [Schneier], provided they use
the same modulus, and the data in the TKEY. The TKEY data is
strongly mixed with the DH result by TBD.
Donald E. Eastlake, 3rd [Page 9]
INTERNET-DRAFT The DNS TKEY RR October 19999
The inception and expiry times in the query TKEY are those requested
for the keying material. The inception and expiry times in the
response TKEY are the maximum period the server will consider the
keying material valid. Servers may pre-expire keys so this is not a
guarantee.
@ -521,14 +540,6 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
additional information section and a GSS-API token in the key data
portion. The server responds with a TKEY specifying the GSS-API mode
and a GSS-API token in the key data portion. The resolver and server
Donald E. Eastlake, 3rd [Page 9]
INTERNET-DRAFT The DNS TKEY RR May 1999
feed these tokens to their local GSS implementation and iterate until
an error is encountered or a key (GSS-API session) is established. A
similar exchange can be used to delete a GSS-API session.
@ -539,55 +550,73 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
query and response MAY be, but do not need to be, signed with TSIG
or SIG(0).
4. Spontaneous Server Inclusion
A DNS server may include TKEY RRs spontaneously as additional
information in responses. This SHOULD only be done if the server
knows the querier understands TKEY and has this option implemented.
This technique can be used to establish a server assigned key, a
Diffie-Hellman exchange key, for GSS-API exchange, and to delete a
key. A disadvantage of this technique is that there is no way for
the server to get any immediate error or success indication back and,
in the case of UDP, no way to even know if the DNS response reached
the resolver.
The inception and expiry time in a GSS-API mode TKEY are ignored.
4.1 Spontaneous Server Assigned Keying
3.4 Query for Querier Assigned Keying
A server can include in the additional information section of a
response a server assignment mode TKEY with encrypted keying material
in its key data section along with a KEY RR specifying the client
public key used for the encryption. Such a response SHOULD be signed
but the KEY RR need not be signed by a SIG(KEY). A server should
only do this if there is sufficient room in a query and it has reason
to believe the resolver will understand such additional data. The
KEY RR used MUST be one for which it is believed that the resolver
host has the corresponding private key or it will not be able to
decrypt the keying material.
Optionally, a server can accept resolver assigned keys. The keying
material must be encrypted under a server host key for protection in
transmission as described in Section 5.
The resolver sends an update request to add a TKEY RR that specifies
the keying data with a KEY RR in the additional information section
specifying the server host public key used to encrypt the data. The
name of the key and the keying data are completely controlled by the
sending resolver so a globally unique key name SHOULD be used. The
server SHOULD require that this request be signed with a TSIG, if
there already exists an appropriate shared secret, or a SIG(0) by the
resolver host. The KEY RR used MUST be one for which the server has
the corresponding private key or it will not be able to decrypt the
keying material and will return a FORMERR.
4.2 Spontaneous Diffie-Hellman Keying
A server can include in the additional information section of a
response a Diffie-Hellman exchange mode TKEY along with two KEY RRs
specifying the client and server host public keys used for the
exchange. Such a response SHOULD be signed but the KEY RRs need not
be signed by a SIG(KEY). A server should only do this if there is
sufficient room in a query and it has reason to believe the resolver
host will understand such additional data.
The query TKEY inception and expiry give the time period the querier
intends to consider the keying material valid. The server can return
Donald E. Eastlake, 3rd [Page 10]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
4.3 Spontaneous GSS-API Exchange
a lesser time interval to advise that it will not maintain state for
that long.
3.5 Query for TKEY Deletion
Keys established via TKEY can be treated as soft state. Since DNS
transactions are originated by the resolver, the resolver can simply
toss keys, although it may have to go through another key exchange if
it later needs one. Similarly, the server can discard keys although
that will result in an error on receiving a query with a TSIG using
the discarded key.
The key expiration provided in the TKEY and the ability of each party
to discard keys may be adequate but servers may implement key
deletion whereby the server discards a key on receipt from a resolver
of a delete request for a TKEY with the key's name. If the server
has no record of a key with that name, it returns BADNAME.
4. Spontaneous Server Inclusion
A DNS server may include a TKEY RR spontaneously as additional
information in responses. This SHOULD only be done if the server
knows the querier understands TKEY and has this option implemented.
This technique can be used for GSS-API exchange, and to delete a key.
A disadvantage of this technique is that there is no way for the
server to get any immediate error or success indication back and, in
the case of UDP, no way to even know if the DNS response reached the
resolver.
4.1 Spontaneous GSS-API Exchange
A server can spontaneously include in the additional information
section of a response, a GSS-API mode TKEY. The information in the
@ -602,88 +631,39 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
4.4 Spontaneous Key Deletion
A server can hint to a client that it has deleted a symmetric key by
spontaneously including a TKEY RR in the additional information
section of a response with the key's name and specifying the key
deletion mode. Such a response SHOULD be signed. If authenticated,
it deletes all keys with the given name whose effective time period
overlaps the inception to expiration period given in the deletion
mode TKEY. (If the inception time of one symmetric key is equal to
the expiration time of another, or vice versa, they do not overlap.)
Failure by a client to receive or properly process such additional
information in a response would simply mean that the client might use
a key that the server had discarded and then get an error indication.
5. TKEY Dynamic Update Requests
If a DNS server supports dynamic update [RFC 2136], then dynamic
update request can be used to exchange resolver assigned symmetric
keys as described in section 5.1 below and to delete previously
exchanged keys from a server as described in section 5.2 below.
5.1 Exchange via TKEY 'Add'
Optionally, a server can accept resolver assigned keys. The keying
material must be encrypted under a server host key for protection in
transmission as described in Section 6.
The resolver sends an update request to add a TKEY RR that specifies
the keying data with a KEY RR in the additional information section
specifying the server host public key used to encrypt the data. The
name of the key and the keying data are completely controlled by the
Donald E. Eastlake, 3rd [Page 11]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
sending resolver so a globally unique key name SHOULD be used. The
server SHOULD require that this request be signed with a TSIG, if
there already exists an appropriate shared secret, or a SIG(0) by the
resolver host. The KEY RR used MUST be one for which the server has
the corresponding private key or it will not be able to decrypt the
keying material.
4.2 Spontaneous Key Deletion
A server can hint to a client that it has deleted a symmetric key by
spontaneously including a TKEY RR in the additional information
section of a response with the key's name and specifying the key
deletion mode. Such a response SHOULD be signed. If authenticated,
it deletes the key with the given name. The inception and expiry
times of the delete TKEY are ignored. Failure by a client to receive
or properly process such additional information in a response would
simply mean that the client might use a key that the server had
discarded and then get an error indication.
5.2 TKEY Deletion
Keys established via TKEY can be treated as soft state. Since DNS
transactions are originated by the resolver, the resolver can simply
toss keys, although it may have to go through another key exchange if
it later needs one. Similarly, the server can discard keys although
that will result in an error on receiving a query with a TSIG using
the discarded key.
The key expiration provided in the TKEY and the ability of each party
to discard keys may be adequate but servers that support dynamic
update [RFC 2136] may optionally implement key deletion whereby the
server discards a key on receipt from a resolver of a delete request
for a TKEY with the key's name. The mode and most fields of the TKEY
being "deleted" are ignored. But, to allow for the possibility of
multiple keys with the same name but different time periods, the only
keys deleted are those whose time period overlaps with that specified
by the inception and expiration in the TKEY being "deleted".
6. Methods of Encryption
5. Methods of Encryption
For the server assigned and resolver assigned key exchange, the
keying material is sent within the key data field of a TKEY RR
encrypted under the private key corresponding to the public key in an
accompanying KEY RR [RFC 2535]. The secret keying material being
send will generally be fairly short, usually less than 256 bits,
because that is adequate for very strong protection with modern keyed
hash or symmetric algorithms.
encrypted under the public key in an accompanying KEY RR [RFC 2535].
The KEY RR MUST correspond to a name for the destination host such
that the destination host has the corresponding private key to
decrypt the data. The secret keying material being send will
generally be fairly short, usually less than 256 bits, because that
is adequate for very strong protection with modern keyed hash or
symmetric algorithms.
If the KEY RR specifies the RSA algorithm, then the keying material
is encrypted as per the description of RSA encryption in PKCS#1 [RFC
@ -695,34 +675,33 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
block is clear from the public RSA key specified and the PKCS#1
padding makes it clear what part of the encrypted data is actually
keying material and what part is formatting or the required at least
eight bytes of random [RFC 1750] padding.
6. IANA Considerations
This section is to be interpreted as provided in [RFC 2434].
Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF
can only be assigned by an IETF standards action (and 1 through 5 are
assigned by this Proposed Standard). Special consideration should be
given before the allocation of meaning for Mode field values 0x0000
and 0xFFFF.
Donald E. Eastlake, 3rd [Page 12]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
eight bytes of random [RFC 1750] padding.
7. IANA Considerations
This section is to be interpreted as provided in [RFC 2434].
Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF
can only be assigned by an IETF standards action excluding
Experimental Standards (and 1 through 5 are assigned by this Proposed
Standard). Special consideration should be given before the
allocation of meaning for Mode field values 0x0000 and 0xFFFF.
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
are allocated by an IETF consensus excluding Experimental Standards.
are allocated by an IETF consensus.
Mode field values 0x1000 through 0xEFFF are allocated based on RFC
documentation of their use or the issuance of an Experimental
Standard.
documentation of their use.
Mode values should not be changed when the status of their use
changes. I.E. a mode value assigned for an Experimental Standard
@ -731,7 +710,7 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
8. Security Considerations
7. Security Considerations
To avoid different interpretations of the inception and expiration
times in TKEY RRs, resolvers and servers exchanging them must have
@ -739,7 +718,8 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
NTP protocol [RFC 2030] but that or any other time synchronization
MUST be done securely.
It is recommended that the server require TKEY queries be signed.
TKEY queries SHOULD be signed and those using the querier
establishment mode MUST be signed to authenticate their origin.
However, for currently defined modes, relatively little damage will
be done if an unsigned query of this sort is accepted and processed,
as described above, for each mode. In addition, requiring that a TKEY
@ -748,17 +728,89 @@ INTERNET-DRAFT The DNS TKEY RR May 1999
computational requirements on the server, particularly in verifying
SIG(0) public key signatures.
Responses to TKEY queries SHOULD always have DNS transaction
signatures to protect the integrity of any keying data, error codes,
etc. This signature, if present, MUST use a previously established
secret (TSIG) or public (SIG(0)) key and MUST NOT use any key that
the response to be verified is itself providing.
Responses to TKEY queries MUST always have DNS transaction signatures
to protect the integrity of any keying data, error codes, etc. This
signature MUST use a previously established secret (TSIG) or public
(SIG(0)) key and MUST NOT use any key that the response to be
verified is itself providing.
To avoid replay attacks, it is necessary that a response or querier
establishment mode query involving TKEY not be valid if replayed on
the order of 2**32 second (about 136 years) later. To acomplish
this, the keying material used in any TSIG or SIG(0) RR that
authenticates a TKEY message MUST NOT have a lifetime of more then
2**31 - 1 seconds. Thus, on attempted replay, the authenticating
TSIG or SIG(0) RR will not be verifyable due to key expiration and
the replay will fail.
Donald E. Eastlake, 3rd [Page 13]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
Changes from Previous Draft
Prohibit more than one TKEY in a request or response. Prohibit more
than one key with the same name (even if they have non-overlapping
validity periods).
Spontaneous server inclusion of Diffi-Hellman TKEYs and server
assigned key have been eliminated.
"Update" opcode TKEY operations have all been moved to the "Query"
opcode even if they are not something you would naturally think of as
a query.
Error codes for more error conditions listed explicitly.
More explicit TKEY key naming suggestions.
Donald E. Eastlake, 3rd [Page 14]
INTERNET-DRAFT The DNS TKEY RR October 19999
References
@ -813,10 +865,10 @@ References
Donald E. Eastlake, 3rd [Page 14]
Donald E. Eastlake, 3rd [Page 15]
INTERNET-DRAFT The DNS TKEY RR May 1999
INTERNET-DRAFT The DNS TKEY RR October 19999
Author's Address
@ -835,9 +887,9 @@ Author's Address
Expiration and File Name
This draft expires November 1999.
This draft expires October 1999.
Its file name is draft-ietf-dnsind-tkey-00.txt.
Its file name is draft-ietf-dnsind-tkey-01.txt.
@ -871,5 +923,5 @@ Expiration and File Name
Donald E. Eastlake, 3rd [Page 15]
Donald E. Eastlake, 3rd [Page 16]