draft-ietf-dnsext-delegation-signer-09.txt   draft-ietf-dnsext-delegation-signer-10.txt 
DNSEXT Working Group Olafur Gudmundsson DNSEXT Working Group Olafur Gudmundsson
<draft-ietf-dnsext-delegation-signer-09.txt> <draft-ietf-dnsext-delegation-signer-10.txt>
Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090. Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.
Delegation Signer Resource Record Delegation Signer Resource Record
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Comments should be sent to the authors or the DNSEXT WG mailing list Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org namedroppers@ops.ietf.org
This draft expires on April 1, 2003. This draft expires on April 16, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All rights reserved. Copyright (C) The Internet Society (2002). All rights reserved.
Abstract Abstract
The delegation signer (DS) resource record is inserted at a zone cut The delegation signer (DS) resource record is inserted at a zone cut
(i.e., a delegation point) to indicate that the delegated zone is (i.e., a delegation point) to indicate that the delegated zone is
digitally signed and that the delegated zone recognizes the indicated digitally signed and that the delegated zone recognizes the indicated
skipping to change at page 5, line 12 skipping to change at page 5, line 12
This increases the size of referral messages and may cause some or This increases the size of referral messages and may cause some or
all glue to be omitted. If the DS or NXT RRsets with signatures do all glue to be omitted. If the DS or NXT RRsets with signatures do
not fit in the DNS message, the TC bit MUST be set. Additional not fit in the DNS message, the TC bit MUST be set. Additional
section processing is not changed. section processing is not changed.
A DS RRset accompanying an NS RRset indicates that the child zone is A DS RRset accompanying an NS RRset indicates that the child zone is
secure. If an NS RRset exists without a DS RRset, the child zone is secure. If an NS RRset exists without a DS RRset, the child zone is
unsecure (from the parents point of view). DS RRsets MUST NOT appear unsecure (from the parents point of view). DS RRsets MUST NOT appear
at non-delegation points or at a zone's apex. at non-delegation points or at a zone's apex.
Section 2.2.1 defines the behavior of the corner case of non Section 2.2.1 defines special considerations related to authoritative
recursive server that is only authorative for the child. The servers responding to DS queries. Section 2.2.2 replaces RFC2535
following section 2.2.2 replaces RFC2535 sections 2.3.4 and 3.4, sections 2.3.4 and 3.4, section 2.2.3 replaces RFC3008 section 2.7,
section 2.2.3 replaces RFC3008 section 2.7, and RFC3090 updates are and section 2.2.4 updates RFC3090.
in section 2.2.4.
2.2.1 Authorative servers special processing
A server that is authorative for both parent and child, a DS aware
server will return DS from the parent zone. A non DS aware server is
expected to answer:
RCODE: NOERROR
AA bit: set
Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
This indicates there is no DS at the apex. If the server is DS aware
and does not perform recursive lookup for the DS, it MUST return the
above answer. The reason is to avoid confusing resolvers that are non
DS aware. In the early deployment of DS, most resolvers will be non-
DS aware thus send DS queries to child servers rather than parent
ones.
A DS aware recursive server that is authorative for the child, MAY
perform a recursive query to search for the DS record, if the RD bit
is set. If this server has the DS in cache it MUST return it without
the AA bit.
2.2.2 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points 2.2.2 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
DNS security views each zone as a unit of data completely under the DNS security views each zone as a unit of data completely under the
control of the zone owner with each entry (RRset) signed by a special control of the zone owner with each entry (RRset) signed by a special
private key held by the zone manager. But the DNS protocol views the private key held by the zone manager. But the DNS protocol views the
leaf nodes in a zone that are also the apex nodes of a child zone leaf nodes in a zone that are also the apex nodes of a child zone
(i.e., delegation points) as "really" belonging to the child zone. (i.e., delegation points) as "really" belonging to the child zone.
The corresponding domain names appear in two master files and might The corresponding domain names appear in two master files and might
have RRsets signed by both the parent and child zones' keys. A have RRsets signed by both the parent and child zones' keys. A
skipping to change at page 6, line 24 skipping to change at page 6, line 4
A secure zone MUST contain a self-signed KEY RRset at its apex. Upon A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
verifying the DS RRset from the parent, a resolver MAY trust any KEY verifying the DS RRset from the parent, a resolver MAY trust any KEY
identified in the DS RRset as a valid signer of the child's apex KEY identified in the DS RRset as a valid signer of the child's apex KEY
RRset. Resolvers configured to trust one of the keys signing the KEY RRset. Resolvers configured to trust one of the keys signing the KEY
RRset MAY now treat any data signed by the zone keys in the KEY RRset RRset MAY now treat any data signed by the zone keys in the KEY RRset
as secure. In all other cases resolvers MUST consider the zone as secure. In all other cases resolvers MUST consider the zone
unsecure. A DS RRset MUST NOT appear at a zone's apex. unsecure. A DS RRset MUST NOT appear at a zone's apex.
An authoritative server queried for type DS MUST return the DS RRset An authoritative server queried for type DS MUST return the DS RRset
in the answer section. in the answer section.
2.2.2.1 Special processing for DS queries
When a server is authoritative for the parent zone at a delegation
point and receives a query for the DS record at that name, it will
return the DS from the parent zone. This is true whether or not it
is also authoritative for the child zone.
When the server is authoritative for the child zone at a delegation
point but not the parent zone, there is no natural response, since
the child zone is not authoritative for the DS record at the zone's
apex. As these queries are only expected to originate from recursive
servers which are not DS-aware, the authoritative server MUST answer
with:
RCODE: NOERROR
AA bit: set
Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
That is, it answers as if it is authoritative and the DS record does
not exist. DS-aware recursive servers will query the parent zone at
delegation points, so will not be affected by this.
A server authoritative for only the child zone at a delegation point
that is also a caching server MAY (if the RD bit is set in the query)
perform recursion to find the DS record at the delegation point, and
may return the DS record from its cache. In this case, the AA bit
MUST not be set in the response.
2.2.3 Signer's Name (replaces RFC3008 section 2.7) 2.2.3 Signer's Name (replaces RFC3008 section 2.7)
The signer's name field of a SIG RR MUST contain the name of the zone The signer's name field of a SIG RR MUST contain the name of the zone
to which the data and signature belong. The combination of signer's to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is name, key tag, and algorithm MUST identify a zone key if the SIG is
to be considered material. This document defines a standard policy to be considered material. This document defines a standard policy
for DNSSEC validation; local policy may override the standard policy. for DNSSEC validation; local policy may override the standard policy.
There are no restrictions on the signer field of a SIG(0) record. There are no restrictions on the signer field of a SIG(0) record.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/