Commit 6112b0e8 authored by Bob Halley's avatar Bob Halley
Browse files

draft updates

parent dd324bd7
This diff is collapsed.
DNSIND Working Group Brian Wellington (TISLabs)
INTERNET-DRAFT Olafur Gudmundsson (TISLabs)
April 1999
<draft-ietf-dnsind-dddd-01.txt>
Updates: RFC 2136
Deferred Dynamic Domain Name System (DNS) Delete Operations
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document proposes a mechanism for notifying a dynamic DNS server
that a delete operation should be performed at a certain point in the
future. This works within the framework of the current DNS dynamic
update protocol, and provides needed functionality for clients with
leased dynamic addresses.
Expires October 1999 [Page 1]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
1 - Introduction
Dynamic update operations for the Domain Name System [RFC1034, RFC1035]
are defined in [RFC2136], but there is no automated method of specifying
that records should have a fixed lifetime, or lease.
1.1 - Overview of DNS Dynamic Update
DNS dynamic update defines a new DNS opcode and a new interpretation of
the DNS message if that opcode is used. An update can specify
insertions or deletions of data, along with prerequisites necessary for
the updates to occur. All tests and changes for a DNS update request
are restricted to a single zone, and are performed at the primary server
for the zone. The primary server for a dynamic zone must increment the
zone SOA serial number when an update occurs or before the next
retrieval of the SOA.
1.2 - Overview of DHCP leases
DHCP [RFC2131] provides a means for a host to obtain a network address
from a DHCP server. The server may ``lease'' this address to the host,
meaning that it is valid only for the period of time specified in the
lease. The host may may extend its lease with subsequent requests, or
may issue a message to release the address back to the server when it is
no longer needed.
2 - Background
When a host receives dynamic addresses with associated dynamic DNS
records, the records can be updated by either the host or the DHCP
server. In many cases, update by the server is recommended, since the
server maintains lease information for each address. In some cases,
though, the server cannot update some or all of the DNS records. This
happens when the DNS and DHCP server are under different administration,
for example.
A host can easily update its own DNS records when receiving information
from the DHCP server. It can also delete its records when shutting
down. If the host unexpectedly goes down, though, it cannot delete the
records. When the DHCP lease on the address expires and is not renewed,
the DHCP server may reassign the address. The DNS records now point to
an assigned address, but not the correct address. Until the host
updates its records again, DNS will contain bad information.
Since the DHCP and DNS servers are often not co-located with the
clients, the possibility of a host unexpectedly going down and not
communicating with the servers is non-trivial.
Expires October 1999 [Page 2]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
If the host could set a lease on the DNS records similar to that on its
address, the DNS records would lose validity at the same time as the
address. This would prevent bad information from remaining in DNS. DNS
has no such provision for leases, though, since this would require
storing a lease time along with each record (or each record in a dynamic
zone).
An alternative method is suggested. A ``delete'' update is sent along
with the ``add'' update, but the delete is marked in such a way that it
will not be exectuted immediately. Instead, it will be stored for the
specified amount of time before being applied. If the host wishes to
extend or shorten the lifetime of the DNS record(s), it can replace the
``deferred delete'' record, which will reset the lease time of the
record(s). The ``deferred delete'' record would, of course, also be
removed if a normal delete update was received.
3 - Protocol changes
When doing a delete update operation as defined in [RFC2136] (deleting
an RR, an RRset, or all RRset from a name), the TTL field MUST be
specified as 0. An [RFC2136] compliant server will silently ignore (*)
an update record with a non-zero TTL. This document overloads the TTL
field. If TTL is non-zero, the value represents the number of seconds
(a 32 bit unsigned integer) before which the delete will be applied to
the zone. Thus, the delete operation will be deferred for that number
of seconds, where the number of seconds indicates the lease time. A 32
bit integer provides for a lease time of over 136 years, which should be
long enough for most uses.
3.1 - Storage and execution
Deferred delete records are stored, persistently, by the name server.
The name server SHOULD attempt to evaluate the deletes in a timely
manner. If multiple deferred deletes are sent in the same DNS message
with the same TTL value, they MUST be processed atomically if processed
as planned (that is, none of the deferred deletes are updated or
cancelled).
3.2 - Processing of deferred deletes
When a deferred delete is received, the server must check to see if it
matches an existing deferred delete records, where matching indicates
the same name, type, class, and rdata. If a match is found, the new
deferred delete MUST replace the old one. If the deferred delete does
not refer to any record in the server, it should fail as a normal delete
would.
Expires October 1999 [Page 3]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
3.3 - Processing of normal deletes
When a normal delete is received and accepted, the server SHOULD purge
any matching deferred delete records.
3.4 - Processing of cancellations
The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL
field has a special meaning. If a delete containing this lease time is
received, the server will unconditionally remove any matching deferred
deletes. If no deferred delete matches, this request will be silently
ignored.
3.5 - Processing of adds
When data is added through a dynamic update which matches a deferred
delete, there is no additional processing done.
4 - TTL handling
Any record that may be deleted SHOULD have a short TTL compared to its
lease time, to prevent deleted data from being cached past its
expiration.
When the time until an RR is deleted becomes low enough, the server MAY
modify the TTL of the RRset. Whenever the TTL is automatically reduced
by this process, the zone will be considered ``changed'' for the purpose
of automatic SOA SERIAL increment (as in [RFC2136]) and real time zone
slave notification [RFC1996]. As these operations can potentially be
expensive (more so if DNSSEC [RFC2535] signatures must be regenerated),
the specific limits and effects are left to the implementation.
If the TTL is modified by the server, it is not reset if the lease is
renewed. Therefore, the original RR SHOULD be sent with the lease
renewal if the client expects that the server has modified the TTL.
Expires October 1999 [Page 4]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
5 - Usage
Normally, a deferred delete update will initially be sent along with an
add, although this is not required. Further updates to the deferred
delete may be sent independently, although the add should be sent again.
If the deferred delete is associated with a leased address, the lease
time of the update SHOULD be approximately equal to the lease time of
the address.
6 - Protocol robustness
This protocol has no inherent protection against replayed messages,
which can either originate from an attack or faulty hardware. To
prevent this problem, prerequisites should be used in the update
message, such as a test for the existence of a TXT record describing the
lease, which would be added along with the other records (see [RFC2136],
section 5).
7 - Security considerations
This addition to the dynamic DNS protocol does not affect the security
of the protocol. If security is desired, TSIG [TSIG] and/or DNSSEC
[RFC2535] authentication should be used, as specified in [simple-update]
or [RFC2137, update2]. The authors strongly recommend using security
along with this protocol.
If a DNSSEC signed-zone is modified with deferred deletes, the server
must resign any affected records when the delete is executed. No
special processing is required when the delete is received.
8 - IANA Considerations
None.
9 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC1996] P. Vixie ``A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996.
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
& Cisco & DEC, April 1997.
Expires October 1999 [Page 5]
INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
2137, CyberCash, April 1997.
[RFC2535] D. Eastlake ``Domain Name System Security Extensions,'' RFC
2535, IBM, March 1999.
[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington
``Secret Key Transaction Signatures for DNS (TSIG),'' draft-
ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs,
February 1999.
[simple-update]
B. Wellington ``Simple Secure Domain Name System (DNS)
Dynamic Update,'' draft-ietf-dnssec-simple-update-00.txt,
TISLabs, November 1998.
[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic
Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite
Systems Company, August 1998.
8 - Author's Address
Brian Wellington Olafur Gudmundsson
TISLabs at Network Associates TISLabs at Network Associates
3060 Washington Road, Route 97 3060 Washington Road, Route 97
Glenwood, MD 21738 Glenwood, MD 21738
+1 443 259 2369 +1 443 259 2389
<bwelling@tislabs.com> <ogud@tislabs.com>
Expires October 1999 [Page 6]
DNSIND Working Group D. Eastlake
INTERNET-DRAFT IBM
Expires October 1999
April 1999
draft-ietf-dnsind-indirect-key-00.txt
Indirect KEY RRs in the Domain Name System (DNS)
-------- --- --- -- --- ------ ---- ------ -----
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-indirect-key-00.txt, is
intended to be become a Proposed Standard RFC. Distribution of this
document is unlimited. Comments should be sent to the DNSSEC mailing
list <dns-security@tis.com> or to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
[RFC 2535] defines a means for storing cryptographic public keys in
the Domain Name System. An additional code point is defined for the
algorithm field of the KEY resource record (RR) to indicate that the
key is not stored in the KEY RR but is pointed to by the KEY RR.
Encodings to indicate different types of key and pointer formats are
specified.
[This draft is moved from the DNSSEC WG as part of that WG's merger
into me DNSIND WG. It would have been draft-ietf-dnssec-indirect-
key-02.txt in the DNSSEC WG.]
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Indirect KEY RRs
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. The Indirect KEY RR Algorithm...........................3
2.1 The Target Type Field..................................4
2.2 The Target Algorithm Field.............................5
2.3 The Hash Fields........................................5
3. Performance Considerations..............................6
4. IANA Considerations.....................................6
5. Security Considerations.................................6
References.................................................7
Author's Address...........................................7
Expiration and File Name...................................8
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Indirect KEY RRs
1. Introduction
The Domain Name System (DNS) security extensions [RFC 2535] provide
for the general storage of public keys in the domain name system via
the KEY resource record (RR). These KEY RRs are used in support of
DNS security and may be used to support other security protocols.
KEY RRs can be associated with users, zones, and hosts or other end
entities named in the DNS.
For reasons given below, it will sometimes be desireable to store a
key or keys elsewhere and merely point to it from the KEY RR.
Indirect key storage makes it possible to point to a key service via
a URL, to have a compact pointer to a larger key or set of keys, to
point to a certificate either inside DNS [RFC 2538] or outside the
DNS, and where appropriate, to store a key or key set applicable to
many DNS entries in some place and point to it from those entries.
However, to simplify DNSSEC implementation, this technique MUST NOT
be used for KEY RRs used in for verification in DNSSEC, i.e., the
value of the "protocol" field of an indirect KEY RR MUST NOT be 3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY" in this document are to be interpreted as
described in [RFC 2119].
2. The Indirect KEY RR Algorithm
Domain Name System (DNS) KEY Resource Record (RR) [RFC 2535]
algorithm number 252 is defined as the indirect key algorithm. This
algorithm MAY NOT be used for zone keys in support of DNS security.
All KEYs used in DNSSEC validation MUST be stored directly in the
DNS.
When the algorithm byte of a KEY RR has the value 252, the "public
key" portion of the RR is formated as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| target type | target alg. | hash type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash size | hash (variable size) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
| /
/ pointer (variable size) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Indirect KEY RRs
2.1 The Target Type Field
Target type specifies the type of the key containing data being
pointed at.
Target type
-----------
0 - reserved, see section 4
1 - indicates that the pointer is a domain name from which KEY RRs
[RFC 2535] should be retrieved. Name compression in the pointer
field is prohibited.
2 - indicates that the pointer is a null terminated character string
which is a URL [RFC 1738]. For exisiting data transfer URL
schemes, such as ftp, http, shttp, etc., the data is the same as
the public key portion of a KEY RR. (New URL schemes may be
defined which return multiple keys.)
3 - indicates that the pointer is a domain name from which CERT RRs
[RFC 2538] should be retrieved. Name compression in the pointer
field is prohibited.
4 - indicates that the pointer is a null terminated character string
which is a URL [RFC 1738]. For exisiting data transfer URL
schemes, such as ftp, http, shttp, etc., the data is the same as
the entire RDATA portion of a CERT RR [RFC 2538]. (New URL
schemes may be defined which return multiple such data blocks.)
5 - indicates that the pointer is a null terminated character string
which is a URL [RFC 1738]. For exisiting data transfer URL
schemes, such as ftp, http, shttp, etc., the data is a PKCS#1 [RFC
2437] format key. (New URL schemes may be defined which return
multiple keys.)
6 through 255 - available for assignment, see section 4.
256 through 511 (i.e., 256 + n) - indicate that the pointer is a null
terminated character string which is a URL [RFC 1738]. For
exisiting data transfer URL schemes, such as ftp, http, shttp,
etc., the data is a certificate of the type indicated by a CERT RR
[RFC 2538] certificate type of n. That is, target types 257, 258,
and 259 are PKIX, SPKI, and PGP certificates and target types 509
and 510 are URL and OID private certificate types. (New URL
schemes may be defined which return multiple such certificates.)
512 through 65534 - available for assignment, see section 4.
65535 reserved, see section 4.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Indirect KEY RRs
2.2 The Target Algorithm Field
The algorithm field is as defined in [RFC 2535]. If non-zero, it
specifies the algorithm type of the target key or keys pointed. If
zero, it does not specify what algorithm the target key or keys apply
to.
2.3 The Hash Fields
If the indirecting KEY RRset [RFC 2181, 2535] is retrieved from an
appropriately secure DNS zone with a resolver implementing DNS
security, then there would be a high level of confidence in the
entire value of the KEY RRset including any direct keys. This may or
may not be true of any indirect key pointed to. If an indirect key
is embodied in a certificate or retrieved via a secure protocol such
as SHTTP, it may also be secure. But an indirecting KEY RR could,
for example, simply have an FTP URL pointing to a binary key stored
elsewhere, the retrieval of which would not be secure.
The hash option in algorithm 252 KEY RRs provides a means of
extending the security of the indirecting KEY RR to the actual key
material pointed at. By including a hash in a secure indirecting RR,
this secure hash can be checked against the hash of the actual keying
material
Type Hash Algorithm
---- --------------
0 indicates no hash present
1 MD5 [RFC 1321]
2 SHA-1
3 RIPEMD
4-252 available, see section 4
253 private, domain name (see below)
254 private, OID (see below)
255 reserved
Codes 253 and 254 indicate that a private, proprietary, local, or
experimental hash algorithm is used. For code 253, the hash field
begins with a wire encoded domain name (with compression prohibited)
that indicates the algorithm to use. For code 254, the hash field
begins with a one byte unsigned OID length followed by a BER encoded
OID which indicates the algorithm to use.
The hash size field is an unsigned octet count of the hash field size
less the length of any code 253 or 254 prefix. For some hash
algorithms it may be fixed by the algorithm choice but this will not
always be the case. For example, hash size is used to distinguish
between RIPEMD-128 (16 octets) and RIPEMD-160 (20 octets). If the
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Indirect KEY RRs