RFC 2230 (rfc2230) - Page 2 of 11
Key Exchange Delegation Record for the DNS
Alternative Format: Original Text Document
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
FQDN).
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.
2. APPROACH
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