Key Exchange Delegation Record for the DNS
RFC 2230

Document Type RFC - Informational (November 1997; No errata)
Was draft-rfced-info-atkinson (individual)
Author Randall Atkinson 
Last updated 2013-03-02
Stream Legacy stream
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2230 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         R. Atkinson
Request for Comments: 2230                                            NRL
Category: Informational                                     November 1997

               Key Exchange Delegation Record for the DNS

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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


   This note describes a mechanism whereby authorisation for one node to
   act as key exchanger for a second node is delegated and made
   available via the Secure DNS.  This mechanism is intended to be used
   only with the Secure DNS.  It can be used with several security
   services.  For example, a system seeking to use IP Security [RFC-
   1825, RFC-1826, RFC-1827] to protect IP packets for a given
   destination can use this mechanism to determine the set of authorised
   remote key exchanger systems for that destination.


   The Domain Name System (DNS) is the standard way that Internet nodes
   locate information about addresses, mail exchangers, and other data
   relating to remote Internet nodes. [RFC-1035, RFC-1034] More
   recently, Eastlake and Kaufman have defined standards-track security
   extensions to the DNS. [RFC-2065] These security extensions can be
   used to authenticate signed DNS data records and can also be used to
   store signed public keys in the DNS.

   The KX record is useful in providing an authenticatible method of
   delegating authorisation for one node to provide key exchange
   services on behalf of one or more, possibly different, nodes.  This
   note specifies the syntax and semantics of the KX record, which is
   currently in limited deployment in certain IP-based networks.  The

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

   reader is assumed to be familiar with the basics of DNS, including
   familiarity with [RFC-1035, RFC-1034].  This document is not on the
   IETF standards-track and does not specify any level of standard.
   This document merely provides information for the Internet community.

1.1 Identity Terminology

   This document relies upon the concept of "identity domination".  This
   concept might be new to the reader and so is explained in this
   section.  The subject of endpoint naming for security associations
   has historically been somewhat contentious.  This document takes no
   position on what forms of identity should be used.  In a network,
   there are several forms of identity that are possible.

   For example, IP Security has defined notions of identity that
   include: IP Address, IP Address Range, Connection ID, Fully-Qualified
   Domain Name (FQDN), and User with Fully Qualified Domain Name (USER

   A USER FQDN identity dominates a FQDN identity.  A FQDN identity in
   turn dominates an IP Address identity.  Similarly, a Connection ID
   dominates an IP Address identity.  An IP Address Range dominates each
   IP Address identity for each IP address within that IP address range.
   Also, for completeness, an IP Address identity is considered to
   dominate itself.


   This document specifies a new kind of DNS Resource Record (RR), known
   as the Key Exchanger (KX) record.  A Key Exchanger Record has the
   mnemonic "KX" and the type code of 36.  Each KX record is associated
   with a fully-qualified domain name.  The KX record is modeled on the
   MX record described in [Part86]. Any given domain, subdomain, or host
   entry in the DNS might have a KX record.

2.1 IPsec Examples

   In these two examples, let S be the originating node and let D be the
   destination node.  S2 is another node on the same subnet as S.  D2 is
   another node on the same subnet as D.  R1 and R2 are IPsec-capable
   routers.  The path from S to D goes via first R1 and later R2.  The
   return path from D to S goes via first R2 and later R1.

   IETF-standard IP Security uses unidirectional Security Associations
   [RFC-1825].  Therefore, a typical IP session will use a pair of
   related Security Associations, one in each direction.  The examples
   below talk about how to setup an example Security Association, but in
   practice a pair of matched Security Associations will normally be

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


2.1.1 Subnet-to-Subnet Example

   If neither S nor D implements IPsec, security can still be provided
   between R1 and R2 by building a secure tunnel.  This can use either
   AH or ESP.

       S ---+                                          +----D
            |                                          |
Show full document text