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
