[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
synthesis in -ter; HEREIS draft-vixie-dnssec-ter-01.txt
oh hell. i let myself be fooled by the radio silence and by my private
e-mail to at least one of the "dnssec transition mechanism" subcommittee,
into thinking that i didn't need to push out an updated version of this
draft that was absent the synthesis section (formerly 2.5). HEREIS -01:
DNSEXT Working Group Paul Vixie
INTERNET-DRAFT ISC
<draft-vixie-dnssec-ter-01.txt> June 2004
Extending DNSSEC-BIS (DNSSEC-TER)
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
As the DNSSEC-BIS document set goes to press, we find that the design
goals for DNSSEC have shifted somewhat in the ten years of its
preproduction. This memo lists some possible new directions for
DNSSEC-TER, and also, some methods by which DNSSEC-TER could first
coexist with, and possibly replace, DNSSEC-BIS.
1 - Rationale and Scope
1.1. DNSSEC-BIS, which took ten years to evolve, is widely considered to
be a working solution for end to end DNS data authenticity. However,
the threat model which drove the design of DNSSEC and DNSSEC-BIS fails
to address issues of great interest to some members of the community,
for example, domain name confidentiality.
Expires December 2004 [Page 1]
INTERNET-DRAFT DNSSEC-TER June 2004
1.2. Without proposing any specific new features, this memo will lay out
an upgrade path whereby DNSSEC-TER could first coexist with, and then
possibly replace DNSSEC-BIS, with no loss of functionality for DNSSEC-
BIS adopters. The method used has been called a "type code roll" or
TCR.
1.3. The goal of this memo is not to specify DNSSEC-TER itself, but
rather, to describe the method by which it can be developed and
deployed, compatibly with an existing DNSSEC-BIS installed base.
2 - New Signalling, New Metadata
2.1. Since DNSSEC-BIS already depends on EDNS due to message size
increases, it is safe to depend on EDNS to carry a new DNSSEC-TER flag.
The meaning of this flag would be, generally, "when I say I want DNSSEC
metadata in the response to this query, I can handle, and prefer,
DNSSEC-TER metadata."
2.2. DNSSEC-TER might define new metadata records (for example, DS2,
NSEC2, RRSIG2, and/or DNSKEY2), but will not redefine the meaning or
format of existing DNSSEC-BIS metadata records due to the risk of these
records becoming separated from the DNSSEC-TER tag that tells how to
interpret them.
2.3. EDNS is a hop by hop protocol, carrying meaning only between an
initiator and a responder. A caching forwarder who can process both
DNSSEC-TER and DNSSEC-BIS will "tag" its security metadata using the
"DNSSEC-TER data is wanted" status of the query which causes that
metadata to enter the cache. If cached data exists but was fetched
without (or with) this tag, and a query arrives with (or without) the
"DNSSEC-TER wanted" flag, then the new query will have to be forwarded
upstream toward the authority servers, and the result (even if negative)
will be cached and used separately. This behaviour has the effect of
promoting the "DNSSEC-TER" wanted flag from hop-by-hop to end-to-end.
2.4. If an authority server or caching recursive server is asked for
DNSSEC-TER metadata but only has DNSSEC-BIS metadata available, then
DNSSEC-BIS data will be sent. Thus, a requestor who is capable of
handling DNSSEC-TER metadata records should ask for DNSSEC-TER first,
and then fall back to DNSSEC-BIS if necessary. This optimizes for the
eventual case when the installed base of DNSSEC-BIS has completely
upgraded to DNSSEC-TER. An initiator is not permitted to assume, from
the lack of a DNSSEC-TER response, that either that server or that zone
does not in general support DNSSEC-TER.
Expires December 2004 [Page 2]
INTERNET-DRAFT DNSSEC-TER June 2004
2.5. A zone signer and/or authority server might choose to support both
DNSSEC-BIS and DNSSEC-TER, or only DNSSEC-BIS, or only DNSSEC-TER. It
is expected that a validating recursive server, or a caching recursive
server, will support either DNSSEC-BIS alone (as is the case today), or
both DNSSEC-BIS and DNSSEC-TER, but never DNSSEC-TER alone.
3 - References
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, USC/Information Sciences
Institute, November 1987.
[RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671,
IETF DNSIND, September 1998
4 - Author's Address
Paul Vixie
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
+1.650.423.1301
<vixie@isc.org>
3557*VIX
Expires December 2004 [Page 3]
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>