Commit 18657d33 authored by Andreas Gustafsson's avatar Andreas Gustafsson
Browse files

updated internet drafts

parent 6d3c9cdf
This diff is collapsed.
This Internet-Draft has expired and is no longer available.
Unrevised documents placed in the Internet-Drafts directories have a
maximum life of six months. After that time, they must be updated, or
they will be deleted. This document was deleted on March 20, 2000.
INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2535 Motorola
Expires: September 2000 March 2000
Expires: October 2000 April 2000
DNS Request and Transaction Signatures ( SIG(0)s )
--- ------- --- ----------- ---------- - ------- -
draft-ietf-dnsext-sig-zero-00.txt
<draft-ietf-dnsext-sig-zero-01.txt>
Status of This Document
This draft, file name draft-ietf-dnsext-sig-zero-00.txt, is intended
to become a Proposed Standard RFC updating Proposed Standard [RFC
2535]. Distribution of this document is unlimited. Comments should
be sent to the DNS Working Group mailing list
<namedroppers@internic.net> or to the author. [This is the successor
to draft-ietf-dnsind-sig-zero-01.txt.]
This draft is intended to become a Proposed Standard RFC updating
Proposed Standard [RFC 2535]. Distribution of this document is
unlimited. Comments should be sent to the DNS Working Group mailing
list <namedroppers@internic.net> 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
......@@ -26,10 +25,11 @@ Status of This Document
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."
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
......@@ -57,7 +57,7 @@ Abstract
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
Acknowledgments
......@@ -67,6 +67,7 @@ Acknowledgments
acknowledged:
Olafur Gudmundsson
Ed Lewis
Brian Wellington
......@@ -111,11 +112,10 @@ Table of Contents
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
1. Introduction
......@@ -127,8 +127,8 @@ INTERNET-DRAFT DNS SIG(0) March 2000
transactions / responses. Such a resource record, because it has a
type covered field of zero, is frequently called a SIG(0). The
changes are based on implementation and attempted implementation
experience with TSIG [draft-ietf-{dnsind|dnsext}-tsig-*.txt] and the
[RFC 2535] specification for SIG(0).
experience with TSIG [draft-ietf-dnsext-tsig-*.txt] and the [RFC
2535] specification for SIG(0).
Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
and 4.3. No changes are made herein related to the KEY or NXT RRs or
......@@ -143,17 +143,14 @@ INTERNET-DRAFT DNS SIG(0) March 2000
2. SIG(0) Design Rationale
The authenticated data origin and data existence denial services of
secure DNS protect only regular data resource records (RRs) or
authenticatably deny their nonexistence. These services provide no
protection for glue records, DNS requests, no protection for message
headers on requests or responses, and no protection of the overall
integrity of a response.
If header bits are falsely set or the like by a bad server, there is
little that can be done. However, it is possible to add transaction
and query authentication to be sure that queries and responses and
not tampered with in transit.
SIG(0) provides protection for DNS transactions and requests that is
not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
2535]. The authenticated data origin services of secure DNS either
provide protected data resource records (RRs) or authenticatably deny
their nonexistence. These services provide no protection for glue
records, DNS requests, no protection for message headers on requests
or responses, and no protection of the overall integrity of a
response.
......@@ -161,19 +158,22 @@ INTERNET-DRAFT DNS SIG(0) March 2000
Transaction authentication means that a requester can be sure it is
at least getting the messages from the server it queried and that the
response is from the request it sent (i.e., that these messages have
not been diddled in transit). This is accomplished by optionally
adding either a TSIG RR [draft-ietf-{dnsind|dnsext}-tsig-*.txt] or,
as described herein, a SIG(0) resource record at the end of the
response which digitally signs the concatenation of the server's
response and the corresponding resolver query.
received messages are in response to me query it sent. This is
accomplished by optionally adding either a TSIG RR [draft-ietf-
dnsext-tsig-*.txt] or, as described herein, a SIG(0) resource record
at the end of the response which digitally signs the concatenation of
the server's response and the corresponding resolver query.
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
2.2 Request Authentication
......@@ -214,43 +214,41 @@ INTERNET-DRAFT DNS SIG(0) March 2000
Because TSIG involves secret keys installed at both the requester and
server the presence of such a key implies that the other party
understands TSIG and likely has the same key installed. Furthermore,
TSIG uses keyed hash authentication codes which are relatively
inexpensive to compute. Thus it is common to authenticate requests
with TSIG and responses are authenticated with TSIG if the
understands TSIG and very likely has the same key installed.
Furthermore, TSIG uses keyed hash authentication codes which are
relatively inexpensive to compute. Thus it is common to authenticate
requests with TSIG and responses are authenticated with TSIG if the
corresponding request is authenticated.
SIG(0) on the other hand, uses public key authentication, where the
public keys are stored in DNS as KEY RRs. Thus, existence of such a
KEY RR does not necessarily imply implementation of SIG(0). In
addition, SIG(0) involves relatively expensive public key
cryptographic operations that should be minimized and the
verification of a SIG(0) involves obtaining and verifying the
public keys are stored in DNS as KEY RRs and a private key is stored
at the signer. Existence of such a KEY RR does not necessarily imply
implementation of SIG(0). In addition, SIG(0) involves relatively
expensive public key cryptographic operations that should be
minimized and the verification of a SIG(0) involves obtaining and
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
corresponding KEY which can be an expensive and lengthy operation.
Indeed, a policy of using SIG(0) on all requests and verifying it
before responding would, for some configurations, lead to a deadly
embrace with the attempt to obtain and verify the KEY needed to
authenticate the request SIG(0) resulting in additional requests
accompanied by a SIG(0) leading to further requests accompanied by a
SIG(0), etc. Furthermore, omitting SIG(0)s when not required on
requests halves the number of public key operations required by the
transaction.
verifying the corresponding KEY which can be an expensive and lengthy
operation. Indeed, a policy of using SIG(0) on all requests and
verifying it before responding would, for some configurations, lead
to a deadly embrace with the attempt to obtain and verify the KEY
needed to authenticate the request SIG(0) resulting in additional
requests accompanied by a SIG(0) leading to further requests
accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not
required on requests halves the number of public key operations
required by the transaction.
For these reasons, SIG(0)s SHOULD only be used on requests when
necessary to authenticate that the requester has some required
privilege or identity. SIG(0)s on replies are defined in such a way
as to not require a SIG(0) on the corresponding request and still
provide transaction protection. Some responses, such as those
involving TKEY [draft-ietf-dnsext-tkey-*.txt], MUST be authenticated
with TSIG or SIG(0). For other replies, whether they are
provide transaction protection. For other replies, whether they are
authenticated by the server or required to be authenticated by the
requester SHOULD be a local configuration option.
......@@ -265,14 +263,15 @@ INTERNET-DRAFT DNS SIG(0) March 2000
2535] and this document concerning SIG(0) RRs should be resolved in
favor of this document.
For all transaction SIG(0)s, the signer field MUST be the name of the
originating server host and there MUST be a KEY RR at that name with
the public key corresponding to the private key used to calculate the
signature. (The inverse IP address mapping name for an IP address of
the server MAY be used if the relevant KEY is stored there.)
For all transaction SIG(0)s, the signer field MUST be a name of the
originating host and there MUST be a KEY RR at that name with the
public key corresponding to the private key used to calculate the
signature. (The host domain name used may be the inverse IP address
mapping name for an IP address of the host if the relevant KEY is
stored there.)
For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
meaningless. The TTL fields SHOULD be zero and the CLASS filed
meaningless. The TTL fields SHOULD be zero and the CLASS field
SHOULD be ANY. To conserve space, the owner name SHOULD be root (a
single zero octet). When SIG(0) authentication on a response is
desired, that SIG RR must be considered the highest priority of any
......@@ -286,32 +285,29 @@ INTERNET-DRAFT DNS SIG(0) March 2000
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
3.1 Calculating Request and Transaction SIGs
A DNS request may be optionally signed by including one or more
SIG(0)s at the end of the query additional information section. Such
SIGs are identified by having a "type covered" field of zero. They
sign the preceding DNS request message including DNS header but not
including the UDP/IP header or any request SIG(0)s at the end and
before the request RR counts have been adjusted for the inclusions of
any request SIG(0)s.
A DNS request may be optionally signed by including one SIG(0)s at
the end of the query additional information section. Such a SIG is
identified by having a "type covered" field of zero. It signs the
preceding DNS request message including DNS header but not including
the UDP/IP header and before the request RR counts have been adjusted
for the inclusions of the request SIG(0).
Note: requests and response can either have a single TSIG or one or
more SIG(0)s but not both a TSIG and a SIG(0).
It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
(1) the SIG's RDATA section omitting the signature subfield itself,
(2) the entire DNS query messages, including DNS header, but not the
UDP/IP header and before the reply RR counts have been adjusted for
the inclusion of the SIG(0). That is
They are calculated by using a "data" (see [RFC 2535], Section 4.1.8)
of (1) the SIG's RDATA section omitting the signature subfield
itself, (2) the entire DNS query messages, including DNS header, but
not the UDP/IP header or any SIG(0) and before the reply RR counts
have been adjusted for the inclusion of any SIG(0). That is
data = RDATA | request - SIG(0)s
data = RDATA | request - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself.
......@@ -320,14 +316,14 @@ INTERNET-DRAFT DNS SIG(0) March 2000
that produced it. Such transaction signatures are calculated by
using a "data" of (1) the SIG's RDATA section omitting the signature
itself, (2) the entire DNS query message that produced this response,
including the query's DNS header and any SIG(0)s but not its UDP/IP
header, and (3) the entire DNS response message, including DNS header
but not the UDP/IP header or any SIG(0) and before the response RR
counts have been adjusted for the inclusion of any SIG(0).
including the query's DNS header but not its UDP/IP header, and (3)
the entire DNS response message, including DNS header but not the
UDP/IP header and before the response RR counts have been adjusted
for the inclusion of the SIG(0).
That is
data = RDATA | full query | response - SIG(0)s
data = RDATA | full query | response - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself.
......@@ -342,24 +338,28 @@ INTERNET-DRAFT DNS SIG(0) March 2000
packet is calculated with "data" as above and for each subsequent
packet, it is calculated as follows:
data = RDATA | DNS payload - SIG(0) | previous packet
where "|" is concatenations, RDATA is as above, and previous packet
is the previous DNS payload including DNS header and the SIG(0) but
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
data = RDATA | DNS payload - SIG(0)s | previous packet
where "|" is concatenations, RDATA is as above, and previous packet
is the previous DNS payload including DNS header and any SIG(0)s but
not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an
alternative, TSIG may be used after, if necessary, setting up a key
with TKEY [draft-ietf-dnsext-tkey-*.txt].
Except where needed to authenticate an update, TKEY, or similar
privileged request, servers are not required to check request SIGs.
privileged request, servers are not required to check a request
SIG(0).
Note: requests and response can either have a single TSIG or one
SIG(0) but not both a TSIG and a SIG(0).
......@@ -373,7 +373,7 @@ INTERNET-DRAFT DNS SIG(0) March 2000
mode in use. For all other responses, it MAY be checked and the
message rejected if the checks fail.
If a response SIG(0) checks succeed, such a transaction
If a responses SIG(0) check succeed, such a transaction
authentication SIG does NOT directly authenticate the validity any
data-RRs in the message. However, it authenticates that they were
sent by the queried server and have not been diddled. (Only a proper
......@@ -405,7 +405,7 @@ INTERNET-DRAFT DNS SIG(0) March 2000
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
The inclusion of the SIG(0) inception and expiration time under the
......@@ -415,7 +415,8 @@ INTERNET-DRAFT DNS SIG(0) March 2000
5. IANA Considerations
No new fields are created or field values assigned by the document.
No new parameters are created or parameter values assigned by the
document.
......@@ -433,13 +434,12 @@ References
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[draft-ietf-{dnsind|dnsext}-tsig-*.txt] - P. Vixie, O. Gudmundsson,
D. Eastlake, B. Wellington, "Secret Key Transaction Signatures for
DNS (TSIG)".
[draft-ietf-dnsext-tsig-*.txt] - P. Vixie, O. Gudmundsson, D.
Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS
(TSIG)".
[draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key
Establishment for DNS (RR)"
Establishment for DNS (RR)".
......@@ -463,7 +463,7 @@ References
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS SIG(0) March 2000
INTERNET-DRAFT DNS SIG(0) April 2000
Author's Address
......@@ -483,9 +483,9 @@ Author's Address
Expiration and File Name
This draft expires September 2000.
This draft expires October 2000.
Its file name is draft-ietf-dnsext-sig-zero-00.txt.
Its file name is draft-ietf-dnsext-sig-zero-01.txt.
......
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