draft-ietf-dnsext-delegation-signer-08.txt   draft-ietf-dnsext-delegation-signer-09.txt 
DNSEXT Working Group Olafur Gudmundsson DNSEXT Working Group Olafur Gudmundsson
<draft-ietf-dnsext-delegation-signer-08.txt> <draft-ietf-dnsext-delegation-signer-09.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 December 30, 2002. This draft expires on April 1, 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 2, line 27 skipping to change at page 2, line 27
Experience shows that when the same data can reside in two Experience shows that when the same data can reside in two
administratively different DNS zones, the data frequently gets out of administratively different DNS zones, the data frequently gets out of
sync. The presence of an NS RRset in a zone anywhere other than at sync. The presence of an NS RRset in a zone anywhere other than at
the apex indicates a zone cut or delegation. The RDATA of the NS the apex indicates a zone cut or delegation. The RDATA of the NS
RRset specifies the authoritative servers for the delegated or RRset specifies the authoritative servers for the delegated or
"child" zone. Based on actual measurements, 10-30% of all delegations "child" zone. Based on actual measurements, 10-30% of all delegations
on the Internet have differing NS RRsets at parent and child. There on the Internet have differing NS RRsets at parent and child. There
are a number of reasons for this, including a lack of communication are a number of reasons for this, including a lack of communication
between parent and child and bogus name servers being listed to meet between parent and child and bogus name servers being listed to meet
registrar requirements. registry requirements.
DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to
have its KEY RRset signed by its parent to create a verifiable chain have its KEY RRset signed by its parent to create a verifiable chain
of KEYs. There has been some debate on where the signed KEY RRset of KEYs. There has been some debate on where the signed KEY RRset
should reside, whether at the child [RFC2535] or at the parent. If should reside, whether at the child [RFC2535] or at the parent. If
the KEY RRset resides at the child, maintaining the signed KEY RRset the KEY RRset resides at the child, maintaining the signed KEY RRset
in the child requires frequent two-way communication between the two in the child requires frequent two-way communication between the two
parties. First the child transmits the KEY RRset to the parent and parties. First the child transmits the KEY RRset to the parent and
then the parent sends the signature(s) to the child. Storing the KEY then the parent sends the signature(s) to the child. Storing the KEY
RRset at the parent simplifies the communication. RRset at the parent simplifies the communication.
skipping to change at page 4, line 45 skipping to change at page 4, line 45
signatures verified for other types of RRsets. signatures verified for other types of RRsets.
2.2 Protocol Change 2.2 Protocol Change
All DNS servers and resolvers that support DS MUST support the OK bit All DNS servers and resolvers that support DS MUST support the OK bit
[RFC3225] and a larger message size [RFC3226]. In order for a [RFC3225] and a larger message size [RFC3226]. In order for a
delegation to be considered secure the delegation MUST contain a DS delegation to be considered secure the delegation MUST contain a DS
RRset. If a query contains the OK bit, a server returning a referral RRset. If a query contains the OK bit, a server returning a referral
for the delegation MUST include the following RRsets in the authority for the delegation MUST include the following RRsets in the authority
section in this order: section in this order:
If DS RRset is present:
parent NS RRset parent NS RRset
DS and SIG(DS) (if DS is present) DS and SIG(DS)
parent NXT and SIG(NXT) (If no DS) If no DS RRset is present:
parent NS RRset
parent NXT and SIG(NXT)
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. DS RRsets MUST NOT appear at non-delegation points or at a unsecure (from the parents point of view). DS RRsets MUST NOT appear
zone's apex. at non-delegation points or at a zone's apex.
The following section 2.2.1 replaces RFC2535 sections 2.3.4 and 3.4, Section 2.2.1 defines the behavior of the corner case of non
section 2.2.2 replaces RFC3008 section 2.7, and RFC3090 updates are recursive server that is only authorative for the child. The
in section 2.2.3. following section 2.2.2 replaces RFC2535 sections 2.3.4 and 3.4,
section 2.2.3 replaces RFC3008 section 2.7, and RFC3090 updates are
in section 2.2.4.
2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points 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
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
retrieval could get a mixture of these RRsets and SIGs, especially retrieval could get a mixture of these RRsets and SIGs, especially
since one server could be serving both the zone above and below a since one server could be serving both the zone above and below a
delegation point [RFC 2181]. delegation point [RFC 2181].
Each DS RRset stored in the parent zone MUST be signed by one of the Each DS RRset stored in the parent zone MUST be signed by, at least,
parent zone's private key. The parent zone MUST NOT contain a KEY one of the parent zone's private key. The parent zone MUST NOT
RRset at any delegation point. Delegations in the parent MAY contain contain a KEY RRset at any delegation point. Delegations in the
only the following RR types: NS, DS, NXT and SIG. The NS RRset MUST parent MAY contain only the following RR types: NS, DS, NXT and SIG.
NOT be signed. The NXT RRset is the exceptional case: it will always The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
appear differently and authoritatively in both the parent and child case: it will always appear differently and authoritatively in both
zones if both are secure. the parent and child zones if both are secure.
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 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.
The combination of signer's name, key tag, and algorithm MUST The combination of signer's name, key tag, and algorithm MUST
identify a key if this SIG(0) is to be processed. identify a key if this SIG(0) is to be processed.
skipping to change at page 7, line 9 skipping to change at page 7, line 36
Over the years there have been various discussions surrounding the Over the years there have been various discussions surrounding the
DNS delegation model, declaring it to be broken because there is no DNS delegation model, declaring it to be broken because there is no
good way to assert if a delegation exists. In the RFC2535 version of good way to assert if a delegation exists. In the RFC2535 version of
DNSSEC, the presence of the NS bit in the NXT bit map proves there is DNSSEC, the presence of the NS bit in the NXT bit map proves there is
a delegation at this name. Something more explicit is needed and the a delegation at this name. Something more explicit is needed and the
DS record addresses this need for secure delegations. DS record addresses this need for secure delegations.
The DS record is a major change to DNS: it is the first resource The DS record is a major change to DNS: it is the first resource
record that can appear only on the upper side of a delegation. Adding record that can appear only on the upper side of a delegation. Adding
it will cause interoperability problems and requires a flag day for it will cause interoperabilty problems and requires a flag day for
DNSSEC. Many old servers and resolvers MUST be upgraded to take DNSSEC. Many old servers and resolvers MUST be upgraded to take
advantage of DS. Some old servers will be able to be authoritative advantage of DS. Some old servers will be able to be authoritative
for zones with DS records but will not add the NXT or DS records to for zones with DS records but will not add the NXT or DS records to
the authority section. The same is true for caching servers; in the authority section. The same is true for caching servers; in
fact, some may even refuse to pass on the DS or NXT records. fact, some may even refuse to pass on the DS or NXT records.
2.4 Wire Format of the DS record 2.4 Wire Format of the DS record
The DS (type=TDB) record contains these fields: key tag, algorithm, The DS (type=TDB) record contains these fields: key tag, algorithm,
digest type, and the digest of a public key KEY record that is digest type, and the digest of a public key KEY record that is
skipping to change at page 7, line 51 skipping to change at page 8, line 40
MUST be allowed to sign DNS data. The digest type is an identifier MUST be allowed to sign DNS data. The digest type is an identifier
for the digest algorithm used. The digest is calculated over the for the digest algorithm used. The digest is calculated over the
canonical name of the delegated domain name followed by the whole canonical name of the delegated domain name followed by the whole
RDATA of the KEY record (all four fields). RDATA of the KEY record (all four fields).
digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata) digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
Digest type value 0 is reserved, value 1 is SHA-1, and reserving Digest type value 0 is reserved, value 1 is SHA-1, and reserving
other types requires IETF standards action. For interoperability other types requires IETF standards action. For interoperabilty
reasons, as few digest algorithms as possible should be reserved. The reasons, as few digest algorithms as possible should be reserved. The
only reason to reserve additional digest types is to increase only reason to reserve additional digest types is to increase
security. security.
DS records MUST point to zone KEY records that are allowed to DS records MUST point to zone KEY records that are allowed to
authenticate DNS data. The indicated KEY record's protocol field authenticate DNS data. The indicated KEY record's protocol field
MUST be set to 3; flag field bits 0 and 6 MUST be set to 0; bit 7 MUST be set to 3; flag field bits 0 and 6 MUST be set to 0; bit 7
MUST be set to 1. The value of other bits is not significant for the MUST be set to 1. The value of other bits is not significant for the
purposes of this document. purposes of this document.
skipping to change at page 10, line 35 skipping to change at page 11, line 35
secure.example. SIG(NXT) secure.example. SIG(NXT)
secure.example. SIG(DS) secure.example. SIG(DS)
unsecure.example NS ns1.unsecure.example. unsecure.example NS ns1.unsecure.example.
unsecure.example. NXT NS SIG NXT example. unsecure.example. NXT NS SIG NXT example.
unsecure.example. SIG(NXT) unsecure.example. SIG(NXT)
In zone "secure.example." following records exist: In zone "secure.example." following records exist:
secure.example. SOA <soa stuff> secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example. secure.example. NS ns1.secure.example.
secure.example. KEY <tag=12345 alg=3> secure.example. KEY <tag=12345 alg=3>
secure.example. KEY <tag=54321 alg=5>
secure.example. NXT <nxt stuff>
secure.example. SIG(KEY) <key-tag=12345 alg=3> secure.example. SIG(KEY) <key-tag=12345 alg=3>
secure.example. SIG(SOA) <key-tag=12345 alg=3> secure.example. SIG(SOA) <key-tag=54321 alg=5>
secure.example. SIG(NS) <key-tag=12345 alg=5> secure.example. SIG(NS) <key-tag=54321 alg=5>
secure.example. SIG(NXT) <key-tag=54321 alg=5>
In this example the private key for "example." signs the DS record In this example the private key for "example." signs the DS record
for "secure.example.", making that a secure delegation. The DS record for "secure.example.", making that a secure delegation. The DS record
states which key is expected to sign the KEY RRset at states which key is expected to sign the KEY RRset at
"secure.example.". Here "secure.example." signs its KEY RRset with "secure.example.". Here "secure.example." signs its KEY RRset with
the KEY identified in the DS RRset, thus the KEY RRset is validated the KEY identified in the DS RRset, thus the KEY RRset is validated
and trusted. and trusted.
This example has only one DS record for the child, but parents MUST This example has only one DS record for the child, but parents MUST
allow multiple DS records to facilitate key rollover. It is strongly allow multiple DS records to facilitate key rollover and multiple KEY
recommended that the DS RRset be kept small: two or three DS records algorithms.
SHOULD be sufficient in all cases.
The resolver determines the security status of "unsecure.example." by The resolver determines the security status of "unsecure.example." by
examining the parent zone's NXT record for this name. The absence of examining the parent zone's NXT record for this name. The absence of
the DS bit indicates an unsecure delegation. the DS bit indicates an unsecure delegation. Note the NXT record
SHOULD only be examined after verifying the corresponding signature.
3.1 Resolver Cost Estimates for DS Records 3.1 Resolver Cost Estimates for DS Records
From a RFC2535 resolver point of view, for each delegation followed From a RFC2535 resolver point of view, for each delegation followed
to chase down an answer, one KEY RRset has to be verified. to chase down an answer, one KEY RRset has to be verified.
Additional RRsets might also need to be verified based on local Additional RRsets might also need to be verified based on local
policy (e.g., the contents of the NS RRset). Once the resolver gets policy (e.g., the contents of the NS RRset). Once the resolver gets
to the appropriate delegation, validating the answer might require to the appropriate delegation, validating the answer might require
verifying one or more signatures. A simple A record lookup requires verifying one or more signatures. A simple A record lookup requires
at least N delegations to be verified and one RRset. For a DS-enabled at least N delegations to be verified and one RRset. For a DS-enabled
 End of changes. 

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