From d8eee1b955e3637b2b8f19f7937e40bcc0d3eaa7 Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Mon, 8 Nov 1999 19:04:51 +0000 Subject: [PATCH] added and updated some drafts --- ...02.txt => draft-ietf-dnsind-apl-rr-03.txt} | 132 ++- doc/draft/draft-ietf-dnsind-iana-dns-00.txt | 755 -------------- doc/draft/draft-ietf-dnsind-iana-dns-02.txt | 927 ++++++++++++++++++ doc/draft/draft-ietf-dnsind-sigalgopt-00.txt | 164 ++++ ...y-00.txt => draft-ietf-dnsind-tkey-01.txt} | 594 ++++++----- 5 files changed, 1495 insertions(+), 1077 deletions(-) rename doc/draft/{draft-ietf-dnsind-apl-rr-02.txt => draft-ietf-dnsind-apl-rr-03.txt} (69%) delete mode 100644 doc/draft/draft-ietf-dnsind-iana-dns-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-iana-dns-02.txt create mode 100644 doc/draft/draft-ietf-dnsind-sigalgopt-00.txt rename doc/draft/{draft-ietf-dnsind-tkey-00.txt => draft-ietf-dnsind-tkey-01.txt} (65%) diff --git a/doc/draft/draft-ietf-dnsind-apl-rr-02.txt b/doc/draft/draft-ietf-dnsind-apl-rr-03.txt similarity index 69% rename from doc/draft/draft-ietf-dnsind-apl-rr-02.txt rename to doc/draft/draft-ietf-dnsind-apl-rr-03.txt index d908bcf8e1..d6c3e5392d 100644 --- a/doc/draft/draft-ietf-dnsind-apl-rr-02.txt +++ b/doc/draft/draft-ietf-dnsind-apl-rr-03.txt @@ -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: - IN APL {[!]address/prefix}* + IN 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 , 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 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
part of an follows [RFC2373], section 2.2. Legal values for - -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 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", - , 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)", , 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 -Koch Expires December 1999 [Page 6] +Koch Expires April 2000 [Page 6] diff --git a/doc/draft/draft-ietf-dnsind-iana-dns-00.txt b/doc/draft/draft-ietf-dnsind-iana-dns-00.txt deleted file mode 100644 index 345c11ad26..0000000000 --- a/doc/draft/draft-ietf-dnsind-iana-dns-00.txt +++ /dev/null @@ -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 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 . - - - - - - - - - - - - - - - - - - - - -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 . - - 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 - ... - - -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 . - - 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 . 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] - - - - - -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] - diff --git a/doc/draft/draft-ietf-dnsind-iana-dns-02.txt b/doc/draft/draft-ietf-dnsind-iana-dns-02.txt new file mode 100644 index 0000000000..901f50487d --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-iana-dns-02.txt @@ -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 is + unlimited. Comments should be sent to the DNS Working Group mailing + list 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 + . + + 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", + . + + [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, + + [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] + diff --git a/doc/draft/draft-ietf-dnsind-sigalgopt-00.txt b/doc/draft/draft-ietf-dnsind-sigalgopt-00.txt new file mode 100644 index 0000000000..c27dd9891c --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-sigalgopt-00.txt @@ -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 + + + The list of Internet-Draft Shadow Directories can be accessed at + + + 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] diff --git a/doc/draft/draft-ietf-dnsind-tkey-00.txt b/doc/draft/draft-ietf-dnsind-tkey-01.txt similarity index 65% rename from doc/draft/draft-ietf-dnsind-tkey-00.txt rename to doc/draft/draft-ietf-dnsind-tkey-01.txt index 1f31086b74..fca82a8435 100644 --- a/doc/draft/draft-ietf-dnsind-tkey-00.txt +++ b/doc/draft/draft-ietf-dnsind-tkey-01.txt @@ -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 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 - - Stuart Kwan + 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]