rfc2930.txt

bind 9.3结合mysql数据库

Network Working Group                                   D. Eastlake, 3rd
Request for Comments: 2930                                      Motorola
Category: Standards Track                                 September 2000


               Secret Key Establishment for DNS (TKEY RR)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   [RFC 2845] provides a means of authenticating Domain Name System
   (DNS) queries and responses using shared secret keys via the
   Transaction Signature (TSIG) resource record (RR).  However, it
   provides no mechanism for setting up such keys other than manual
   exchange. This document describes a Transaction Key (TKEY) RR that
   can be used in a number of different modes to establish shared secret
   keys between a DNS resolver and server.

Acknowledgments

   The comments and ideas of the following persons (listed in alphabetic
   order) have been incorporated herein and are gratefully acknowledged:

         Olafur Gudmundsson (TIS)

         Stuart Kwan (Microsoft)

         Ed Lewis (TIS)

         Erik Nordmark (SUN)

         Brian Wellington (Nominum)








Eastlake                    Standards Track                     [Page 1]

RFC 2930                    The DNS TKEY RR               September 2000


Table of Contents

   1. Introduction...............................................  2
   1.1 Overview of Contents......................................  3
   2. The TKEY Resource Record...................................  4
   2.1 The Name Field............................................  4
   2.2 The TTL Field.............................................  5
   2.3 The Algorithm Field.......................................  5
   2.4 The Inception and Expiration Fields.......................  5
   2.5 The Mode Field............................................  5
   2.6 The Error Field...........................................  6
   2.7 The Key Size and Data Fields..............................  6
   2.8 The Other Size and Data Fields............................  6
   3. General TKEY Considerations................................  7
   4. Exchange via Resolver Query................................  8
   4.1 Query for Diffie-Hellman Exchanged Keying.................  8
   4.2 Query for TKEY Deletion...................................  9
   4.3 Query for GSS-API Establishment........................... 10
   4.4 Query for Server Assigned Keying.......................... 10
   4.5 Query for Resolver Assigned Keying........................ 11
   5. Spontaneous Server Inclusion............................... 12
   5.1 Spontaneous Server Key Deletion........................... 12
   6. Methods of Encryption...................................... 12
   7. IANA Considerations........................................ 13
   8. Security Considerations.................................... 13
   References.................................................... 14
   Author's Address.............................................. 15
   Full Copyright Statement...................................... 16

1. Introduction

   The Domain Name System (DNS) is a hierarchical, distributed, highly
   available database used for bi-directional mapping between domain
   names and addresses, for email routing, and for other information
   [RFC 1034, 1035].  It has been extended to provide for public key
   security and dynamic update [RFC 2535, RFC 2136].  Familiarity with
   these RFCs is assumed.

   [RFC 2845] provides a means of efficiently authenticating DNS
   messages using shared secret keys via the TSIG resource record (RR)
   but provides no mechanism for setting up such keys other than manual
   exchange. This document specifies a TKEY RR that can be used in a
   number of different modes to establish and delete such shared secret
   keys between a DNS resolver and server.







Eastlake                    Standards Track                     [Page 2]

RFC 2930                    The DNS TKEY RR               September 2000


   Note that TKEY established keying material and TSIGs that use it are
   associated with DNS servers or resolvers.  They are not associated
   with zones.  They may be used to authenticate queries and responses
   but they do not provide zone based DNS data origin or denial
   authentication [RFC 2535].

   Certain modes of TKEY perform encryption which may affect their
   export or import status for some countries.  The affected modes
   specified in this document are the server assigned mode and the
   resolver assigned mode.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

   In all cases herein, the term "resolver" includes that part of a
   server which may make full and incremental [RFC 1995] zone transfer
   queries, forwards recursive queries, etc.

1.1 Overview of Contents

   Section 2 below specifies the TKEY RR and provides a description of
   and considerations for its constituent fields.

   Section 3 describes general principles of operations with TKEY.

   Section 4 discusses key agreement and deletion via DNS requests with
   the Query opcode for RR type TKEY.  This method is applicable to all
   currently defined TKEY modes, although in some cases it is not what
   would intuitively be called a "query".

   Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
   servers which is currently used only for key deletion.

   Section 6 describes encryption methods for transmitting secret key
   information. In this document these are used only for the server
   assigned mode and the resolver assigned mode.

   Section 7 covers IANA considerations in assignment of TKEY modes.

   Finally, Section 8 provides the required security considerations
   section.









Eastlake                    Standards Track                     [Page 3]

RFC 2930                    The DNS TKEY RR               September 2000


2. The TKEY Resource Record

   The TKEY resource record (RR) has the structure given below.  Its RR
   type code is 249.

      Field       Type         Comment
      -----       ----         -------

      NAME         domain      see description below
      TTYPE        u_int16_t   TKEY = 249
      CLASS        u_int16_t   ignored, SHOULD be 255 (ANY)
      TTL          u_int32_t   ignored, SHOULD be zero
      RDLEN        u_int16_t   size of RDATA
      RDATA:
       Algorithm:   domain
       Inception:   u_int32_t
       Expiration:  u_int32_t
       Mode:        u_int16_t
       Error:       u_int16_t
       Key Size:    u_int16_t
       Key Data:    octet-stream
       Other Size:  u_int16_t
       Other Data:  octet-stream  undefined by this specification

2.1 The Name Field

   The Name field relates to naming keys.  Its meaning differs somewhat
   with mode and context as explained in subsequent sections.

   At any DNS server or resolver only one octet string of keying
   material may be in place for any particular key name.  An attempt to
   establish another set of keying material at a server for an existing
   name returns a BADNAME error.

   For a TKEY with a non-root name appearing in a query, the TKEY RR
   name SHOULD be a domain locally unique at the resolver, less than 128
   octets long in wire encoding, and meaningful to the resolver to
   assist in distinguishing keys and/or key agreement sessions.   For
   TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
   be a globally unique server assigned domain.

   A reasonable key naming strategy is as follows:

      If the key is generated as the result of a query with root as its
      owner name, then the server SHOULD create a globally unique domain
      name, to be the key name, by suffixing a pseudo-random [RFC 1750]
      label with a domain name of the server.  For example
      89n3mDgX072pp.server1.example.com.  If generation of a new



Eastlake                    Standards Track                     [Page 4]

RFC 2930                    The DNS TKEY RR               September 2000


      pseudo-random name in each case is an excessive computation load
      or entropy drain, a serial number prefix can be added to a fixed
      pseudo-random name generated an DNS server start time, such as
      1001.89n3mDgX072pp.server1.example.com.

      If the key is generated as the result of a query with a non-root
      name, say 789.resolver.example.net, then use the concatenation of
      that with a name of the server.  For example
      789.resolver.example.net.server1.example.com.

2.2 The TTL Field

   The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
   be sure that older DNS implementations do not cache TKEY RRs.

2.3 The Algorithm Field

   The algorithm name is in the form of a domain name with the same
   meaning as in [RFC 2845].  The algorithm determines how the secret
   keying material agreed to using the TKEY RR is actually used to
   derive the algorithm specific key.

2.4 The Inception and Expiration Fields

   The inception time and expiration times are in number of seconds
   since the beginning of 1 January 1970 GMT ignoring leap seconds
   treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
   between a DNS resolver and a DNS server where these fields are
   meaningful, they are either the requested validity interval for the
   keying material asked for or specify the validity interval of keying
   material provided.

   To avoid different interpretations of the inception and expiration
   times in TKEY RRs, resolvers and servers exchanging them must have
   the same idea of what time it is.  One way of doing this is with the
   NTP protocol [RFC 2030] but that or any other time synchronization
   used for this purpose MUST be done securely.

2.5 The Mode Field

   The mode field specifies the general scheme for key agreement or the
   purpose of the TKEY DNS message.  Servers and resolvers supporting
   this specification MUST implement the Diffie-Hellman key agreement
   mode and the key deletion mode for queries.  All other modes are
   OPTIONAL.  A server supporting TKEY that receives a TKEY request with
   a mode it does not support returns the BADMODE error.  The following
   values of the Mode octet are defined, available, or reserved:




Eastlake                    Standards Track                     [Page 5]

RFC 2930                    The DNS TKEY RR               September 2000


         Value    Description
         -----    -----------
          0        - reserved, see section 7
          1       server assignment
          2       Diffie-Hellman exchange
          3       GSS-API negotiation
          4       resolver assignment
          5       key deletion
         6-65534   - available, see section 7
         65535     - reserved, see section 7

2.6 The Error Field

   The error code field is an extended RCODE.  The following values are