rfc2230.txt

bind 9.3结合mysql数据库

2.2 Other Examples

   This mechanism can be extended for use with other services as well.
   To give some insight into other possible uses, this section discusses
   use of KX records in environments using a Key Distribution Center
   (KDC), such as Kerberos [KN93], and a possible use of KX records in
   conjunction with mobile nodes accessing the network via a dialup
   service.

2.2.1 KDC Examples

   This example considers the situation of a destination node
   implementing IPsec that can only obtain its Security Association
   information from a Key Distribution Center (KDC).  Let the KDC
   implement both the KDC protocol and also a non-KDC key management
   protocol (e.g. ISAKMP).  In such a case, each client node of the KDC
   might have its own KX record pointing at the KDC so that nodes not
   implementing the KDC protocol can still create Security Associations
   with each of the client nodes of the KDC.

   In the event the session initiator were not using the KDC but the
   session target was an IPsec node that only used the KDC, the
   initiator would find the KX record for the target pointing at the



Atkinson                     Informational                      [Page 6]

RFC 2230           DNS Key Exchange Delegation Record      November 1997


   KDC.  Then, the external key management exchange (e.g. ISAKMP) would
   be between the initiator and the KDC.  Then the KDC would distribute
   the IPsec SA to the KDC-only IPsec node using the KDC.  The IPsec
   traffic itself could travel directly between the initiator and the
   destination node.

   In the event the initiator node could only use the KDC and the target
   were not using the KDC, the initiator would send its request for a
   key to the KDC.  The KDC would then initiate an external key
   management exchange (e.g. ISAKMP) with a node that the target's KX
   record(s) pointed to, on behalf of the initiator node.

   The target node could verify that the KDC were allowed to proxy for
   the initiator node by looking up the KX records for the initiator
   node and finding a KX record for the initiator that listed the KDC.

   Then the external key exchange would be performed between the KDC and
   the target node.  Then the KDC would distribute the resulting IPsec
   Security Association to the initiator.  Again, IPsec traffic itself
   could travel directly between the initiator and the destination.

2.2.2 Dial-Up Host Example

   This example outlines a possible use of KX records with mobile hosts
   that dial into the network via PPP and are dynamically assigned an IP
   address and domain-name at dial-in time.

   Consider the situation where each mobile node is dynamically assigned
   both a domain name and an IP address at the time that node dials into
   the network.  Let the policy require that each mobile node act as its
   own Key Exchanger.  In this case, it is important that dial-in nodes
   use addresses from one or more well known IP subnets or address pools
   dedicated to dial-in access.  If that is true, then no KX record or
   other action is needed to ensure that each node will act as its own
   Key Exchanger because lack of a KX record indicates that the node is
   its own Key Exchanger.

   Consider the situation where the mobile node's domain name remains
   constant but its IP address changes.  Let the policy require that
   each mobile node act as its own Key Exchanger.  In this case, there
   might be operational problems when another node attempts to perform a
   secure reverse DNS lookup on the IP address to determine the
   corresponding domain name.  The authenticated DNS binding (in the
   form of a PTR record) between the mobile node's currently assigned IP
   address and its permanent domain name will need to be securely
   updated each time the node is assigned a new IP address.  There are
   no mechanisms for accomplishing this that are both IETF-standard and
   widely deployed as of the time this note was written.  Use of Dynamic



Atkinson                     Informational                      [Page 7]

RFC 2230           DNS Key Exchange Delegation Record      November 1997


   DNS Update without authentication is a significant security risk and
   hence is not recommended for this situation.

3. SYNTAX OF KX RECORD

   A KX record has the DNS TYPE of "KX" and a numeric value of 36.  A KX
   record is a member of the Internet ("IN") CLASS in the DNS.  Each KX
   record is associated with a <domain-name> entry in the DNS.  A KX
   record has the following textual syntax:

        <domain-name>  IN  KX  <preference> <domain-name>

   For this description, let the <domain-name> item to the left of the
   "KX" string be called <domain-name 1> and the <domain-name> item to
   the right of the "KX" string be called <domain-name 2>.  <preference>
   is a non-negative integer.

   Internet nodes about to initiate a key exchange with <domain-name 1>
   should instead contact <domain-name 2> to initiate the key exchange
   for a security service between the initiator and <domain-name 2>.  If
   more than one KX record exists for <domain-name 1>, then the
   <preference> field is used to indicate preference among the systems
   delegated to.  Lower values are preferred over higher values.  The
   <domain-name 2> is authorised to provide key exchange services on
   behalf of <domain-name 1>.  The <domain-name 2> MUST have a CNAME
   record, an A record, or an AAAA record associated with it.

3.1 KX RDATA format

   The KX DNS record has the following RDATA format:

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                  PREFERENCE                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   EXCHANGER                   /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

   PREFERENCE      A 16 bit non-negative integer which specifies the
                   preference given to this RR among other KX records
                   at the same owner.  Lower values are preferred.

   EXCHANGER       A <domain-name> which specifies a host willing to
                   act as a mail exchange for the owner name.





Atkinson                     Informational                      [Page 8]

RFC 2230           DNS Key Exchange Delegation Record      November 1997


   KX records MUST cause type A additional section processing for the
   host specified by EXCHANGER.  In the event that the host processing
   the DNS transaction supports IPv6, KX records MUST also cause type
   AAAA additional section processing.

   The KX RDATA field MUST NOT be compressed.

4. SECURITY CONSIDERATIONS

   KX records MUST always be signed using the method(s) defined by the
   DNS Security extensions specified in [RFC-2065].  All unsigned KX
   records MUST be ignored because of the security vulnerability caused
   by assuming that unsigned records are valid.  All signed KX records
   whose signatures do not correctly validate MUST be ignored because of
   the potential security vulnerability in trusting an invalid KX
   record.

   KX records MUST be ignored by systems not implementing Secure DNS
   because such systems have no mechanism to authenticate the KX record.

   If a node does not have a permanent DNS entry and some form of
   Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
   fully authenticated to prevent an adversary from injecting false DNS
   records (especially the KX, A, and PTR records) into the Domain Name
   System.  If false records were inserted into the DNS without being
   signed by the Secure DNS mechanisms, then a denial-of-service attack
   results.  If false records were inserted into the DNS and were
   (erroneously) signed by the signing authority, then an active attack
   results.

   Myriad serious security vulnerabilities can arise if the restrictions
   throuhout this document are not strictly adhered to.  Implementers
   should carefully consider the openly published issues relating to DNS
   security [Bell95,Vixie95] as they build their implementations.
   Readers should also consider the security considerations discussed in
   the DNS Security Extensions document [RFC-2065].

5. REFERENCES


   [RFC-1825]  Atkinson, R., "IP Authentication Header", RFC 1826,
               August 1995.

   [RFC-1827]  Atkinson, R., "IP Encapsulating Security Payload",
               RFC 1827, August 1995.






Atkinson                     Informational                      [Page 9]

RFC 2230           DNS Key Exchange Delegation Record      November 1997


   [Bell95] Bellovin, S., "Using the Domain Name System for System
            Break-ins", Proceedings of 5th USENIX UNIX Security
            Symposium, USENIX Association, Berkeley, CA, June 1995.
            ftp://ftp.research.att.com/dist/smb/dnshack.ps

   [RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
               Security Extensions", RFC 2065, January 1997.

   [RFC-1510]  Kohl J., and C. Neuman, "The Kerberos Network
               Authentication Service", RFC 1510, September 1993.

   [RFC-1035]  Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, November 1987.

   [RFC-1034]  Mockapetris, P., "Domain names - concepts and
               facilities", STD 13, RFC 1034, November 1987.

   [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
             the 5th USENIX UNIX Security Symposium, USENIX
             Association, Berkeley, CA, June 1995.
             ftp://ftp.vix.com/pri/vixie/bindsec.psf

ACKNOWLEDGEMENTS

   Development of this DNS record was primarily performed during 1993
   through 1995.  The author's work on this was sponsored jointly by the
   Computing Systems Technology Office (CSTO) of the Advanced Research
   Projects Agency (ARPA) and by the Information Security Program Office
   (PD71E), Space & Naval Warface Systems Command (SPAWAR).  In that
   era, Dave Mihelcic and others provided detailed review and
   constructive feedback.  More recently, Bob Moscowitz and Todd Welch
   provided detailed review and constructive feedback of a work in
   progress version of this document.

AUTHOR'S ADDRESS

   Randall Atkinson
   Code 5544
   Naval Research Laboratory
   4555 Overlook Avenue, SW
   Washington, DC 20375-5337

   Phone: (DSN) 354-8590
   EMail: [e-mail]







Atkinson                     Informational                     [Page 10]

RFC 2230           DNS Key Exchange Delegation Record      November 1997


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   andand distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Atkinson                     Informational                     [Page 11]