From 15e26d11c8bfd345f79cc972ca5c0aedcaee5982 Mon Sep 17 00:00:00 2001 From: Bob Halley Date: Wed, 8 Sep 1999 18:25:34 +0000 Subject: [PATCH] update --- ...01.txt => draft-ietf-dnsind-apl-rr-02.txt} | 190 ++--- ...-02.txt => draft-ietf-dnsind-edns1-03.txt} | 153 +--- doc/draft/draft-ietf-dnsind-iana-dns-00.txt | 755 ++++++++++++++++++ ...raft-ietf-dnsind-local-compression-05.txt} | 121 ++- ...t => draft-ietf-dnsind-local-names-07.txt} | 580 ++++++-------- ...g-08.txt => draft-ietf-dnsind-tsig-11.txt} | 390 +++------ doc/draft/draft-skwan-gss-tsig-04.txt | 599 ++++++++++++++ 7 files changed, 1861 insertions(+), 927 deletions(-) rename doc/draft/{draft-ietf-dnsind-apl-rr-01.txt => draft-ietf-dnsind-apl-rr-02.txt} (71%) rename doc/draft/{draft-ietf-dnsind-edns1-02.txt => draft-ietf-dnsind-edns1-03.txt} (83%) create mode 100644 doc/draft/draft-ietf-dnsind-iana-dns-00.txt rename doc/draft/{draft-ietf-dnsind-local-compression-04.txt => draft-ietf-dnsind-local-compression-05.txt} (87%) rename doc/draft/{draft-ietf-dnsind-local-names-06.txt => draft-ietf-dnsind-local-names-07.txt} (61%) rename doc/draft/{draft-ietf-dnsind-tsig-08.txt => draft-ietf-dnsind-tsig-11.txt} (79%) create mode 100644 doc/draft/draft-skwan-gss-tsig-04.txt diff --git a/doc/draft/draft-ietf-dnsind-apl-rr-01.txt b/doc/draft/draft-ietf-dnsind-apl-rr-02.txt similarity index 71% rename from doc/draft/draft-ietf-dnsind-apl-rr-01.txt rename to doc/draft/draft-ietf-dnsind-apl-rr-02.txt index 0aeaf3e448..d908bcf8e1 100644 --- a/doc/draft/draft-ietf-dnsind-apl-rr-01.txt +++ b/doc/draft/draft-ietf-dnsind-apl-rr-02.txt @@ -1,12 +1,9 @@ - - INTERNET-DRAFT Peter Koch -Expires: August 1999 Universitaet Bielefeld -Updates: RFC 1035 February 1999 - - A DNS RR Type for Lists of IP Address Prefixes (APL RR) - draft-ietf-dnsind-apl-rr-01.txt +Expires: December 1999 Universitaet Bielefeld +Updates: RFC 1035 June 1999 + A DNS RR Type for Lists of Address Prefixes (APL RR) + draft-ietf-dnsind-apl-rr-02.txt Status of this Memo @@ -36,7 +33,7 @@ Abstract The Domain Name System is primarily used to translate domain names into IPv4 addresses using A RRs. Several approaches exist to describe - networks or address ranges. This document proposes a new DNS RR type + networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists. 1. Conventions used in this document @@ -46,15 +43,11 @@ Abstract document are to be interpreted as described in [RFC2119]. Domain names herein are for explanatory purposes only and should not - be expected to lead to useful information in real life [TESTTLD]. + be expected to lead to useful information in real life [RFC2606]. +Koch Expires December 1999 [Page 1] - - -Koch Expires August 1999 [Page 1] - -INTERNET-DRAFT DNS APL RR February 1999 - +INTERNET-DRAFT DNS APL RR June 1999 2. Background @@ -67,7 +60,7 @@ INTERNET-DRAFT DNS APL RR February 1999 older BIND versions, a weak form of controlling access to zone data was implemented using TXT RRs describing address ranges. - This document proposes a new RR type for address prefix lists. + This document specifies a new RR type for address prefix lists. 3. APL RR Type @@ -83,63 +76,55 @@ INTERNET-DRAFT DNS APL RR February 1999 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ADDRESSFAMILY | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - | N | PREFIX | MBZ | AFDLENGTH | + | PREFIX | N | AFDLENGTH | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ / AFDPART / | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - ADDRESSFAMILY 16 bit unsigned value as assigned by IANA (see IANA Considerations) + PREFIX 8 bit unsigned binary coded prefix length. + Upper and lower bounds and interpretation of + this value are address family specific. N negation flag, indicates the presence of the "!" character in the textual format. It has the value "1" if the "!" was given, "0" else. - PREFIX binary coded prefix length. Upper and lower - bounds and interpretation of this value are - address family specific. - MBZ reserved, must be zero AFDLENGTH length in octets of the following address - family dependent part. This is to deal with - yet undefined address families and variable - length addresses. - - - - -Koch Expires August 1999 [Page 2] - -INTERNET-DRAFT DNS APL RR February 1999 - - + family dependent part (7 bit unsigned). AFDPART address family dependent part. See below. - This document defines the AFDPARTs for address families 1 (IPv4) and + +Koch Expires December 1999 [Page 2] + +INTERNET-DRAFT DNS APL RR June 1999 + 2 (IPv6). Future revisions may deal with additional address families. 4.1. AFDPART for IPv4 The encoding of an IPv4 address (address family 1) follows the - encoding specified for the A RR by [RFC1035], section 3.4.1. + encoding specified for the A RR by [RFC1035], section 3.4.1. Trailing + zero octets MUST be ignored, regardless of the prefix length. PREFIX specifies the number of bits of the IPv4 address starting at - the most significant bit. Legal encodings range from 0 (1 bit) to 31 - (32 bit, complete address). + the most significant bit. Legal values range from 0 to 32. - An IPv4 AFDPART has a fixed length of 4 octets. + An IPv4 AFDPART has a variable length of 0 to 4 octets. -4.1. AFDPART for IPv6 +4.2. AFDPART for IPv6 The encoding of an IPv6 address (address family 2) follows the - encoding specified for the AAAA RR by [RFC1886], section 2.2. + specification for the AAAA RR in [RFC1886], section 2.2. The 128 bit + address is encoded in network byte order. Trailing zero octets MUST + be ignored, regardless of the prefix length. PREFIX specifies the number of bits of the IPv6 address starting at - the most significant bit. Legal encodings range from 0 (1 bit) to 127 - (128 bit, complete address). + the most significant bit. Legal values range from 0 to 128. - An IPv6 AFDPART has a fixed length of 16 octets. + An IPv6 AFDPART has a variable length of 0 to 16 octets. 5. Zone File Syntax @@ -157,28 +142,25 @@ INTERNET-DRAFT DNS APL RR February 1999 An IPv4 address in the
part of an is in dotted quad notation, just as in an A RR. The has values from the - interval 1..32 (decimal), corresponding to encodings 0..31. - -5.1. Textual Representation of IPv6 Addresses - - - -Koch Expires August 1999 [Page 3] - -INTERNET-DRAFT DNS APL RR February 1999 + interval 0..32 (decimal). +5.2. Textual Representation of IPv6 Addresses The representation of an IPv6 address in the
part of an follows [RFC2373], section 2.2. Legal values for - are from the interval 1..128 (decimal), corresponding to encodings - 0..127. + +Koch Expires December 1999 [Page 3] + +INTERNET-DRAFT DNS APL RR June 1999 + + are from the interval 0..128 (decimal). 6. APL RR usage An APL RR with empty RDATA is valid and implements an empty list. Multiple occurences of the same in a single APL RR are allowed and MUST NOT be merged by a DNS server or resolver. - must be kept in order and MUST NOT be rearranged or + MUST be kept in order and MUST NOT be rearranged or aggregated. A single APL RR may contain belonging to different @@ -196,34 +178,39 @@ INTERNET-DRAFT DNS APL RR February 1999 7. Examples + 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. + foo.example APL 192.168.32.0/21 !192.168.38.0/28 42.168.192.IN-ADDR.ARPA APL 192.168.42.0/26 192.168.42.64/26 \ 192.168.42.128/25 - _axfr_.sbo.example APL 127.0.0.1/32 172.16.64.0/22 + _axfr.sbo.example APL 127.0.0.1/32 172.16.64.0/22 multicast.example APL 224.0.0.0/4 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 Any information obtained from the DNS should be regarded as unsafe - unless techniques specified in [RFC2065] or [TSIGRR] were used. The + 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 - - -Koch Expires August 1999 [Page 4] - -INTERNET-DRAFT DNS APL RR February 1999 - - 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. @@ -235,10 +222,9 @@ INTERNET-DRAFT DNS APL RR February 1999 11. References - - [A6DNSRR] Crawford,M., Thomson,S., "DNS Extensions to Support IP - Version 6", , work - in progress + [A6DNSRR] Crawford,M., Huitema,C., Thomson,S., "DNS Extensions to + Support IPv6 Address Aggregation and Renumbering", + , work in progress [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", RFC 1034, STD 13, November 1987 @@ -252,9 +238,6 @@ INTERNET-DRAFT DNS APL RR February 1999 [RFC1886] Thomson,S., Huitema.,C., "DNS Extensions to support IP version 6", RFC 1886, December 1995 - [RFC2065] Eastlake,D., Kaufman,C. "Domain Name System Security - Extensions", RFC 2065, January 1997 - [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997 @@ -264,22 +247,20 @@ INTERNET-DRAFT DNS APL RR February 1999 [RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998 - [TESTTLD] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", - , work in progress + [RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC + 2535, March 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 - - - - -Koch Expires August 1999 [Page 5] - -INTERNET-DRAFT DNS APL RR February 1999 - - 12. Author's Address Peter Koch @@ -291,45 +272,4 @@ INTERNET-DRAFT DNS APL RR February 1999 +49 521 106 2902 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Koch Expires August 1999 [Page 6] - +Koch Expires December 1999 [Page 6] diff --git a/doc/draft/draft-ietf-dnsind-edns1-02.txt b/doc/draft/draft-ietf-dnsind-edns1-03.txt similarity index 83% rename from doc/draft/draft-ietf-dnsind-edns1-02.txt rename to doc/draft/draft-ietf-dnsind-edns1-03.txt index d6be78be77..b300eed20c 100644 --- a/doc/draft/draft-ietf-dnsind-edns1-02.txt +++ b/doc/draft/draft-ietf-dnsind-edns1-03.txt @@ -1,34 +1,29 @@ - - - - - DNSIND Working Group Paul Vixie INTERNET-DRAFT ISC - January, 1999 - + June, 1999 Extensions to DNS (EDNS1) - Status of this Memo - This document is an Internet-Draft. 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. + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' + material or to cite them other than as "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 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). + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. Abstract @@ -47,14 +42,9 @@ several new extended label types and message options, and the ability to ask multiple questions in a single request. + Expires December 1999 [Page 1] - - - - Expires July 1999 [Page 1] - - INTERNET-DRAFT EDNS1 January 1999 - + INTERNET-DRAFT EDNS1 June 1999 2 - Affected Protocol Elements @@ -95,19 +85,9 @@ 3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long local compression pointer'' as described in [KOCH98]. + Expires December 1999 [Page 2] - - - - - - - - - Expires July 1999 [Page 2] - - INTERNET-DRAFT EDNS1 January 1999 - + INTERNET-DRAFT EDNS1 June 1999 4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags are structured as follows: @@ -119,7 +99,6 @@ 2: |MD |FM |RRD|LM | Z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As defined by [EDNS0].) @@ -143,25 +122,27 @@ segments of a segmented message. It is an error for TC to be set on any message of a segmented message. Any given RR must fit completely within a message, and all - messages will both begin and end on RR boundaries. + messages will both begin and end on RR boundaries. Each + section in a multipart message must appear in normal + message order, and each section must be complete before + later sections are added. All segments of a message + must be transmitted contiguously, without interleaving + of other messages. FM ``First match'' flag. Notable only when multiple questions are present. If set in a request, questions will be processed in wire order and the first question whose answer would have NOERROR AND ANCOUNT>0 is treated + + Expires December 1999 [Page 3] + + INTERNET-DRAFT EDNS1 June 1999 + as if it were the only question in the query message. Otherwise, questions can be processed in any order and all possible answer records will be included in the response. Response FM should be ignored by requestors. - - - - Expires July 1999 [Page 3] - - INTERNET-DRAFT EDNS1 January 1999 - - RRD ``Recursion really desired'' flag. Notable only when a request is processed by an intermediate name server (``forwarder'') who is not authoritative for the zone @@ -200,21 +181,16 @@ Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. + Expires December 1999 [Page 4] + + INTERNET-DRAFT EDNS1 June 1999 + 5 - Multiple Questions for QUERY 5.1. If QDCOUNT>1, multiple questions are present. All questions must be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. - - - - - Expires July 1999 [Page 4] - - INTERNET-DRAFT EDNS1 January 1999 - - 5.2. RCODE and AA apply to all RRs in the answer section having the QNAME that is shared by all questions in the question section. AA applies to all matching answers, and will not be set unless the exact @@ -236,8 +212,8 @@ 6 - Acknowledgements Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, - Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Michael - Patton were each instrumental in creating this specification. + Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton, + and Michael Graff were each instrumental in creating this specification. 7 - References @@ -254,20 +230,13 @@ [KOCH98] P. Koch, ``A New Scheme for the Compression of Domain Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt. + + Expires December 1999 [Page 5] + + INTERNET-DRAFT EDNS1 June 1999 + IETF DNSIND, March 1998. - - - - - - - - Expires July 1999 [Page 5] - - INTERNET-DRAFT EDNS1 January 1999 - - 8 - Author's Address Paul Vixie @@ -275,46 +244,6 @@ 950 Charter Street Redwood City, CA 94063 +1 650 779 7001 - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Expires July 1999 [Page 6] - + Expires December 1999 [Page 6] diff --git a/doc/draft/draft-ietf-dnsind-iana-dns-00.txt b/doc/draft/draft-ietf-dnsind-iana-dns-00.txt new file mode 100644 index 0000000000..345c11ad26 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-iana-dns-00.txt @@ -0,0 +1,755 @@ +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-local-compression-04.txt b/doc/draft/draft-ietf-dnsind-local-compression-05.txt similarity index 87% rename from doc/draft/draft-ietf-dnsind-local-compression-04.txt rename to doc/draft/draft-ietf-dnsind-local-compression-05.txt index 08ac30f6ba..ec27e3ac77 100644 --- a/doc/draft/draft-ietf-dnsind-local-compression-04.txt +++ b/doc/draft/draft-ietf-dnsind-local-compression-05.txt @@ -1,14 +1,9 @@ - - - - INTERNET-DRAFT Peter Koch -Expires: August 1999 Universitaet Bielefeld -Updates: 1035, 1183, 2065, 2163, 2168 February 1999 +Expires: December 1999 Universitaet Bielefeld +Updates: 1035, 1183, 2163, 2168, 2535 June 1999 A New Scheme for the Compression of Domain Names - draft-ietf-dnsind-local-compression-04.txt - + draft-ietf-dnsind-local-compression-05.txt Status of this Memo @@ -51,18 +46,15 @@ Abstract The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +Koch Expires December 1999 [Page 1] - -Koch Expires August 1999 [Page 1] - -INTERNET-DRAFT DNS Compression February 1999 - +INTERNET-DRAFT DNS Compression June 1999 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Domain names herein are for explanatory purposes only and should not - be expected to lead to useful information in real life [TESTTLD]. + be expected to lead to useful information in real life [RFC2606]. 2. Background @@ -107,12 +99,9 @@ INTERNET-DRAFT DNS Compression February 1999 names in the RDATA section of "well known" RR types (those initially defined in [RFC1035]), there is no interoperable way of applying +Koch Expires December 1999 [Page 2] - -Koch Expires August 1999 [Page 2] - -INTERNET-DRAFT DNS Compression February 1999 - +INTERNET-DRAFT DNS Compression June 1999 compression to the RDATA section of newer RRs: @@ -163,12 +152,9 @@ INTERNET-DRAFT DNS Compression February 1999 number (starting at 0 for the topmost label, the TLD). This way we avoid the need for extra decompression of the owner name during +Koch Expires December 1999 [Page 3] - -Koch Expires August 1999 [Page 3] - -INTERNET-DRAFT DNS Compression February 1999 - +INTERNET-DRAFT DNS Compression June 1999 message composition or decomposition. @@ -194,7 +180,7 @@ Example section consisting of two domain names: ab.foo.example IN CNAME bar.example - bar.example IN XMPL ab.foo.example foo.example + bar.example IN XMPL a.foo.example foo.example In a message this appears as follows (randomly starting at octet 12): @@ -218,13 +204,9 @@ Example 10 octets skipped (TYPE, CLASS, TTL, RDLENGTH) +Koch Expires December 1999 [Page 4] - - -Koch Expires August 1999 [Page 4] - -INTERNET-DRAFT DNS Compression February 1999 - +INTERNET-DRAFT DNS Compression June 1999 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 38 | 3 | b | @@ -264,7 +246,7 @@ INTERNET-DRAFT DNS Compression February 1999 5. Interaction with DNSSEC - The security extensions to DNS [RFC2065] mandate that domain names in + The security extensions to DNS [RFC2535] mandate that domain names in RDATA be signed only in expanded, lower case format. For RR types using local compression the specification is changed as follows: @@ -275,12 +257,9 @@ INTERNET-DRAFT DNS Compression February 1999 This way RR type transparency can be achieved, since domain names in +Koch Expires December 1999 [Page 5] - -Koch Expires August 1999 [Page 5] - -INTERNET-DRAFT DNS Compression February 1999 - +INTERNET-DRAFT DNS Compression June 1999 the RDATA section are treated as arbitrary data and can be cached and verified by resolvers not aware of the particular RR type. Old RR @@ -292,6 +271,13 @@ INTERNET-DRAFT DNS Compression February 1999 be used to compress the RDATA part more efficiently, this MUST NOT be done. Otherwise signatures would be invalidated. + Currently slave servers store zones in text format and re-encode the + data into wire format, e.g. after a restart. This encoding must be + unique to ensure signature validity. To achieve this, local + compression MUST be applied optimally, i.e. every domain name must be + compressed as far as possible and each local compression pointer must + point to the earliest available target (including the owner). + 6. Interaction with Binary Labels When constructing local compression pointers into the owner name, @@ -311,7 +297,7 @@ INTERNET-DRAFT DNS Compression February 1999 introduction of binary labels a domain name can consist of up to 1904 labels (all one-bit labels). This document restricts the possible compression targets in an owner name to the topmost 255 labels. This - limit was chosen to be consistent with [DNSSEC], section 4.1. + limit was chosen to be consistent with [RFC2535], section 4.1.3. 7. Old RR types and deployment @@ -322,7 +308,12 @@ INTERNET-DRAFT DNS Compression February 1999 The following RR types with domain names in the RDATA section have been defined since [RFC1035] (Standards Track, Experimental and Informational RFCs, ignoring withdrawn types): RP [RFC1183], AFSDB - [RFC1183], RT [RFC1183], SIG [RFC2065], PX [RFC2163], NXT [RFC2065], + [RFC1183], RT [RFC1183], SIG [RFC2535], PX [RFC2163], NXT [RFC2535], + +Koch Expires December 1999 [Page 6] + +INTERNET-DRAFT DNS Compression June 1999 + SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230]. Some specifications do not mention DNS compression at all, others explicitly suggest it and only in part identify interoperability issues. Only the KX and SRV @@ -330,14 +321,6 @@ INTERNET-DRAFT DNS Compression February 1999 The specification of RP, AFSDB, RT, PX, and NAPTR is hereby changed in that domain names in the RDATA section MUST NOT be compressed and - - - -Koch Expires August 1999 [Page 6] - -INTERNET-DRAFT DNS Compression February 1999 - - MUST NOT be compression targets. Local compression MUST NOT be used for owner names and it MUST NOT be @@ -373,10 +356,13 @@ INTERNET-DRAFT DNS Compression February 1999 10. References - [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", RFC 1034, STD 13, November 1987 +Koch Expires December 1999 [Page 7] + +INTERNET-DRAFT DNS Compression June 1999 + [RFC1035] Mockapetris,P., "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 @@ -386,20 +372,9 @@ INTERNET-DRAFT DNS Compression February 1999 [RFC1183] Everhart,C., Mamakos,L., Ullmann,R., Mockapetris,P., "New DNS RR Definitions", RFC 1183, October 1990 - - - -Koch Expires August 1999 [Page 7] - -INTERNET-DRAFT DNS Compression February 1999 - - [RFC2052] Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996 - [RFC2065] Eastlake,D., Kaufman,C. "Domain Name System Security - Extensions" RFC 2065, January 1997 - [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997 @@ -414,17 +389,18 @@ INTERNET-DRAFT DNS Compression February 1999 [RFC2230] Atkinson,R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997 + [RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC + 2535, March 1999 + + [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", + RFC 2606, BCP 32, June 1999 + [EDNS0] Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft- ietf-dnsind-edns0-XX.txt, work in progress [BINLABELS] Crawford,M., "Binary Labels in the Domain Name System", draft-ietf-dnsind-binary-labels-XX.txt, work in progress - [TESTTLD] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", - , work in progress - - - 11. Author's Address Peter Koch @@ -433,17 +409,12 @@ INTERNET-DRAFT DNS Compression February 1999 Postfach 10 01 31 D-33501 Bielefeld Germany + +Koch Expires December 1999 [Page 8] + +INTERNET-DRAFT DNS Compression June 1999 + +49 521 106 2902 - - - - - - - - - -Koch Expires August 1999 [Page 8] - +Koch Expires December 1999 [Page 9] diff --git a/doc/draft/draft-ietf-dnsind-local-names-06.txt b/doc/draft/draft-ietf-dnsind-local-names-07.txt similarity index 61% rename from doc/draft/draft-ietf-dnsind-local-names-06.txt rename to doc/draft/draft-ietf-dnsind-local-names-07.txt index 15db52aa8b..63fcfcfb0e 100644 --- a/doc/draft/draft-ietf-dnsind-local-names-06.txt +++ b/doc/draft/draft-ietf-dnsind-local-names-07.txt @@ -1,12 +1,12 @@ +DNS Working Group Donald E. Eastlake, 3rd +INTERNET-DRAFT IBM +Expires December 1999 June 1999 -INTERNET-DRAFT Local Domain Names - November 1998 - Expires May 1999 +draft-ietf-dnsind-local-names-07.txt - - Local DNS Names - ----- --- ----- + Local Domain Name System (DNS) Names + ----- ------ ---- ------ ----- ----- Donald E. Eastlake 3rd @@ -14,12 +14,12 @@ INTERNET-DRAFT Local Domain Names Status of This Document - This draft, file name draft-ietf-dnsind-local-names-06.txt, is - intended to be become an Informational RFC. Distribution of this - document is unlimited. Comments should be sent to the DNS mailing - list or to the author. + This draft, file name draft-ietf-dnsind-local-names-07.txt. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list or to the author. - This document is an Internet-Draft. Internet-Drafts are working + 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. @@ -30,6 +30,12 @@ Status of This Document 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. + 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 @@ -40,26 +46,33 @@ Status of This Document Abstract - A set of second level domain names are defined under a new top level - domain name such that local private DNS zones can be maintained - similar to the private IP addresses reserved in [RFC 1918]. These - zone locally appear to be part of the global DNS name tree. - Additional second level domain names are assigned under this TLD for - loopback addresses and IPv6 link and site local addresses. + It is increasingly common for their to be "local" domain names which + are not intended to be seen from the global Internet. In some cases + this if for policy reasons, in other cases because they map to IP + addresses or other data which is only locally meaningful [RFC 1918, + 2373]. + + A new top level domain (TLD) name (.local) is reserved and a name + structure suggested below this TLD such that local private DNS zones + can safely be created without fear of conflict if these names should + leak out of a private enclave. It addition, a method of providing + DNS service for these names is suggested such that they are + maintained privately, similar to the reserved private IP addresses, - - - - - - -Donald E. Eastlake 3rd [Page 1] +D. Eastlake 3rd [Page 1] INTERNET-DRAFT Local DNS Names + yet locally appear to be part of the global DNS name tree and are + reachable by a local resolver with no special knowledge. Additional + second level domain names are assigned under this TLD for IPv6 link + and site local addresses and loopback functions. + + + Acknowledgments The valuable contributions of the following persons are gratefully @@ -71,33 +84,68 @@ Acknowledgments + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Local DNS Names + + Table of Contents Status of This Document....................................1 Abstract...................................................1 - Acknowledgments............................................2 - Table of Contents..........................................2 - 1. Introduction............................................3 - 2. Local Names Via The .local Top Level Domain.............3 - 2.1 Local DNS Server Specifics.............................6 - 2.2 Local in-addr.arpa Zones...............................7 - 2.3 Name Conflicts.........................................7 - 2.4 Nested Enclaves........................................8 - 3. Other Names in .local...................................8 - 4. Security Considerations.................................8 - 4.1 Strength of Privacy Offered............................8 - 4.2 Interaction with DNSSEC................................9 - 4.3 Network Abuse..........................................9 + Table of Contents..........................................3 - References................................................10 - Author's Address..........................................10 - Expiration and File Name..................................10 + 1. Introduction............................................4 + 2. Local Names Via The .local Top Level Domain.............5 + 2.1 Local DNS Server Specifics.............................7 + 2.2 Local in-addr.arpa Zones...............................8 + 2.3 Name Conflicts.........................................8 + 2.4 Nested Enclaves........................................9 + 3. Other Names in .local...................................9 + 4. Security Considerations.................................9 + 4.1 Strength of Privacy Offered............................9 + 4.2 Interaction with DNSSEC...............................10 - Appendix A: the .local zone...............................11 - - Appendix B: the .in-addr.arpa zone.......................13 + References................................................11 + Author's Address..........................................11 + Expiration and File Name..................................11 @@ -112,7 +160,23 @@ Table of Contents -Donald E. Eastlake 3rd [Page 2] + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 3] INTERNET-DRAFT Local DNS Names @@ -121,8 +185,8 @@ INTERNET-DRAFT Local DNS Names 1. Introduction The global Internet Domain Name System (DNS) is documented in [RFC - 1034, 1035, 1591] and numerous additional Requests for Comment. It - defines a tree of names starting with root, ".", immediately below + 1034, 1035, 1591, 2606] and numerous additional Requests for Comment. + It defines a tree of names starting with root, ".", immediately below which are top level domain names such as .com and .us. Below top level domain names there are normally additional levels of names. @@ -133,11 +197,13 @@ INTERNET-DRAFT Local DNS Names appeared. In many cases, organizations have hosts or resources that they specifically want to reference with DNS names but which they also want to be walled off from global access and even from global - knowledge of the DNS name. + knowledge of the DNS name for the resource. In the realm of IP addresses, this has been accomplished by reserving - three blocks of addresses as documented in [RFC 1918]. Familiarity - with the contents of that RFC is assumed. + three blocks of IPv4 addresses as documented in [RFC 1918] and by + allocating parts of the IPv6 address space for link and site local + addresses [RFC 2373]. Familiarity with the contents of these RFCs is + assumed. Addresses in these blocks are not to be globally routed. In the DNS area, local private names have generally been achieved in the past by "splitting" DNS at the enclave boundary, giving different @@ -145,7 +211,7 @@ INTERNET-DRAFT Local DNS Names of the enclave, using different servers for inside and outside, etc. as mentioned in [RFC 1918]. Such relatively complex configuration diddling is at variance with the simple global tree structure of the - initial DNS. + initial DNS concept. This document specifies an alternative approach to achieving the effect of local names that is more in tune with the concept of a @@ -154,28 +220,32 @@ INTERNET-DRAFT Local DNS Names continue to work. [RFC 1918] requires that private IP addresses not be indirectly - exposed to the general Internet via DNS records or otherwise. This + exposed to the general Internet via DNS records or otherwise. By + implication, the same would be true of IPv6 local addresses. This RFC provides the recommended way to accomplish such private IP - address hiding and carves out an exception thereto for the addresses - of the servers for some zones which are children of the .local top - level domain name. + address hiding and carves out a limited exception thereto for the + addresses of the servers for some zones which are children of the + .local top level domain name. + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Local DNS Names + + 2. Local Names Via The .local Top Level Domain The fundamental idea, as described in more detail below, is to define second level domains under .local which are served by DNS name servers that have private IP addresses. These server's addresses would only be routed within the domain to which the names are local. - - -Donald E. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Local DNS Names - - Thus the servers, and the names and resource records inside them, would not be directly accessible outside the enclave, if the guidelines in this document are followed. @@ -220,20 +290,20 @@ INTERNET-DRAFT Local DNS Names | example +---------------------O pubhost6 + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Local DNS Names + + Starting at the bottom, pubhost6 is intended to illustrate an ordinary host connected to the Internet with domain name pubhost6.example.com. Though not indicated in the above diagram, every DNS zone is in fact served by at least two hosts (and some but substantially more). The addresses of the servers for the root (.), .com, and example.com zones would all be in the public portion of the - - -Donald E. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Local DNS Names - - IP address space, i.e., in the space of all unicast IP addresses not reserved for private use. @@ -278,6 +348,14 @@ INTERNET-DRAFT Local DNS Names that privhost3 and pubhost4 are actually the same physical machine. The could be accomplished equally well by storing a single public address for that host under both the public and private names or by + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Local DNS Names + + having the host answer to both a public IP address stored under the public name and a private IP address stored under the private name. In the later case you could even also store the public address along @@ -285,13 +363,6 @@ INTERNET-DRAFT Local DNS Names - -Donald E. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Local DNS Names - - 2.1 Local DNS Server Specifics A variety of second level names are provided in the .local zone each @@ -336,15 +407,8 @@ INTERNET-DRAFT Local DNS Names enclave to private IP addresses which have a different meaning for that resolver. - The Appendix A to this document gives the recommended initial content - of the .local zone. - - - - - -Donald E. Eastlake 3rd [Page 6] +D. Eastlake 3rd [Page 7] INTERNET-DRAFT Local DNS Names @@ -353,16 +417,14 @@ INTERNET-DRAFT Local DNS Names 2.2 Local in-addr.arpa Zones Inverse lookup of local names corresponding to private IP addresses - needs to be provided via the in-addr.arpa zone. Appendix B contains - recommended additions to the in-addr.arpa zone (or subzones thereof) - to accomplish this. Because of the fixed naming within this zone, - different names with different numbers of servers or different - addresses can not be provided. As with the forward .local entries, - the actual NS RRs in the servers serving the private portions of the - inverse in-addr.arpa will dominate. When one of these is queried by - a resolver, it can provide information on additional servers for that - particular subzone in the private IP address portion of the in- - addr.arpa tree. + needs to be provided via the in-addr.arpa and ip6.int zones. Because + of the fixed naming within this zone, different names with different + numbers of servers or different addresses can not be provided. As + with the forward .local entries, the actual NS RRs in the servers + serving the private portions of the inverse in-addr.arpa will + dominate. When one of these is queried by a resolver, it can provide + information on additional servers for that particular subzone in the + private IP address portion of the in-addr.arpa tree. @@ -381,9 +443,9 @@ INTERNET-DRAFT Local DNS Names domain name of the enclave SHOULD always be prefixed to .local. For example, a company might have - host1.company.co.xy + host1.company.example as a globally accessible host and - host2.company.co.xy.b3.local + host2.company.example.b3.local as a host for internal use only. The global name could normally be resolvable anywhere on the Internet while the local name could not be resolved anywhere except within the company enclave. @@ -394,22 +456,23 @@ INTERNET-DRAFT Local DNS Names names, such as host3. For DNS look up purposes, such a name must be expanded into a fully qualified domain name and a "search list" of possible suffix qualifications is tried. If, for example, both - host4.school.ac.xy and host4.school.ac.xy.b3.local existed, then a - local reference to "host4" would be ambiguous and could lead to - either machine depending on the order of qualifications tried. This - order could even be different in different pieces of local software - or on different local hosts, resulting in substantial confusion. For - this reason, it is strongly recommended that disjoint name sets be + host4.school.ac.example and host4.school.ac.example.b3.local existed, + then a local reference to "host4" would be ambiguous and could lead + to either machine depending on the order of qualifications tried. + This order could even be different in different pieces of local + software or on different local hosts, resulting in substantial + confusion. For this reason, it is strongly recommended that disjoint + name sets be used for global and local entity unqualified domain + names and that fully qualified domain names be used wherever -Donald E. Eastlake 3rd [Page 7] +D. Eastlake 3rd [Page 8] INTERNET-DRAFT Local DNS Names - used for global and local entity unqualified domain names and that - fully qualified domain names be used wherever practical. + practical. @@ -430,8 +493,11 @@ INTERNET-DRAFT Local DNS Names Three additional second level domain names are assigned in the .local top level domain for other types of local names. - In particular, link.local and site.local are reserved for use in - qualifying IPv6 link local names and site local names. + In particular, + link.local and + site.local + are reserved for use in qualifying IPv6 link local names and site + local names. In addition, loopback.local is assigned and given the loopback address. @@ -441,34 +507,36 @@ INTERNET-DRAFT Local DNS Names 4. Security Considerations This section discusses the strength of the privacy offered by using - subzones of .local, interactions with DNS security, and possible - interaction with network abuse. + subzones of .local and interactions with DNS security. 4.1 Strength of Privacy Offered - It should be noted that the privacy of the DNS information protected - by storing it in servers with private IP addresses is not strong. It - is completely dependent on the integrity of enclave perimeter routing - to make these servers inaccessible. And it may occasionally leak out - in any case due to inclusion in email address fields, web pages, and - the like, although such leakage should be no worse than current split - DNS implementations of DNS data hiding. + Local names, as proposed herein, are not intended to be a strong + security mechanism. - Software should not depend on local names being accessible only - within a particular enclave as someone could deliberately create the + The privacy of the DNS information protected by storing it in servers + with private IP addresses is weak. It is completely dependent on the + integrity of enclave perimeter routing to make these servers + inaccessible. And it may occasionally leak out in any case due to + inclusion in email address fields, web pages, and the like, although + such leakage should be no worse than current split DNS -Donald E. Eastlake 3rd [Page 8] +D. Eastlake 3rd [Page 9] INTERNET-DRAFT Local DNS Names - same names within a different enclave even if the names incorporate - the name of the original enclave in an attempt to avoid such - conflicts. + implementations of DNS data hiding. + + Software should not depend on local names being accessible only + within a particular enclave as someone could deliberately create the + same names within a different enclave. This is true even if, as + recommended herein, the names incorporate the domain name of the + original enclave in an attempt to avoid such conflicts. @@ -476,34 +544,14 @@ INTERNET-DRAFT Local DNS Names Although an enclave may derive some amount of security by virtue of its isolation, it will normally be desirable to implement DNS - security [draft-ietf-dnssec-secext2-*.txt] within the enclave. The - enclave owner should generate their own keys and sign their subzone - of .local. However, a signed copy of their public key can not be - included in the .local zone as it is different for every enclave. - Thus, to authenticate the .local subzone contents, it will be - necessary to sign the KEY RR at the apex of the local subzone of - .local with the .local zone key or another key that is trusted by - local resolvers or staticly configure the public key for the .local - subzone in local resolvers. - - - -4.3 Network Abuse - - Use of the defined private server second level domain names under - return addresses, or the like, could cause DNS, SMTP, and many other - types of references to IP addresses in the [RFC 1918] blocks. This - can occur from within a firewall due to web browsing or email - processing of web pages or email from virtually anywhere in the - Internet. However, this is not a new situation as anyone who - controls any zone in the DNS, say zone.foo.example, can, although - this violates [RFC 1918], create entries therein with arbitrary IP - addresses (including multicast and undefined formats). Then, by - using these name entries in email, web links, etc., attempt to cause - a variety of spurious protocol connections to those addresses. - - Use of .local at least provides some warning that a name may be not - be correctly resolvable. + security [RFC 2535] within the enclave. The enclave owner should + generate their own keys and sign their subzone of .local. However, a + signed copy of their public key can not be included in the .local + zone as it is different for every enclave. Thus, to authenticate the + .local subzone contents, it will be necessary to sign the KEY RR at + the apex of the local subzone of .local with the .local zone key or + another key that is trusted by local resolvers or staticly configure + the public key for the .local subzone in local resolvers. @@ -518,7 +566,23 @@ INTERNET-DRAFT Local DNS Names -Donald E. Eastlake 3rd [Page 9] + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 10] INTERNET-DRAFT Local DNS Names @@ -544,8 +608,14 @@ References RFC 1958 - B. Carpenter, "Architectural Principles of the Internet", 06/06/1996. - draft-ietf-dnssec-secext2-*.txt - D. Eastlake "Domain Name System - Security Extensions". + RFC 2373 - R. Hinden, S. Deering, "IP Version 6 Addressing + Architecture", July 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. @@ -553,202 +623,40 @@ Author's Address Donald E. Eastlake 3rd IBM - 318 Acton Street - Carlisle, MA 01741 USA + 65 Shindegan Hill Road, RR #1 + Carmel, NY 10512 USA - Telephone: +1 978-287-4877 - +1 914-784-7913 - FAX: +1 978-371-7148 + Telephone: +1 914-276-2668 (h) + +1 914-784-7913 (w) + FAX: +1 914-784-3833 (w) EMail: dee3@us.ibm.com Expiration and File Name - This draft expires May 1999. + This draft expires December 1999. - Its file name is draft-ietf-dnsind-local-names-06.txt. + Its file name is draft-ietf-dnsind-local-names-07.txt. - - - - - - -Donald E. Eastlake 3rd [Page 10] +D. Eastlake 3rd [Page 11] -INTERNET-DRAFT Local DNS Names -Appendix A: the .local zone - - ===== The .local zone suggested initial contents ==== - - local. IN SOA ... ... ( - 1234 ; serial - 90000 ; refresh, 25 hours - 36000 ; retry, 10 hours - 3456000 ; expiry, 40 days - 43200 ) ; minimum of 12 hours - NS ... ; actual servers for .local zone - NS ... - ... - - loopback A 127.0.0.1 - AAAA 0::1 - MX 100 loopback.local. - - a2.local. NS ns1.a2.local. - NS ns2.a2.local. - ns1.a2.local. A 10.1.1.2 - ns2.a2.local. A 10.1.2.2 - - a3.local. NS ns1.a3.local. - NS ns2.a3.local. - NS ns3.a3.local. - ns1.a3.local. A 10.1.1.2 - ns2.a3.local. A 10.1.2.2 - ns3.a3.local. A 10.2.1.2 - - a4.local. NS ns1.a4.local. - NS ns2.a4.local. - NS ns3.a4.local. - NS ns4.a4.local. - ns1.a4.local. A 10.1.1.2 - ns2.a4.local. A 10.1.2.2 - ns3.a4.local. A 10.2.1.2 - ns4.a4.local. A 10.128.1.2 - - b2.local. NS ns1.b2.local. - NS ns2.b2.local. - ns1.b2.local. A 172.16.1.2 - ns2.b2.local. A 172.16.2.2 - - b3.local. NS ns1.b3.local. - NS ns2.b3.local. - NS ns3.b3.local. - ns1.b3.local. A 172.16.1.2 - ns2.b3.local. A 172.16.2.2 - ns3.b3.local. A 172.16.128.2 -Donald E. Eastlake 3rd [Page 11] - - -INTERNET-DRAFT Local DNS Names - - - c2.local. NS ns1.c2.local. - NS ns2.c2.local. - ns1.c2.local. A 192.168.1.2 - ns2.c2.local. A 192.168.2.2 - - c3.local. NS ns1.c3.local. - NS ns2.c3.local. - NS ns3.c3.local. - ns1.c3.local. A 192.168.1.2 - ns2.c3.local. A 192.168.2.2 - ns3.c3.local. A 192.168.128.2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake 3rd [Page 12] - - -INTERNET-DRAFT Local DNS Names - - -Appendix B: the .in-addr.arpa zone - - ===== Auggested additional entries in the in-addr.arpa zone ==== - - 10.in-addr.arpa. NS ns1.a2.local. - NS ns2.a2.local. - ns1.a2.local. A 10.1.1.2 - ns2.a2.local. A 10.1.2.2 - - 16.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - ns1.b2.local. A 172.16.1.2 ; one set of glue records - ns2.b2.local. A 172.16.2.2 ; for all the b2 cases - 17.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 18.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 19.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 20.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 21.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 22.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 23.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 24.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 25.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 26.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 27.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 28.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 29.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 30.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - 31.172.in-addr.arpa. NS ns1.b2.local. - NS ns2.b2.local. - - 168.192.in-addr.arpa. NS ns1.c2.local. - NS ns2.c2.local. - ns1.c2.local. A 192.168.1.2 - ns2.c2.local. A 102.168.2.2 - - - - -Donald E. Eastlake 3rd [Page 13] + + + + + + + + + + + +D. Eastlake 3rd [Page 12] diff --git a/doc/draft/draft-ietf-dnsind-tsig-08.txt b/doc/draft/draft-ietf-dnsind-tsig-11.txt similarity index 79% rename from doc/draft/draft-ietf-dnsind-tsig-08.txt rename to doc/draft/draft-ietf-dnsind-tsig-11.txt index 374bc32fd2..b58af806de 100644 --- a/doc/draft/draft-ietf-dnsind-tsig-08.txt +++ b/doc/draft/draft-ietf-dnsind-tsig-11.txt @@ -1,18 +1,13 @@ - - - DNSIND Working Group Paul Vixie (Ed.) (ISC) - INTERNET-DRAFT Olafur Gudmundsson (TISLabs) + INTERNET-DRAFT Olafur Gudmundsson (NAILabs) Donald Eastlake 3rd (IBM) - Brian Wellington (TISLabs) - February 1999 + Brian Wellington (NAILabs) + July 1999 Amends: RFC 1035 - Secret Key Transaction Signatures for DNS (TSIG) - Status of this Memo This document is an Internet-Draft and is in full conformance with @@ -34,7 +29,6 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - Abstract This protocol allows for transaction level authentication using @@ -46,44 +40,40 @@ it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution - - - - Expires August 1999 [Page 1] - - INTERNET-DRAFT DNS TSIG February 1999 - - is available. + Expires January 2000 [Page 1] + + INTERNET-DRAFT DNS TSIG July 1999 + 1 - Introduction 1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated hierarchical distributed database system that provides information fundamental to Internet operations, such as name <=> address translation - and mail handling information. DNS has recently been extended [RFC2065] + and mail handling information. DNS has recently been extended [RFC2535] to provide for data origin authentication, and public key distribution, all based on public key cryptography and public key based digital signatures. To be practical, this form of security generally requires extensive local caching of keys and tracing of authentication through multiple keys and signatures to a pre-trusted locally configured key. - 1.2. One difficulty with the [RFC2065] scheme is that common DNS + 1.2. One difficulty with the [RFC2535] scheme is that common DNS implementations include simple ``stub'' resolvers which do not have caches. Such resolvers typically rely on a caching DNS server on another host. It is impractical for these stub resolvers to perform - general [RFC2065] authentication and they would naturally depend on + general [RFC2535] authentication and they would naturally depend on their caching DNS server to perform such services for them. To do so securely requires secure communication of queries and responses. - [RFC2065] provides public key transaction signatures to support this but + [RFC2535] provides public key transaction signatures to support this but such signatures are very expensive computationally to generate. In general, these require the same complex public key logic that is impractical for stubs. This document specifies an efficient secret key based transaction signature that avoids these difficulties. - 1.3. A second area where use of straight [RFC2065] public key based + 1.3. A second area where use of straight [RFC2535] public key based mechanisms may be impractical is authenticating dynamic update [RFC2136] - requests. [RFC2065] provides for request signatures but with [RFC2065] + requests. [RFC2535] provides for request signatures but with [RFC2535] they, like transaction signatures, require computationally expensive public key cryptography and complex authentication logic. Secure Domain Name System Dynamic Update ([RFC2137]) describes how different keys are @@ -94,18 +84,13 @@ 1.4. A further use of this mechanishm is to protect zone transfers. In this case the data covered would be the whole zone transfer including - any glue records sent. The protocol described by [RFC2065] does not + any glue records sent. The protocol described by [RFC2535] does not protect glue records and unsigned records unless SIG(0) (transaction signature) is used. + Expires January 2000 [Page 2] - - - - Expires August 1999 [Page 2] - - INTERNET-DRAFT DNS TSIG February 1999 - + INTERNET-DRAFT DNS TSIG July 1999 1.5. The signature mechanism proposed in this document uses shared secret keys to establish trust relationship between two entities. Such @@ -132,8 +117,9 @@ ERROR = 16 (BADSIG) ERROR = 17 (BADKEY) ERROR = 18 (BADTIME) - ERROR = 19 (BADID) + 1.7. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and + "MAY" in this document are to be interpreted as described in [RFC 2119]. 2 - TSIG RR Format @@ -146,19 +132,9 @@ computed to cover a particular DNS transaction and are not DNS RRs in the usual sense. + Expires January 2000 [Page 3] - - - - - - - - - Expires August 1999 [Page 3] - - INTERNET-DRAFT DNS TSIG February 1999 - + INTERNET-DRAFT DNS TSIG July 1999 2.2 TSIG Calculation @@ -166,10 +142,11 @@ value in storing or retransmitting them, thus the TSIG RR should be discarded once it has been used to authenticate DNS message. The only Message Digest algorithm specified in this document is ``HMAC-MD5'' (see - [RFC1321], [RFC2104]). Other algorithms can be specified at later date. - Names and definitions of new algorithms should be registered with IANA. - All multi-octet integers in TSIG Record are sent in network byte order - (see [RFC1035 2.3.2]). + [RFC1321], [RFC2104]). The ``HMAC-MD5'' algorithm is mandatory to + implement for interoperability. Other algorithms can be specified at a + later date. Names and definitions of new algorithms should be + registered with IANA. All multi-octet integers in TSIG Record are sent + in network byte order (see [RFC1035 2.3.2]). 2.3. Record Format @@ -199,24 +176,15 @@ RdLen (variable) + Expires January 2000 [Page 4] - - - - - - - - - Expires August 1999 [Page 4] - - INTERNET-DRAFT DNS TSIG February 1999 - + INTERNET-DRAFT DNS TSIG July 1999 RDATA Field Name Data Type Notes - ------------------------------------------------------------------ + +------------------------------------------------------------------ Algorithm Name domain-name Name of the algorithm expressed as a domain name. Time Signed u_int48_t seconds since 1-Jan-70 UTC. @@ -227,13 +195,12 @@ Original ID u_int16_t original message ID Error u_int16_t expanded RCODE covering signature processing. - Other Len u_int16_t length, in octets, of Other Data. + Other Len u_int16_t length, in octets, of Other +Data. Other Data octet stream undefined by this protocol. - 2.4. Example - NAME GW-DENVAX-0042.HOME.VIX.COM. TYPE TSIG @@ -258,13 +225,9 @@ Other Len 0 Other Data empty + Expires January 2000 [Page 5] - - - Expires August 1999 [Page 5] - - INTERNET-DRAFT DNS TSIG February 1999 - + INTERNET-DRAFT DNS TSIG July 1999 3 - Protocol Operation @@ -272,29 +235,34 @@ Once the outgoing message has been constructed, the keyed message digest operation can be performed. The resulting message digest will then be - stored in a TSIG which is appended to the additional data section. - Appending a transaction signature to an DNS message is not allowed to - result in a truncated response; a TCP connection must be used to prevent - the truncation. To force a TCP connection, the server is permitted to - return an answer with no data only TSIG attached and TC bit set and - RCODE 0 (NOERROR). The client should at this point retry the request - using TCP (per [RFC1035 4.2.2]). + stored in a TSIG which is appended to the additional data section (the + ARCOUNT is incremented to reflect this). Appending a transaction + signature to an DNS message is not allowed to result in a truncated + response; a TCP connection must be used to prevent the truncation. To + force a TCP connection, the server is permitted to return an answer with + no data only TSIG attached and TC bit set and RCODE 0 (NOERROR). The + client should at this point retry the request using TCP (per [RFC1035 + 4.2.2]). 3.2. TSIG processing on incoming messages - Upon receipt of a message with a TSIG RR, the TSIG RR is copied to a + If an incoming message contains a TSIG record, it MUST be the last + record in the additional section. Multiple TSIG records are not + allowed. If a TSIG record is prsent in any other position, the packet + is dropped and a response with RCODE 1 (should be sent). Upon receipt + of a message with a correctly placed TSIG RR, the TSIG RR is copied to a safe location, removed from the DNS Message, and decremented out of the DNS Message Headers ARCOUNT. At this point the keyed message digest operation is performed. If the algorithm name or key name is unknown to the recipient, or if the message digests do not match, the whole DNS - Message must be discarded. A response with RCODE 9 (NOTAUTH) should be - sent back to the originator with TSIG ERROR 17 (BADKEY), if no key is - available to sign this message it must be sent unsigned (Signature Size - == 0 and empty signature). A message to the system operations log - should to be generated, to warn the operations staff of a possible - security incident in progress. Care should be taken to ensure that - logging of this type of event does not open the system to a denial of - service attack. + Message must be discarded. If the message is a query, a response with + RCODE 9 (NOTAUTH) should be sent back to the originator with TSIG ERROR + 17 (BADKEY) or TSIG error 16 (BADSIG). If no key is available to sign + this message it must be sent unsigned (Signature Size == 0 and empty + signature). A message to the system operations log should to be + generated, to warn the operations staff of a possible security incident + in progress. Care should be taken to ensure that logging of this type + of event does not open the system to a denial of service attack. 3.3. Time values used in TSIG calculations @@ -306,19 +274,16 @@ their ``on the wire'' format, in the following order: first Time Signed, then Fudge. For example: + Expires January 2000 [Page 6] + + INTERNET-DRAFT DNS TSIG July 1999 + Field Name Value Wire Format Meaning - --------------------------------------------------------------------------- + +--------------------------------------------------------------------------- Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997 Fudge 300 01 2C 5 minutes - - - - Expires August 1999 [Page 6] - - INTERNET-DRAFT DNS TSIG February 1999 - - 3.4. TSIG Variables and Coverage When generating or verifying a transaction signature, the following data @@ -329,9 +294,8 @@ A whole and complete DNS message in wire format, before the TSIG RR has been added to the additional data section and before the DNS Message Header's ARCOUNT field has been incremented to contain the TSIG RR. If - the message is of a type that can be forwarded (i.e. update) and the - message ID differs from the original message ID, the original message ID - is substituted for the message ID. + the message ID differs from the original message ID, the original + message ID is substituted for the message ID. 3.4.2. TSIG Variables @@ -358,26 +322,21 @@ case. The use of label types other than 00 is not defined for this specification. + Expires January 2000 [Page 7] + + INTERNET-DRAFT DNS TSIG July 1999 + 3.4.3. Request Signature Response signatures will include the request signature in their digest. The request's signature is digested in wire format, including the following fields: - - - - Expires August 1999 [Page 7] - - INTERNET-DRAFT DNS TSIG February 1999 - - Field Type Description --------------------------------------------------------- Signature Length u_int16_t in network byte order Signature Data octet stream exactly as transmitted - 3.5. Padding Digested components are fed into the hashing function as a continuous @@ -393,8 +352,7 @@ Digest components for requests are: DNS Message (request) - TSIG Variables (response) - + TSIG Variables (request) Note that some older name servers will not accept requests with a nonempty additional data section, but clients should only attempt signed @@ -411,26 +369,17 @@ DNS Message (response) TSIG Variables (response) + Expires January 2000 [Page 8] - - - - - - - - - Expires August 1999 [Page 8] - - INTERNET-DRAFT DNS TSIG February 1999 - + INTERNET-DRAFT DNS TSIG July 1999 4.3. TSIG on TSIG Error returns When a server detects an error in TSIG checks relating to the key or - signature, the server should send back an unsigned error message. If an - error is detected that does not relate to the key or signature, the - server should send back a signed error message. Digest components are: + signature, the server should send back an unsigned error message + (Signature Size == 0 and empty signature). If an error is detected that + does not relate to the key or signature, the server should send back a + signed error message. Digest components are: Request signature (if the request signature validated) DNS Message (response) @@ -461,29 +410,20 @@ TSIG check fails, the client MUST close the connection. If the client does not get TSIG frequently enough (as specified above) it SHOULD assume the connection has been hijacked and it SHOULD close the - connection. Client should treat this the same way as any other - interrupted transfer. + connection. Client should treat this the same way as they would any + other interrupted transfer (although the exact behavior is not + specified). + Expires January 2000 [Page 9] - - - - - - - - - Expires August 1999 [Page 9] - - INTERNET-DRAFT DNS TSIG February 1999 - + INTERNET-DRAFT DNS TSIG July 1999 4.5. Server TSIG checks Upon receipt of a message, server will check if there is a TSIG RR. If one exists, the server is required to return a TSIG RR in the response. The server MUST perform the following checks in the following order, - check KEY, check ID, check TIME values, check Signature. + check KEY, check TIME values, check Signature. 4.5.1. KEY check and error handling @@ -492,15 +432,7 @@ TSIG ERROR 17 (BADKEY). This response should be unsigned as specified in [4.3]. The server should log the error. - 4.5.2. ID check and error handling - - If the message is has an opcode that may not be forwarded, the ID field - in the DNS header is expected to match the Original ID field in the TSIG - record. If this is not the case, the server MUST generate an error - response with RCODE 9 (NOTAUTH) and TSIG ERROR 19 (BADID). The server - MUST sign this error response with the same key the client used. - - 4.5.3. TIME check and error handling + 4.5.2. TIME check and error handling If the server time is outside the time interval specified by the request (which is: Time Signed, plus/minus Fudge), the server MUST generate an @@ -512,25 +444,13 @@ verification detecting another BADTIME error. The data signed is specified in [4.3]. - 4.5.4. Signature check and error handling + 4.5.3. Signature check and error handling If TSIG fails to verify, the server MUST generate an error response as specified in [4.3] with RCODE of 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). This response should be unsigned as specified in [4.3]. The server should log the error. - - - - - - - - Expires August 1999 [Page 10] - - INTERNET-DRAFT DNS TSIG February 1999 - - 4.6. Client processing of answer When a client receives a response from a server it expects a TSIG from, @@ -543,6 +463,11 @@ response as it was TSIG error as specified in [4.3]. An message containing an unsigned TSIG record or a TSIG record which fails verification should not be considered an acceptable response; the client + + Expires January 2000 [Page 10] + + INTERNET-DRAFT DNS TSIG July 1999 + should log an error and continue to wait for a signed response until the request times out. @@ -555,14 +480,7 @@ should never sign a response with a different key than signed the request. - 4.6.2. ID error handling - - If an RCODE on a response is 9 (NOTAUTH), and the response TSIG - validates, and the TSIG ERROR is 19 (BADID), this means that for some - reason, the server received a forwarded message of a type that should - not be forwarded. This likely indicates a faulty server. - - 4.6.3. Time error handling + 4.6.2. Time error handling If the response RCODE is 9 (NOTAUTH), and TSIG ERROR is 18 (BADTIME) or the TSIG times in request and answer do not overlap, then this is a TIME @@ -571,20 +489,7 @@ resolvers MUST NOT adjust any clocks in the client based on BADTIME errors, but the server's time in other data field should be logged. - - - - - - - - - Expires August 1999 [Page 11] - - INTERNET-DRAFT DNS TSIG February 1999 - - - 4.6.4. Signature error handling + 4.6.3. Signature error handling If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this is a signature error, and client MAY retry the request with a new @@ -602,9 +507,13 @@ TSIG. If the TSIG passes all checks, the forwarding server has the obligation of including a TSIG of his own, to the destination or the next forwarder. If no transaction security is available to the - destination and response has the AD flag (see [RFC2065]), the forwarder + destination and response has the AD flag (see [RFC2535]), the forwarder MUST unset the AD flag before adding the TSIG to the answer. + Expires January 2000 [Page 11] + + INTERNET-DRAFT DNS TSIG July 1999 + 5 - Shared Secrets 5.1. Secret keys are very sensitive information and all available steps @@ -628,19 +537,10 @@ be at least as long as the keyed message digest , i.e., 16 bytes for HMAC-MD5 or 20 bytes for HMAC-SHA1. - - - - - Expires August 1999 [Page 12] - - INTERNET-DRAFT DNS TSIG February 1999 - - 6 - Security Considerations 6.1. The approach specified here is computationally much less expensive - than the signatures specified in [RFC2065]. As long as the shared + than the signatures specified in [RFC2535]. As long as the shared secret key is not compromised, strong authentication is provided for the last hop from a local name server to the user resolver. @@ -656,9 +556,13 @@ source data can come from a compromised zone master or can be corrupted during transit from an authentic zone master to some ``caching forwarder.'' However, if the server is faithfully performing the full - [RFC2065] security checks, then only security checked data will be + [RFC2535] security checks, then only security checked data will be available to the client. + Expires January 2000 [Page 12] + + INTERNET-DRAFT DNS TSIG July 1999 + 7 - IANA Considerations A new algorithm name should be a valid domain name of the type @@ -668,28 +572,6 @@ IANA must maintain control over the SIG-ALG.REG.INT domain. - - - - - - - - - - - - - - - - - - Expires August 1999 [Page 13] - - INTERNET-DRAFT DNS TSIG February 1999 - - 7 - References [RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' @@ -705,13 +587,13 @@ Recommendations for Security,'' RFC 1750, DEC, CyberCash & MIT, December 1995. - [RFC2065] D. Eastlake , C Kaufman, ``Domain Name System Security - Extensions,'' RFC 2065, CyberCash & Iris, January 1997. - [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC-MD5: Keyed-MD5 for Message Authentication,'' RFC 2104 , IBM, UCSD & IBM, February 1997. + [RFC2119] S. Bradner, ``Key words for use in RFCs to Indicate + Requirement Levels,'' RFC 2119, Harvard, March 1997 + [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore & Cisco & DEC, April 1997. @@ -719,77 +601,27 @@ [RFC2137] D. Eastlake 3rd ``Secure Domain Name System Dynamic Update,'' CyberCash, April 1997. + [RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC + 2535, IBM, March 1999. + Expires January 2000 [Page 13] - - - - - - - - - - - - - - - - - - Expires August 1999 [Page 14] - - INTERNET-DRAFT DNS TSIG February 1999 - + INTERNET-DRAFT DNS TSIG July 1999 9 - Authors' Addresses - Paul Vixie Olafur Gudmundsson - Internet Software Consortium TIS Labs at Network Associates + Internet Software Consortium NAILabs 950 Charter Street 3060 Washington Road, Route 97 Redwood City, CA 94063 Glenwood, MD 21738 +1 650 779 7001 +1 443 259 2389 - + Donald E. Eastlake 3rd Brian Wellington - IBM TIS Labs at Network Associates + IBM NAILabs 65 Shindegan Hill Road, RR #1 3060 Washington Road, Route 97 Carmel, NY 10512 USA Glenwood, MD 21738 - +1 914 783 7913 +1 443 259 2369 + +1 914 784 7913 +1 443 259 2369 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Expires August 1999 [Page 15] - + Expires January 2000 [Page 14] diff --git a/doc/draft/draft-skwan-gss-tsig-04.txt b/doc/draft/draft-skwan-gss-tsig-04.txt new file mode 100644 index 0000000000..cd5e599b99 --- /dev/null +++ b/doc/draft/draft-skwan-gss-tsig-04.txt @@ -0,0 +1,599 @@ +INTERNET-DRAFT Stuart Kwan + Praerit Garg + James Gilroy + Microsoft Corp. + June 1999 + Expires January 2000 + + GSS Algorithm for TSIG (GSS-TSIG) + +Status of this Memo + +This document is an Internet-Draft and is in full conformance +with all provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering +Task Force (IETF), its areas, and its working groups. Note that +other groups may also distribute working documents as +Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six +months and may be updated, replaced, or obsoleted by other +documents at any time. It is inappropriate to use Internet- +Drafts as reference material or to cite them other than as +"work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +Abstract + +The TSIG protocol provides transaction level authentication for DNS. +TSIG is extensible through the definition of new algorithms. This +document specifies an algorithm based on the Generic Security Service +Application Program Interface (GSS-API) [RFC2078]. + +Expires January 2000 [Page 1] + +INTERNET-DRAFT GSS-TSIG June 1999 + +Table of Contents + +1: Introduction......................................................2 +2: Protocol Overview.................................................3 + 2.1: GSS Details...................................................4 +3: Client Protocol Details...........................................4 + 3.1: Negotiating Context...........................................4 + 3.1.1: Call GSS_Init_sec_context.................................5 + 3.1.2: Send TKEY Query to Server.................................6 + 3.1.3: Receive TKEY Query-Response from Server...................6 + 3.2: Context Established...........................................8 +4: Server Protocol Details...........................................8 + 4.1: Negotiating Context...........................................8 + 4.1.1: Receive TKEY Query from Client............................9 + 4.1.2: Call GSS_Accept_sec_context...............................9 + 4.1.3: Send TKEY Query-Response to Client........................9 + 4.2: Context Established..........................................10 + 4.2.1: Terminating a Context....................................10 +5: Sending and Verifying Signed Messages............................11 + 5.1: Sending a Signed Message - Call GSS_GetMIC...................11 + 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............12 +6: Security Considerations..........................................12 +7: Acknowledgements.................................................13 +8: References.......................................................13 + +1. Introduction + +The Secret Key Transaction Signature for DNS [TSIG] protocol was +developed to provide a lightweight alternative to full DNS security +[RFC2535] and secure dynamic update [RFC2137], where full security is +impractical due to implementation complexity, management overhead, or +computational cost. + +The [TSIG] protocol is extensible through the definition of new +algorithms. This document specifies an algorithm based on the Generic +Security Service Application Program Interface (GSS-API) [RFC2078]. +GSS-API is a framework that provides an abstraction of security to the +application protocol developer. The security services offered can +include authentication, integrity, and confidentiality. + +The GSS-API framework has several benefits: +* Mechanism and protocol independence. The underlying mechanisms that +realize the security services can be negotiated on the fly and varied +over time. For example, a client and server may use Kerberos for one +transaction, whereas that same server may use TLS with a different +client. + +Expires January 2000 [Page 2] + +INTERNET-DRAFT GSS-TSIG June 1999 + +* The protocol developer is removed from the responsibility of +creating and managing a security infrastructure. For example, the +developer does not need to create new key distribution or key +management systems. Instead the developer relies on the security +service mechanism to manage this on its behalf. + +2. Protocol Overview + +Readers that are unfamiliar with the GSS-API concepts are encouraged +to read the characteristics and concepts section of [RFC2078] before +examining this protocol in detail. + +In GSS, client and server interact to create a "security context". +The security context is used to create and verify transaction +signatures on messages between the two parties. A unique security +context is required for each unique connection between client and +server. + +Creating a security context involves a negotiation between client and +server. Once a context has been established, it has a finite lifetime +for which it can be used to secure messages. Thus there are three +states of a context associated with a connection: + + +----------+ + | | + V | + +---------------+ | + | Uninitialized | | + | | | + +---------------+ | + | | + V | + +---------------+ | + | Negotiating | | + | Context | | + +---------------+ | + | | + V | + +---------------+ | + | Context | | + | Established | | + +---------------+ | + | | + +----------+ + +Every connection begins in the uninitialized state. + +Expires January 2000 [Page 3] + +INTERNET-DRAFT GSS-TSIG June 1999 + +2.1 GSS Details + +Client and server must be locally authenticated and have acquired +default credentials per [RFC2078] before using this protocol. + +Not all flags used in GSS-API interfaces are specified in this +document. Where omitted, clients and servers may select the default +or use a value based on local system policy. + +Not all error return values from GSS-API interfaces are specified in +this document. When errors are encountered, the caller should act +appropriately. + +3. Client Protocol Details + +A unique context is required for each server to which the client sends +secure messages. A context is identified by a context handle. A +client maintains a mapping of handles to servers, + + (target_server_name, key_name, context_handle) + +The value key_name also identifies a context handle, and is used on +the wire to indicate to a server which context should be used to +process the current request. + +3.1 Negotiating Context + +In GSS, establishing a security context involves the passing of opaque +tokens between the client and the server. The client generates the +initial token and sends it to the server. The server processes the +token and if necessary, returns a subsequent token to the client. The +client processes this token, and so on, until the negotiation is +complete. The number of times the client and server exchange tokens +depends on the underlying security mechanism. A completed negotiation +results in a context handle. + +The TKEY resource record [TKEY] is used as the vehicle to transfer +tokens between client and server. The TKEY record is a general +mechanism for establishing secret keys for use with TSIG. For more +information, see [TKEY]. + +Expires January 2000 [Page 4] + +INTERNET-DRAFT GSS-TSIG June 1999 + +3.1.1 Call GSS_Init_sec_context + +The client obtains the first token by calling GSS_Init_sec_context. +The following input parameters are used. The outcome of the call +is indicated with the output values below. Consult [RFC2078] for +syntax definitions. + + INPUTS + CONTEXT HANDLE input_context_handle = 0 + INTERNAL NAME targ_name = DNS/ + OCTET STRING input_token = NULL + BOOLEAN replay_det_req_flag = TRUE + BOOLEAN mutual_req_flag = TRUE + BOOLEAN deleg_req_flag = TRUE (optional) + + OUTPUTS + INTEGER major_status + CONTEXT HANDLE output_context_handle + OCTET STRING output_token + BOOLEAN replay_det_state + BOOLEAN mutual_state + +The values of replay_det_state and mutual_state indicate if the +security package can provide replay detection and mutual +authentication, respectively. If one or both of these values +are FALSE, the client must abandon this protocol. + +The deleg_req_flag is optional, and can be used if the client wants +the server to be able to call out to other services under the +context of the client. + +If major_status indicates an error, the client must abandon the +protocol. Success values of major_status are GSS_S_CONTINUE_NEEDED +and GSS_S_COMPLETE. The exact success code is important during later +processing. + +The handle output_context_handle is unique to this negotiation and +is stored in the client's mapping table as the context_handle that +maps to target_server_name. + +Expires January 2000 [Page 5] + +INTERNET-DRAFT GSS-TSIG June 1999 + +3.1.2 Send TKEY Query to Server + +The output_token from GSS_Init_sec_context is transmitted to the +server in a query request for a TKEY record. The token itself +will be placed in a TKEY record in the additional records section of +the query. The domain-like name of the TKEY record set queried for +and the name of the supplied TKEY record in the additional section +will uniquely identify the security context to both the client and +server, and thus the client should use a value which is globally +unique. + + TKEY Record + NAME = client-generated globally unique domain name string + (see [TKEY]) + RDATA + Algorithm Name = gss-tsig.microsoft.com + Mode = 3 (GSS-API negotiation - see [TKEY]) + Key Size = size of output_token + Key = output_token + +Assign the remaining fields in the TKEY RDATA appropriate values +per [TKEY]. + +If the last call to GSS_Init_sec_context yielded a major_status value +of GSS_S_COMPLETE, then the message should be signed with a TSIG +record before being sent to the server. See section 5, Sending +and Verifying Signed Messages, for the signing procedure. + +The query is transmitted to the server. + +3.1.3 Receive TKEY Query-Response from Server + +The server will return a standard TKEY query-response (see [TKEY]). +The response may indicate that TKEY is not supported, or that the +GSS-API mode and algorithm are not supported. If this is the case, +the client must abandon this algorithm. + +If the value of the Error field in the TKEY RDATA (TKEY.Error) is +BADKEY, then the token provided by the client was invalid. The +client must abandon this algorithm. + +If TKEY.Error indicates success, then the client may continue. The +next processing step depends on the value of major_status from the +most recent call to GSS_Init_sec_context: either GSS_S_COMPLETE or +GSS_S_CONTINUE. + +Expires January 2000 [Page 6] + +INTERNET-DRAFT GSS-TSIG June 1999 + +3.1.3.1 Value of major_status == GSS_S_COMPLETE + +If the last call to GSS_Init_sec_context yielded a major_status value +of GSS_S_COMPLETE and a non-NULL output_token was sent to the server, +then the client side component of the negotiation is complete and the +client is awaiting confirmation from the server. + +Confirmation will be in the form of a NOERROR query response +containing the last client supplied TKEY record in the answer section +of the query. The response may also be signed with a TSIG record, +and if present this signature must be verified using the procedure +detailed in section 5, Sending and Verifying Signed Messages. + +If the message verification completes without an error, or if a TSIG +signature was not included, the context state is advanced to Context +Established. Proceed to section 3.2 for usage of the security +context. + +3.1.3.2 Value of major_status == GSS_S_CONTINUE + +If the last call to GSS_Init_sec_context yielded a major_status value +of GSS_S_CONTINUE, then the negotiation is not yet complete. The +server will respond to the TKEY query with a NOERROR query response +that contains a TKEY record in the answer section. The TKEY record +contains a token that is passed to GSS_Init_sec_context using the +parameters from the previous call and the following modifications: + + INPUTS + CONTEXT HANDLE input_context_handle = context_handle + OCTET STRING input_token = token from Key field of + TKEY record + + OUTPUTS + INTEGER major_status + OCTET STRING output_token + +If major_status indicates an error, the client must abandon this +algorithm. Success values are GSS_S_CONTINUE and GSS_S_COMPLETE. + +If major_status is GSS_S_CONTINUE the negotiation is not yet +finished. The token output_token must again be passed to the server +in a TKEY record. The negotiation sequence is repeated beginning +with section 3.1.2. The client should place a limit on the number +of continuations in a context negotiation to prevent endless +looping. + +Expires January 2000 [Page 7] + +INTERNET-DRAFT GSS-TSIG June 1999 + +If major_status is GSS_S_COMPLETE and output_token is non-NULL, +the client-side component of the negotiation is complete but the +token output_token must be passed to the server. The negotiation +sequence is repeated beginning with section 3.1.2. + +If major_status is GSS_S_COMPLETE and output_token is NULL, context +negotiation is complete. The response from the server may be signed +with a TSIG record, and if present this signature must be verified +using the procedure detailed in section 5, Sending and +Verifying Signed Messages. + +If the message verification completes without an error, or if a TSIG +signature was not included, the context state is advanced to Context +Established. Proceed to section 3.2 for usage of the security +context. + +3.2 Context Established + +When context negotiation is complete, the handle context_handle is +used for the generation and verification of transaction signatures. + +The procedures for sending and receiving signed messages are given in +section 5, Sending and Verifying Signed Messages. + +4. Server Protocol Details + +As on the client-side, the result of a successful context negotiation +is a context handle used in future processing. + +A server may be managing several contexts with several clients. +Clients identify their contexts by providing a key name in their +request. The server maintains a mapping of key names to handles: + + (key_name, context_handle) + +4.1 Negotiating Context + +A server recognizes TKEY queries as security context negotiation +messages. + +Expires January 2000 [Page 8] + +INTERNET-DRAFT GSS-TSIG June 1999 + +4.1.1 Receive TKEY Query from Client + +Upon receiving a TKEY query, the server must examine the Mode and +Algorithm Name fields to see if they match this algorithm. If they +match, the (key_name, context_handle) mapping table is searched for +the NAME value of the TKEY record. If the name is found in the table, +the corresponding context_handle is used in following GSS operations. +If the name is not found a new negotiation is started. + +4.1.2 Call GSS_Accept_sec_context + +The server performs its side of a context negotiation by calling +GSS_Accept_sec_context with the token provided by the client in the +TKEY record. + +The server calls GSS_Accept_sec_context: + + INPUTS + CONTEXT HANDLE input_context_handle = 0 if new negotiation, + context_handle if ongoing + OCTET STRING input_token = Key field from TKEY RR + + OUTPUTS + INTEGER major_status + CONTEXT_HANDLE output_context_handle + OCTET STRING output_token + +If this is the first call to GSS_Accept_sec_context in a new +negotiation, then output_context_handle is stored in the server's +key-mapping table as the context_handle that maps to the name of the +TKEY record. + +4.1.3 Send TKEY Query-Response to Client + +If major_status returns a GSS failure code, the negotiation has +failed. The server must respond to the client with a standard +TKEY query-response where the TKEY error field value is set to +BADKEY. + +Success values for major_status are GSS_S_COMPLETE or GSS_S_CONTINUE. + +Expires January 2000 [Page 9] + +INTERNET-DRAFT GSS-TSIG June 1999 + +If major_status is GSS_S_COMPLETE the server component of the +negotiation is finished. The message from the client may be signed +with a TSIG RR, and if present this signature must be verified +using the procedure detailed in section 5, Sending and +Verifying Signed Messages. The server responds to the TKEY query +using a standard query response. If output_token is non-NULL, then it +must be returned to the client in a TKEY in the Answer section of the +response. If output_token is NULL, then the TKEY record received from +the client must be returned in the Answer section of the response. +The answer should be signed with a TSIG record per the procedure given +in section 5, Sending and Verifying Signed Messages. +The context state is advanced to Established. Section 4.2 discusses +the usage of the security context. + +If major_status is GSS_S_CONTINUE, the server component of the +negotiation is not yet finished. The server responds to the TKEY +query with a standard query response, placing a TKEY record containing +output_token in the answer section. The negotiation sequence then +repeats beginning with section 4.1.1. The server must limit the +number of times that a given context is allowed to repeat, to prevent +endless looping. + +4.2 Context Established + +When context negotiation is complete, the handle context_handle +is used for the generation and verification of transaction signatures. +The handle is valid for a finite amount of time determined by the +underlying security mechanism. A server may unilaterally terminate +a context at any time. + +The procedures for sending and receiving signed messages are given in +section 5, Sending and Verifying Signed Messages. + +4.2.1 Terminating a Context + +A server can terminate any established context at any time. The +server may hint to the client that the context is being deleted +by including a TKEY RR in a response with the mode field set to +"key deletion". See [TKEY] for more details. + +An active context is deleted by calling GSS_Delete_sec_context +providing the associated context_handle. + +Expires January 2000 [Page 10] + +INTERNET-DRAFT GSS-TSIG June 1999 + +5. Sending and Verifying Signed Messages + +5.1 Sending a Signed Message - Call GSS_GetMIC + +The procedure for sending a signature-protected message is specified +in [TSIG]. The data to be passed to the signature routine includes +the whole DNS message with specific TSIG variables appended. For the +exact format, see [TSIG]. For this protocol, use the following +TSIG variable values: + + TSIG Record + NAME = key_name that identifies this context + RDATA + Algorithm Name = gss-tsig.microsoft.com + +Assign the remaining fields in the TKEY RDATA appropriate values +per [TKEY]. + +For the GSS algorithm, the signature is generated by calling +GSS_GetMIC: + + INPUTS + CONTEXT HANDLE context_handle = context_handle for key_name + OCTET STRING message = outgoing message plus TSIG + variables (see [TSIG]) + + OUTPUTS + INTEGER major_status + OCTET STRING per_msg_token + +If major_status is GSS_S_COMPLETE, then signature generation +succeeded. The signature in per_msg_token is inserted into the +Signature field of the TSIG RR and the message is transmitted. + +If major_status is GSS_S_CONTEXT_EXPIRED or GSS_S_CREDENTIALS_EXPIRED, +the caller needs to return to the uninitialized state and negotiate +a new security context. + +Expires January 2000 [Page 11] + +INTERNET-DRAFT GSS-TSIG June 1999 + +5.2 Verifying a Signed Message - Call GSS_VerifyMIC + +The procedure for verifying a signature-protected message is specified +in [TSIG]. + +The NAME of the TSIG record determines which context_handle +maps to this context. If the NAME does not map to a currently active +context, the server must send a standard TSIG error response to the +client indicating BADKEY in the TSIG error field (see [TSIG]). + +For the GSS algorithm, a signature is verified by using GSS_VerifyMIC: + + INPUTS + CONTEXT HANDLE context_handle = context_handle for key_name + OCTET STRING message = incoming message plus TSIG + variables (see [TSIG]) + OCTET STRING per_msg_token = Signature field from TSIG RR + + OUTPUTS + INTEGER major_status + +If major_status is GSS_S_COMPLETE, the signature is authentic and the +message was delivered intact. Per [TSIG], the timer values of the +TSIG record must also be valid before considering the message to be +authentic. The caller must not act on the request or response in the +message until these checks are verified. + +If major_status is GSS_S_CONTEXT_EXPIRED, the negotiated context is no +longer valid. If this failure occurs when a server is processing a +client request, the server must send a standard TSIG error response +to the client indicating BADKEY in the TSIG error field (see [TSIG]). + +If major_status is any other error code or if the timer values of the +TSIG record are invalid, the message must not be considered authentic. +If this error checking fails when a server is processing a client +request, the appropriate error response must be sent to the client +per [TSIG]. + +6. Security Considerations + +This document describes a protocol for DNS security using GSS-API. +The security provided by this protocol is only as effective as the +security provided by the underlying GSS mechanisms. + +Expires January 2000 [Page 12] + +INTERNET-DRAFT GSS-TSIG June 1999 + +7. Acknowledgements + +The authors of this document would like to thank the following people +for their contribution to this specification: Chuck Chan, Mike Swift, +Ram Viswanathan and Donald E. Eastlake 3rd. + +8. References + +[RFC2078] J. Linn, "Generic Security Service Application Program + Interface, Version 2," RFC 2078, OpenVision Technologies, + January 1997. + +[TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key + Transaction Signatures for DNS (TSIG)," + draft-ietf-dnsind-tsig-*..txt, ISC, TIS, Cybercash. + +[TKEY] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY + RR)," draft-ietf-dnssec-tkey-*.txt. + +[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions," + RFC 2535, IBM, March 1999. + +[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update," + RFC 2137, CyberCash, April 1997. + +9. Author's Addresses + +Stuart Kwan Praerit Garg +Microsoft Corporation Microsoft Corporation +One Microsoft Way One Microsoft Way +Redmond, WA 98052 Redmond, WA 98052 +USA USA + + +James Gilroy +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 +USA +