draft-ietf-dnsext-delegation-signer-11.txt   draft-ietf-dnsext-delegation-signer-12.txt 
DNSEXT Working Group Olafur Gudmundsson DNSEXT Working Group Olafur Gudmundsson
<draft-ietf-dnsext-delegation-signer-11.txt> <draft-ietf-dnsext-delegation-signer-12.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 30, 2003. This draft expires on June 4, 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 6, line 26 skipping to change at page 6, line 26
That is, it answers as if it is authoritative and the DS record does 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 not exist. DS-aware recursive servers will query the parent zone at
delegation points, so will not be affected by this. delegation points, so will not be affected by this.
A server authoritative for only the child zone at a delegation point 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) 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 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 may return the DS record from its cache. In this case, the AA bit
MUST not be set in the response. MUST not be set in the response.
2.2.1.2 Special processing when child and an ancestor share server
When a child zone and a ancestor other than parent share an
authorative server, a DS aware server MUST answer with information
from child zone, as specified in section 2.2.1.1. This is to prevent
the server to be marked as lame for child.
This answer can cause problem for a DS aware resolver that is
traversing this branch of the DNS tree for the first time. The
resolver is expecting to get back either DS record or a delegation
information. The SOA with same name as QNAME informs the resolver
that the answer orignated from the zone below the one where the DS
resides. At this point the resolver has no information on how to get
from the ancestor to the parent. In this case the resolver SHOULD
attempt to fetch the delegation information by issuing a query with a
QNAME one label shorter and type NS. This will yield the NS set for
the parent, allowing the resolver to query for the DS record.
2.2.2 Signer's Name (replaces RFC3008 section 2.7) 2.2.2 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.
The combination of signer's name, key tag, and algorithm MUST The combination of signer's name, key tag, and algorithm MUST
skipping to change at page 13, line 29 skipping to change at page 13, line 29
6 Acknowledgments 6 Acknowledgments
Over the last few years a number of people have contributed ideas Over the last few years a number of people have contributed ideas
that are captured in this document. The core idea of using one key to that are captured in this document. The core idea of using one key to
sign only the KEY RRset comes from discussions with Bill Manning and sign only the KEY RRset comes from discussions with Bill Manning and
Perry Metzger on how to put in a single root key in all resolvers. Perry Metzger on how to put in a single root key in all resolvers.
Alexis Yushin, Brian Wellington, Paul Vixie, Jakob Schlyter, Scott Alexis Yushin, Brian Wellington, Paul Vixie, Jakob Schlyter, Scott
Rose, Edward Lewis, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan Rose, Edward Lewis, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan
Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard
Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve
Bellovin, Rob Austein, Derek Atkins, Roy Arends, Harald Alvestrand, Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark Andrews, Harald
and others have provided useful comments. Alvestrand, and others have provided useful comments.
Normative References: Normative References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and [RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987. Specification'', STD 13, RFC 1035, November 1987.
[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', [RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'',
RFC 2181, July 1997. RFC 2181, July 1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
 End of changes. 

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