upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-04-22 06:37:42 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

add

Browse source
This commit is contained in:
Bob Halley 1999-08-03 20:46:55 +00:00
parent ebe3937fc0
commit 8631cc57a9
3 changed files with 2641 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

563
doc/rfc/rfc1706.txt Normal file
View file

@ -0,0 +1,563 @@
Network Working Group B. Manning
Request for Comments: 1706 ISI
Obsoletes: 1637, 1348 R. Colella
Category: Informational NIST
October 1994
DNS NSAP Resource Records
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
OSI lower layer protocols, comprising the connectionless network
protocol (CLNP) and supporting routing protocols, are deployed in
some parts of the global Internet. Maintenance and debugging of CLNP
connectivity is greatly aided by support in the Domain Name System
(DNS) for mapping between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for
the DNS for domain name-to-NSAP mapping. The RR may be used with any
NSAP address format.
NSAP-to-name translation is accomplished through use of the PTR RR
(see STD 13, RFC 1035 for a description of the PTR RR). This paper
describes how PTR RRs are used to support this translation.
This document obsoletes RFC 1348 and RFC 1637.
Manning & Colella [Page 1]
RFC 1706 DNS NSAP RRs October 1994
1. Introduction
OSI lower layer protocols, comprising the connectionless network
protocol (CLNP) [5] and supporting routing protocols, are deployed in
some parts of the global Internet. Maintenance and debugging of CLNP
connectivity is greatly aided by support in the Domain Name System
(DNS) [7] [8] for mapping between names and NSAP (network service
access point) addresses [6] [Note: NSAP and NSAP address are used
interchangeably throughout this memo].
This document defines the format of one new Resource Record (RR) for
the DNS for domain name-to-NSAP mapping. The RR may be used with any
NSAP address format.
NSAP-to-name translation is accomplished through use of the PTR RR
(see RFC 1035 for a description of the PTR RR). This paper describes
how PTR RRs are used to support this translation.
This memo assumes that the reader is familiar with the DNS. Some
familiarity with NSAPs is useful; see [1] or Annex A of [6] for
additional information.
2. Background
The reason for defining DNS mappings for NSAPs is to support the
existing CLNP deployment in the Internet. Debugging with CLNP ping
and traceroute has become more difficult with only numeric NSAPs as
the scale of deployment has increased. Current debugging is supported
by maintaining and exchanging a configuration file with name/NSAP
mappings similar in function to hosts.txt. This suffers from the lack
of a central coordinator for this file and also from the perspective
of scaling. The former describes the most serious short-term
problem. Scaling of a hosts.txt-like solution has well-known long-
term scaling difficiencies.
3. Scope
The methods defined in this paper are applicable to all NSAP formats.
As a point of reference, there is a distinction between registration
and publication of addresses. For IP addresses, the IANA is the root
registration authority and the DNS a publication method. For NSAPs,
Annex A of the network service definition, ISO8348 [6], describes the
root registration authority and this memo defines how the DNS is used
as a publication method.
Manning & Colella [Page 2]
RFC 1706 DNS NSAP RRs October 1994
4. Structure of NSAPs
NSAPs are hierarchically structured to allow distributed
administration and efficient routing. Distributed administration
permits subdelegated addressing authorities to, as allowed by the
delegator, further structure the portion of the NSAP space under
their delegated control. Accomodating this distributed authority
requires that there be little or no a priori knowledge of the
structure of NSAPs built into DNS resolvers and servers.
For the purposes of this memo, NSAPs can be thought of as a tree of
identifiers. The root of the tree is ISO8348 [6], and has as its
immediately registered subordinates the one-octet Authority and
Format Identifiers (AFIs) defined there. The size of subsequently-
defined fields depends on which branch of the tree is taken. The
depth of the tree varies according to the authority responsible for
defining subsequent fields.
An example is the authority under which U.S. GOSIP defines NSAPs [2].
Under the AFI of 47, NIST (National Institute of Standards and
Technology) obtained a value of 0005 (the AFI of 47 defines the next
field as being two octets consisting of four BCD digits from the
International Code Designator space [3]). NIST defined the subsequent
fields in [2], as shown in Figure 1. The field immediately following
0005 is a format identifier for the rest of the U.S. GOSIP NSAP
structure, with a hex value of 80. Following this is the three-octet
field, values for which are allocated to network operators; the
registration authority for this field is delegated to GSA (General
Services Administration).
The last octet of the NSAP is the NSelector (NSel). In practice, the
NSAP minus the NSel identifies the CLNP protocol machine on a given
system, and the NSel identifies the CLNP user. Since there can be
more than one CLNP user (meaning multiple NSel values for a given
"base" NSAP), the representation of the NSAP should be CLNP-user
independent. To achieve this, an NSel value of zero shall be used
with all NSAP values stored in the DNS. An NSAP with NSel=0
identifies the network layer itself. It is left to the application
retrieving the NSAP to determine the appropriate value to use in that
instance of communication.
When CLNP is used to support TCP and UDP services, the NSel value
used is the appropriate IP PROTO value as registered with the IANA.
For "standard" OSI, the selection of NSel values is left as a matter
of local administration. Administrators of systems that support the
OSI transport protocol [4] in addition to TCP/UDP must select NSels
for use by OSI Transport that do not conflict with the IP PROTO
values.
Manning & Colella [Page 3]
RFC 1706 DNS NSAP RRs October 1994
|--------------|
| <-- IDP --> |
|--------------|-------------------------------------|
| AFI | IDI | <-- DSP --> |
|-----|--------|-------------------------------------|
| 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel |
|-----|--------|-----|----|-----|----|-----|----|----|
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
|-----|--------|-----|----|-----|----|-----|----|----|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administrative Authority
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
Figure 1: GOSIP Version 2 NSAP structure.
In the NSAP RRs in Master Files and in the printed text in this memo,
NSAPs are often represented as a string of "."-separated hex values.
The values correspond to convenient divisions of the NSAP to make it
more readable. For example, the "."-separated fields might correspond
to the NSAP fields as defined by the appropriate authority (RARE,
U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
readability. The "."s do not appear in DNS packets and DNS servers
can ignore them when reading Master Files. For example, a printable
representation of the first four fields of a U.S. GOSIP NSAP might
look like
47.0005.80.005a00
and a full U.S. GOSIP NSAP might appear as
47.0005.80.005a00.0000.1000.0020.00800a123456.00.
Other NSAP formats have different lengths and different
administratively defined field widths to accomodate different
requirements. For more information on NSAP formats in use see RFC
1629 [1].
Manning & Colella [Page 4]
RFC 1706 DNS NSAP RRs October 1994
5. The NSAP RR
The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
(decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
mapping in the DNS using the NSAP RR operates analogously to IP
address lookup. A query is generated by the resolver requesting an
NSAP RR for a provided domain name.
NSAP RRs conform to the top level RR format and semantics as defined
in Section 3.2.1 of RFC 1035.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE = NSAP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS = IN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
* NAME: an owner name, i.e., the name of the node to which this
resource record pertains.
* TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
* CLASS: two octets containing the RR IN CLASS code of 1.
* TTL: a 32 bit signed integer that specifies the time interval in
seconds that the resource record may be cached before the source
of the information should again be consulted. Zero values are
interpreted to mean that the RR can only be used for the
transaction in progress, and should not be cached. For example,
SOA records are always distributed with a zero TTL to prohibit
caching. Zero values can also be used for extremely volatile data.
Manning & Colella [Page 5]
RFC 1706 DNS NSAP RRs October 1994
* RDLENGTH: an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
* RDATA: a variable length string of octets containing the NSAP.
The value is the binary encoding of the NSAP as it would appear in
the CLNP source or destination address field. A typical example of
such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
20 (decimal); "."s have been omitted to emphasize that they don't
appear in the DNS packets.
39840f80005a0000000001e13708002010726e00
NSAP RRs cause no additional section processing.
6. NSAP-to-name Mapping Using the PTR RR
The PTR RR is defined in RFC 1035. This RR is typically used under
the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
Similarly, the PTR RR is used to map from NSAPs to domain names under
the "NSAP.INT" domain. A domain name is generated from the NSAP
according to the rules described below. A query is sent by the
resolver requesting a PTR RR for the provided domain name.
A domain name is generated from an NSAP by reversing the hex nibbles
of the NSAP, treating each nibble as a separate subdomain, and
appending the top-level subdomain name "NSAP.INT" to it. For example,
the domain name used in the reverse lookup for the NSAP
47.0005.80.005a00.0000.0001.e133.ffffff000162.00
would appear as
0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
0.8.5.0.0.0.7.4.NSAP.INT.
[Implementation note: For sanity's sake user interfaces should be
designed to allow users to enter NSAPs using their natural order,
i.e., as they are typically written on paper. Also, arbitrary "."s
should be allowed (and ignored) on input.]
7. Master File Format
The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
conforms to Section 5, "Master Files," of RFC 1035. Below are
examples of the use of these RRs in Master Files to support name-to-
NSAP and NSAP-to-name mapping.
Manning & Colella [Page 6]
RFC 1706 DNS NSAP RRs October 1994
The NSAP RR introduces a new hex string format for the RDATA field.
The format is "0x" (i.e., a zero followed by an 'x' character)
followed by a variable length string of hex characters (0 to 9, a to
f). The hex string is case-insensitive. "."s (i.e., periods) may be
inserted in the hex string anywhere after the "0x" for readability.
The "."s have no significance other than for readability and are not
propagated in the protocol (e.g., queries or zone transfers).
;;;;;;
;;;;;; Master File for domain nsap.nist.gov.
;;;;;;
@ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
IN NS emu.ncsl.nist.gov.
IN NS tuba.nsap.lanl.gov.
;
;
$ORIGIN nsap.nist.gov.
;
; hosts
;
bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
IN A 129.6.224.161
IN HINFO PC_486 BSDi1.1
;
bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
IN A 129.6.224.162
IN HINFO PC_486 BSDi1.1
;
cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
IN A 129.6.224.171
IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA)
;
infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
IN A 129.6.55.164
IN HINFO PC/486 BSDi1.0(TUBA)
;
; routers
;
cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
IN A 129.6.224.151
Manning & Colella [Page 7]
RFC 1706 DNS NSAP RRs October 1994
IN A 129.6.225.151
IN A 129.6.229.151
;
3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
IN A 129.6.224.111
IN A 129.6.225.111
IN A 129.6.228.111
;;;;;;
;;;;;; Master File for reverse mapping of NSAPs under the
;;;;;; NSAP prefix:
;;;;;;
;;;;;; 47.0005.80.005a00.0000.0001.e133
;;;;;;
@ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
IN NS emu.ncsl.nist.gov.
IN NS tuba.nsap.lanl.gov.
;
;
$ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
;
0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov.
;
0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov.
;
0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov.
;
0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov.
;
0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov.
;
0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov.
8. Security Considerations
Security issues are not discussed in this memo.
Manning & Colella [Page 8]
RFC 1706 DNS NSAP RRs October 1994
9. Authors' Addresses
Bill Manning
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA. 90292
USA
Phone: +1.310.822.1511
EMail: bmanning@isi.edu
Richard Colella
National Institute of Standards and Technology
Technology/B217
Gaithersburg, MD 20899
USA
Phone: +1 301-975-3627
Fax: +1 301 590-0932
EMail: colella@nist.gov
10. References
[1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
1994.
[2] GOSIP Advanced Requirements Group. Government Open Systems
Interconnection Profile (GOSIP) Version 2. Federal Information
Processing Standard 146-1, U.S. Department of Commerce, National
Institute of Standards and Technology, Gaithersburg, MD, April
1991.
[3] ISO/IEC. Data interchange - structures for the identification of
organization. International Standard 6523, ISO/IEC JTC 1,
Switzerland, 1984.
[4] ISO/IEC. Connection oriented transport protocol specification.
International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
[5] ISO/IEC. Protocol for Providing the Connectionless-mode Network
Service. International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
Manning & Colella [Page 9]
RFC 1706 DNS NSAP RRs October 1994
[6] ISO/IEC. Information Processing Systems -- Data Communications --
Network Service Definition. International Standard 8348, ISO/IEC
JTC 1, Switzerland, 1993.
[7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[8] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
Manning & Colella [Page 10]

1459
doc/rfc/rfc2163.txt Normal file
View file

File diff suppressed because it is too large Load diff

619
doc/rfc/rfc2230.txt Normal file
View file

@ -0,0 +1,619 @@
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.
ABSTRACT
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.
1. INTRODUCTION
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
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 [Page 2]
RFC 2230 DNS Key Exchange Delegation Record November 1997
used.
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
| |
+- R1 -----[zero or more routers]-------R2-+
| |
S2---+ +----D2
Figure 1: Network Diagram for Subnet-to-Subnet Example
In this example, R1 makes the policy decision to provide the IPsec
service for traffic from R1 destined for R2. Once R1 has decided
that the packet from S to D should be protected, it performs a secure
DNS lookup for the records associated with domain D. If R1 only
knows the IP address for D, then a secure reverse DNS lookup will be
necessary to determine the domain D, before that forward secure DNS
lookup for records associated with domain D. If these DNS records of
domain D include a KX record for the IPsec service, then R1 knows
which set of nodes are authorised key exchanger nodes for the
destination D.
In this example, let there be at least one KX record for D and let
the most preferred KX record for D point at R2. R1 then selects a
key exchanger (in this example, R2) for D from the list obtained from
the secure DNS. Then R1 initiates a key management session with that
key exchanger (in this example, R2) to setup an IPsec Security
Association between R1 and D. In this example, R1 knows (either by
seeing an outbound packet arriving from S destined to D or via other
methods) that S will be sending traffic to D. In this example R1's
policy requires that traffic from S to D should be segregated at
least on a host-to-host basis, so R1 desires an IPsec Security
Association with source identity that dominates S, proxy identity
that dominates R1, and destination identity that dominates R2.
In turn, R2 is able to authenticate the delegation of Key Exchanger
authorisation for target S to R1 by making an authenticated forward
DNS lookup for KX records associated with S and verifying that at
least one such record points to R1. The identity S is typically
given to R2 as part of the key management process between R1 and R2.
Atkinson Informational [Page 3]
RFC 2230 DNS Key Exchange Delegation Record November 1997
If D initially only knows the IP address of S, then it will need to
perform a secure reverse DNS lookup to obtain the fully-qualified
domain name for S prior to that secure forward DNS lookup.
If R2 does not receive an authenticated DNS response indicating that
R1 is an authorised key exchanger for S, then D will not accept the
SA negotiation from R1 on behalf of identity S.
If the proposed IPsec Security Association is acceptable to both R1
and R2, each of which might have separate policies, then they create
that IPsec Security Association via Key Management.
Note that for unicast traffic, Key Management will typically also
setup a separate (but related) IPsec Security Association for the
return traffic. That return IPsec Security Association will have
equivalent identities. In this example, that return IPsec Security
Association will have a source identity that dominates D, a proxy
identity that dominates R2, and a destination identity that dominates
R1.
Once the IPsec Security Association has been created, then R1 uses it
to protect traffic from S destined for D via a secure tunnel that
originates at R1 and terminates at R2. For the case of unicast, R2
will use the return IPsec Security Association to protect traffic
from D destined for S via a secure tunnel that originates at R2 and
terminates at R1.
2.1.2 Subnet-to-Host Example
Consider the case where D and R1 implement IPsec, but S does not
implement IPsec, which is an interesting variation on the previous
example. This example is shown in Figure 2 below.
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
Figure 2: Network Diagram for Subnet-to-Host Example
In this example, R1 makes the policy decision that IP Security is
needed for the packet travelling from S to D. Then, R1 performs the
secure DNS lookup for D and determines that D is its own key
exchanger, either from the existence of a KX record for D pointing to
D or from an authenticated DNS response indicating that no KX record
exists for D. If R1 does not initially know the domain name of D,
then prior to the above forward secure DNS lookup, R1 performs a
Atkinson Informational [Page 4]
RFC 2230 DNS Key Exchange Delegation Record November 1997
secure reverse DNS lookup on the IP address of D to determine the
fully-qualified domain name for that IP address. R1 then initiates
key management with D to create an IPsec Security Association on
behalf of S.
In turn, D can verify that R1 is authorised to create an IPsec
Security Association on behalf of S by performing a DNS KX record
lookup for target S. R1 usually provides identity S to D via key
management. If D only has the IP address of S, then D will need to
perform a secure reverse lookup on the IP address of S to determine
domain name S prior to the secure forward DNS lookup on S to locate
the KX records for S.
If D does not receive an authenticated DNS response indicating that
R1 is an authorised key exchanger for S, then D will not accept the
SA negotiation from R1 on behalf of identity S.
If the IPsec Security Association is successfully established between
R1 and D, that IPsec Security Association has a source identity that
dominates S's IP address, a proxy identity that dominates R1's IP
address, and a destination identity that dominates D's IP address.
Finally, R1 begins providing the security service for packets from S
that transit R1 destined for D. When D receives such packets, D
examines the SA information during IPsec input processing and sees
that R1's address is listed as valid proxy address for that SA and
that S is the source address for that SA. Hence, D knows at input
processing time that R1 is authorised to provide security on behalf
of S. Therefore packets coming from R1 with valid IP security that
claim to be from S are trusted by D to have really come from S.
2.1.3 Host to Subnet Example
Now consider the above case from D's perspective (i.e. where D is
sending IP packets to S). This variant is sometimes known as the
Mobile Host or "roadwarrier" case. The same basic concepts apply, but
the details are covered here in hope of improved clarity.
S ---+
|
+- R1 -----[zero or more routers]-------D
|
S2---+
Figure 3: Network Diagram for Host-to-Subnet Example
Atkinson Informational [Page 5]
RFC 2230 DNS Key Exchange Delegation Record November 1997
In this example, D makes the policy decision that IP Security is
needed for the packets from D to S. Then D performs the secure DNS
lookup for S and discovers that a KX record for S exists and points
at R1. If D only has the IP address of S, then it performs a secure
reverse DNS lookup on the IP address of S prior to the forward secure
DNS lookup for S.
D then initiates key management with R1, where R1 is acting on behalf
of S, to create an appropriate Security Association. Because D is
acting as its own key exchanger, R1 does not need to perform a secure
DNS lookup for KX records associated with D.
D and R1 then create an appropriate IPsec Security Security
Association. This IPsec Security Association is setup as a secure
tunnel with a source identity that dominates D's IP Address and a
destination identity that dominates R1's IP Address. Because D
performs IPsec for itself, no proxy identity is needed in this IPsec
Security Association. If the proxy identity is non-null in this
situation, then the proxy identity must dominate D's IP Address.
Finally, D sends secured IP packets to R1. R1 receives those
packets, provides IPsec input processing (including appropriate
inner/outer IP address validation), and forwards valid packets along
to S.
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: atkinson@itd.nrl.navy.mil
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]