< draft-ietf-dnsext-dnssec-records-08.txt   draft-ietf-dnsext-dnssec-records-09.txt >
DNS Extensions R. Arends DNS Extensions R. Arends
Internet-Draft Telematica Instituut Internet-Draft Telematica Instituut
Expires: November 15, 2004 R. Austein Expires: January 13, 2005 R. Austein
ISC ISC
M. Larson M. Larson
VeriSign VeriSign
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
May 17, 2004 July 15, 2004
Resource Records for the DNS Security Extensions Resource Records for the DNS Security Extensions
draft-ietf-dnsext-dnssec-records-08 draft-ietf-dnsext-dnssec-records-09
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
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.
This Internet-Draft will expire on November 15, 2004. This Internet-Draft will expire on January 13, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document is part of a family of documents that describes the DNS This document is part of a family of documents that describes the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a Security Extensions (DNSSEC). The DNS Security Extensions are a
collection of resource records and protocol modifications that collection of resource records and protocol modifications that
provide source authentication for the DNS. This document defines the provide source authentication for the DNS. This document defines the
public key (DNSKEY), delegation signer (DS), resource record digital public key (DNSKEY), delegation signer (DS), resource record digital
signature (RRSIG), and authenticated denial of existence (NSEC) signature (RRSIG), and authenticated denial of existence (NSEC)
resource records. The purpose and format of each resource record is resource records. The purpose and format of each resource record is
described in detail, and an example of each resource record is given. described in detail, and an example of each resource record is given.
This document obsoletes RFC 2535 and incorporates changes from all This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535. updates to RFC 2535.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Background and Related Documents . . . . . . . . . . . . . 4 1.1 Background and Related Documents . . . . . . . . . . . . . 4
1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 5
1.3.1 Technical Changes or Corrections . . . . . . . . . . . 4 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 5
1.3.2 Typos and Minor Corrections . . . . . . . . . . . . . 5 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 5
2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 6 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 6
2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 6 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 6
2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 6 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 6
2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 7 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 6
2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 7 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 6
2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 7 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 7
2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 7 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 8
2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 7 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 8
2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 8 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 9
3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 9 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 9
3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 9 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 9
3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 10 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 10
3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 10 3.1.5 Signature Expiration and Inception Fields . . . . . . 10
3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 10 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 10
3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 11 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11
3.1.5 Signature Expiration and Inception Fields . . . . . . 11 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11
3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 11 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12
3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 12 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12
3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 12 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14
3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 13 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14
3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14
4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 15 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 15
4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 15 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 16
4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 15 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 16
4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 16 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 16
4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 17 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18
4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 17 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18
4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 17 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 19
5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 19 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 19
5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 19 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19
5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 20 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 19
5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 20 5.2 Processing of DS RRs When Validating Responses . . . . . . 19
5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 20 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 20
5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 20 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Processing of DS RRs When Validating Responses . . . . . . 20 6. Canonical Form and Order of Resource Records . . . . . . . . . 21
5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 21 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 21
5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 21 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 21
6. Canonical Form and Order of Resource Records . . . . . . . . . 22 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 22
6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 29
10.2 Informative References . . . . . . . . . . . . . . . . . . . 28 A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 29
A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 30 A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 30
A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 30 B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 31
A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 30 B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 32
A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . 33
B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 32
B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 34
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) introduce four new DNS resource The DNS Security Extensions (DNSSEC) introduce four new DNS resource
record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the
purpose of each resource record (RR), the RR's RDATA format, and its purpose of each resource record (RR), the RR's RDATA format, and its
presentation format (ASCII representation). presentation format (ASCII representation).
1.1 Background and Related Documents 1.1 Background and Related Documents
The reader is assumed to be familiar with the basic DNS concepts The reader is assumed to be familiar with the basic DNS concepts
described in [RFC1034], [RFC1035] and subsequent RFCs that update described in [RFC1034], [RFC1035] and subsequent RFCs that update
them: [RFC2136], [RFC2181] and [RFC2308]. them: [RFC2136], [RFC2181] and [RFC2308].
This document is part of a family of documents that define the DNS This document is part of a family of documents that define the DNS
security extensions. The DNS security extensions (DNSSEC) are a security extensions. The DNS security extensions (DNSSEC) are a
collection of resource records and DNS protocol modifications that collection of resource records and DNS protocol modifications that
add source authentication and data integrity to the Domain Name add source authentication and data integrity to the Domain Name
System (DNS). An introduction to DNSSEC and definitions of common System (DNS). An introduction to DNSSEC and definitions of common
terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is
of DNS protocol modifications can be found in assumed to be familiar with this document. A description of DNS
[I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC protocol modifications can be found in
resource records. [I-D.ietf-dnsext-dnssec-protocol].
This document defines the DNSSEC resource records.
1.2 Reserved Words 1.2 Reserved Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.3 Editors' Notes
1.3.1 Technical Changes or Corrections
Please report technical corrections to dnssec-editors@east.isi.edu.
To assist the editors, please indicate the text in error and point
out the RFC that defines the correct behavior. For a technical
change where no RFC that defines the correct behavior, or if there's
more than one applicable RFC and the definitions conflict, please
post the issue to namedroppers.
An example correction to dnssec-editors might be: Page X says
"DNSSEC RRs SHOULD be automatically returned in responses." This was
true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
DNSSEC RR types MUST NOT be included in responses unless the resolver
indicated support for DNSSEC.
1.3.2 Typos and Minor Corrections
Please report any typos corrections to dnssec-editors@east.isi.edu.
To assist the editors, please provide enough context for us to find
the incorrect text quickly.
An example message to dnssec-editors might be: page X says "the
DNSSEC standard has been in development for over 1 years". It
should read "over 10 years".
2. The DNSKEY Resource Record 2. The DNSKEY Resource Record
DNSSEC uses public key cryptography to sign and authenticate DNS DNSSEC uses public key cryptography to sign and authenticate DNS
resource record sets (RRsets). The public keys are stored in DNSKEY resource record sets (RRsets). The public keys are stored in DNSKEY
resource records and are used in the DNSSEC authentication process resource records and are used in the DNSSEC authentication process
described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
authoritative RRsets using a private key and stores the corresponding authoritative RRsets using a private key and stores the corresponding
public key in a DNSKEY RR. A resolver can then use the public key to public key in a DNSKEY RR. A resolver can then use the public key to
authenticate signatures covering the RRsets in the zone. authenticate signatures covering the RRsets in the zone.
skipping to change at page 6, line 45 skipping to change at page 5, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
/ Public Key / / Public Key /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1 The Flags Field 2.1.1 The Flags Field
Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner
name MUST be the name of a zone. If bit 7 has value 0, then the name MUST be the name of a zone. If bit 7 has value 0, then the
DNSKEY record holds some other type of DNS public key, such as a DNSKEY record holds some other type of DNS public key and MUST NOT be
public key used by TKEY and MUST NOT be used to verify RRSIGs that used to verify RRSIGs that cover RRsets.
cover RRsets.
Bit 15 of the Flags field is the Secure Entry Point flag, described Bit 15 of the Flags field is the Secure Entry Point flag, described
in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a
key intended for use as a secure entry point. This flag is only key intended for use as a secure entry point. This flag is only
intended to be to a hint to zone signing or debugging software as to intended to be to a hint to zone signing or debugging software as to
the intended use of this DNSKEY record; validators MUST NOT alter the intended use of this DNSKEY record; validators MUST NOT alter
their behavior during the signature validation process in any way their behavior during the signature validation process in any way
based on the setting of this bit. This also means a DNSKEY RR with based on the setting of this bit. This also means a DNSKEY RR with
the SEP bit set would also need the Zone Key flag set in order to the SEP bit set would also need the Zone Key flag set in order to
legally be able to generate signatures. A DNSKEY RR with the SEP set legally be able to generate signatures. A DNSKEY RR with the SEP set
and the Zone Key flag not set is an invalid DNSKEY. and the Zone Key flag not set MUST NOT be used to verify RRSIGs that
cover RRsets.
Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
creation of the DNSKEY RR, and MUST be ignored upon reception. creation of the DNSKEY RR, and MUST be ignored upon reception.
2.1.2 The Protocol Field 2.1.2 The Protocol Field
The Protocol Field MUST have value 3 and the DNSKEY RR MUST be The Protocol Field MUST have value 3 and the DNSKEY RR MUST be
treated as invalid during signature verification if found to be some treated as invalid during signature verification if found to be some
value other than 3. value other than 3.
skipping to change at page 7, line 43 skipping to change at page 6, line 43
2.1.5 Notes on DNSKEY RDATA Design 2.1.5 Notes on DNSKEY RDATA Design
Although the Protocol Field always has value 3, it is retained for Although the Protocol Field always has value 3, it is retained for
backward compatibility with early versions of the KEY record. backward compatibility with early versions of the KEY record.
2.2 The DNSKEY RR Presentation Format 2.2 The DNSKEY RR Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
The Flag field MUST be represented as an unsigned decimal integer The Flag field MUST be represented as an unsigned decimal integer.
with a value of 0, 256, or 257. Given the currently defined flags, the possible values are: 0, 256,
or 257.
The Protocol Field MUST be represented as an unsigned decimal integer The Protocol Field MUST be represented as an unsigned decimal integer
with a value of 3. with a value of 3.
The Algorithm field MUST be represented either as an unsigned decimal The Algorithm field MUST be represented either as an unsigned decimal
integer or as an algorithm mnemonic as specified in Appendix A.1. integer or as an algorithm mnemonic as specified in Appendix A.1.
The Public Key field MUST be represented as a Base64 encoding of the The Public Key field MUST be represented as a Base64 encoding of the
Public Key. Whitespace is allowed within the Base64 text. For a Public Key. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding, see [RFC1521] Section 5.2. definition of Base64 encoding, see [RFC3548].
2.3 DNSKEY RR Example 2.3 DNSKEY RR Example
The following DNSKEY RR stores a DNS zone key for example.com. The following DNSKEY RR stores a DNS zone key for example.com.
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
Cbl+BBZH4b/0PY1kxkmvHjcZc8no Cbl+BBZH4b/0PY1kxkmvHjcZc8no
kfzj31GajIQKY+5CptLr3buXA10h kfzj31GajIQKY+5CptLr3buXA10h
WqTkF7H6RfoRqXQeogmMHfpftf6z WqTkF7H6RfoRqXQeogmMHfpftf6z
Mv1LyBUgia7za6ZEzOJBOztyvhjL Mv1LyBUgia7za6ZEzOJBOztyvhjL
skipping to change at page 9, line 10 skipping to change at page 8, line 10
Value 5 indicates the public key algorithm. Appendix A.1 identifies Value 5 indicates the public key algorithm. Appendix A.1 identifies
algorithm type 5 as RSA/SHA1 and indicates that the format of the algorithm type 5 as RSA/SHA1 and indicates that the format of the
RSA/SHA1 public key field is defined in [RFC3110]. The remaining RSA/SHA1 public key field is defined in [RFC3110]. The remaining
text is a Base64 encoding of the public key. text is a Base64 encoding of the public key.
3. The RRSIG Resource Record 3. The RRSIG Resource Record
DNSSEC uses public key cryptography to sign and authenticate DNS DNSSEC uses public key cryptography to sign and authenticate DNS
resource record sets (RRsets). Digital signatures are stored in resource record sets (RRsets). Digital signatures are stored in
RRSIG resource records and are used in the DNSSEC authentication RRSIG resource records and are used in the DNSSEC authentication
process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator
can use these RRSIG RRs to authenticate RRsets from the zone. The can use these RRSIG RRs to authenticate RRsets from the zone. The
RRSIG RR MUST only be used to carry verification material (digital RRSIG RR MUST only be used to carry verification material (digital
signatures) used to secure DNS operations. signatures) used to secure DNS operations.
An RRSIG record contains the signature for an RRset with a particular An RRSIG record contains the signature for an RRset with a particular
name, class, and type. The RRSIG RR specifies a validity interval name, class, and type. The RRSIG RR specifies a validity interval
for the signature and uses the Algorithm, the Signer's Name, and the for the signature and uses the Algorithm, the Signer's Name, and the
Key Tag to identify the DNSKEY RR containing the public key that a Key Tag to identify the DNSKEY RR containing the public key that a
validator can use to verify the signature. validator can use to verify the signature.
skipping to change at page 9, line 35 skipping to change at page 8, line 35
the only type allowed at that name. A RRSIG and NSEC (see Section 4) the only type allowed at that name. A RRSIG and NSEC (see Section 4)
MUST exist for the same name as a CNAME resource record in a signed MUST exist for the same name as a CNAME resource record in a signed
zone. zone.
The Type value for the RRSIG RR type is 46. The Type value for the RRSIG RR type is 46.
The RRSIG RR is class independent. The RRSIG RR is class independent.
An RRSIG RR MUST have the same class as the RRset it covers. An RRSIG RR MUST have the same class as the RRset it covers.
The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
it covers. This is an exception to the [RFC2181] rules for TTL covers. This is an exception to the [RFC2181] rules for TTL values
values of individual RRs within a RRset: individual RRSIG with the of individual RRs within a RRset: individual RRSIG with the same
same owner name will have different TTL values if the RRsets they owner name will have different TTL values if the RRsets they cover
cover have different TTL values. have different TTL values.
3.1 RRSIG RDATA Wire Format 3.1 RRSIG RDATA Wire Format
The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
TTL field, a 4 octet Signature Expiration field, a 4 octet Signature TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
Inception field, a 2 octet Key tag, the Signer's Name field, and the Inception field, a 2 octet Key tag, the Signer's Name field, and the
Signature field. Signature field.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
skipping to change at page 10, line 39 skipping to change at page 9, line 39
3.1.2 The Algorithm Number Field 3.1.2 The Algorithm Number Field
The Algorithm Number field identifies the cryptographic algorithm The Algorithm Number field identifies the cryptographic algorithm
used to create the signature. A list of DNSSEC algorithm types can used to create the signature. A list of DNSSEC algorithm types can
be found in Appendix A.1 be found in Appendix A.1
3.1.3 The Labels Field 3.1.3 The Labels Field
The Labels field specifies the number of labels in the original RRSIG The Labels field specifies the number of labels in the original RRSIG
RR owner name. The significance of this field is that a validator RR owner name. The significance of this field is that a validator
uses it to determine if the answer was synthesized from a wildcard. uses it to determine if the answer was synthesized from a wildcard.
If so, it can be used to determine what owner name was used in If so, it can be used to determine what owner name was used in
generating the signature. generating the signature.
To validate a signature, the validator needs the original owner name To validate a signature, the validator needs the original owner name
that was used to create the signature. If the original owner name that was used to create the signature. If the original owner name
contains a wildcard label ("*"), the owner name may have been contains a wildcard label ("*"), the owner name may have been
expanded by the server during the response process, in which case the expanded by the server during the response process, in which case the
validator will need to reconstruct the original owner name in order validator will need to reconstruct the original owner name in order
to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] to validate the signature. [I-D.ietf-dnsext-dnssec-protocol]
describes how to use the Labels field to reconstruct the original describes how to use the Labels field to reconstruct the original
owner name. owner name.
The value of the Labels field MUST NOT count either the null (root) The value of the Labels field MUST NOT count either the null (root)
label that terminates the owner name or the wildcard label (if label that terminates the owner name or the wildcard label (if
present). The value of the Labels field MUST be less than or equal present). The value of the Labels field MUST be less than or equal
skipping to change at page 11, line 23 skipping to change at page 10, line 23
Although the wildcard label is not included in the count stored in Although the wildcard label is not included in the count stored in
the Labels field of the RRSIG RR, the wildcard label is part of the the Labels field of the RRSIG RR, the wildcard label is part of the
RRset's owner name when generating or verifying the signature. RRset's owner name when generating or verifying the signature.
3.1.4 Original TTL Field 3.1.4 Original TTL Field
The Original TTL field specifies the TTL of the covered RRset as it The Original TTL field specifies the TTL of the covered RRset as it
appears in the authoritative zone. appears in the authoritative zone.
The Original TTL field is necessary because a caching resolver The Original TTL field is necessary because a caching resolver
decrements the TTL value of a cached RRset. In order to validate a decrements the TTL value of a cached RRset. In order to validate a
signature, a validator requires the original TTL. signature, a validator requires the original TTL.
[I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
TTL field value to reconstruct the original TTL. TTL field value to reconstruct the original TTL.
3.1.5 Signature Expiration and Inception Fields 3.1.5 Signature Expiration and Inception Fields
The Signature Expiration and Inception fields specify a validity The Signature Expiration and Inception fields specify a validity
period for the signature. The RRSIG record MUST NOT be used for period for the signature. The RRSIG record MUST NOT be used for
authentication prior to the inception date and MUST NOT be used for authentication prior to the inception date and MUST NOT be used for
authentication after the expiration date. authentication after the expiration date.
skipping to change at page 11, line 51 skipping to change at page 10, line 51
Inception field value if the expiration field value is near the Inception field value if the expiration field value is near the
32-bit wrap-around point or if the signature is long lived. Because 32-bit wrap-around point or if the signature is long lived. Because
of this, all comparisons involving these fields MUST use "Serial of this, all comparisons involving these fields MUST use "Serial
number arithmetic" as defined in [RFC1982]. As a direct consequence, number arithmetic" as defined in [RFC1982]. As a direct consequence,
the values contained in these fields cannot refer to dates more than the values contained in these fields cannot refer to dates more than
68 years in either the past or the future. 68 years in either the past or the future.
3.1.6 The Key Tag Field 3.1.6 The Key Tag Field
The Key Tag field contains the key tag value of the DNSKEY RR that The Key Tag field contains the key tag value of the DNSKEY RR that
validates this signature. Appendix B explains how to calculate Key validates this signature, in network byte order. Appendix B explains
Tag values. how to calculate Key Tag values.
3.1.7 The Signer's Name Field 3.1.7 The Signer's Name Field
The Signer's Name field value identifies the owner name of the DNSKEY The Signer's Name field value identifies the owner name of the DNSKEY
RR which a validator should use to validate this signature. The RR which a validator is supposed to use to validate this signature.
Signer's Name field MUST contain the name of the zone of the covered The Signer's Name field MUST contain the name of the zone of the
RRset. A sender MUST NOT use DNS name compression on the Signer's covered RRset. A sender MUST NOT use DNS name compression on the
Name field when transmitting a RRSIG RR. Signer's Name field when transmitting a RRSIG RR.
3.1.8 The Signature Field 3.1.8 The Signature Field
The Signature field contains the cryptographic signature that covers The Signature field contains the cryptographic signature that covers
the RRSIG RDATA (excluding the Signature field) and the RRset the RRSIG RDATA (excluding the Signature field) and the RRset
specified by the RRSIG owner name, RRSIG class, and RRSIG Type specified by the RRSIG owner name, RRSIG class, and RRSIG Type
Covered field. The format of this field depends on the algorithm in Covered field. The format of this field depends on the algorithm in
use and these formats are described in separate companion documents. use and these formats are described in separate companion documents.
3.1.8.1 Signature Calculation 3.1.8.1 Signature Calculation
skipping to change at page 13, line 8 skipping to change at page 12, line 8
RRSIG RR's Type Covered field; RRSIG RR's Type Covered field;
Each RR in the RRset MUST have the TTL listed in the Each RR in the RRset MUST have the TTL listed in the
RRSIG Original TTL Field; RRSIG Original TTL Field;
Any DNS names in the RDATA field of each RR MUST be in Any DNS names in the RDATA field of each RR MUST be in
canonical form; and canonical form; and
The RRset MUST be sorted in canonical order. The RRset MUST be sorted in canonical order.
See Section 6.1 and Section 6.2 for details on canonical name order See Section 6.2 and Section 6.3 for details on canonical form and
and canonical RR form. ordering of RRsets.
3.2 The RRSIG RR Presentation Format 3.2 The RRSIG RR Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
The Type Covered field is represented as a RR type mnemonic. When The Type Covered field is represented as a RR type mnemonic. When
the mnemonic is not known, the TYPE representation as described in the mnemonic is not known, the TYPE representation as described in
[RFC3597] (section 5) MUST be used. [RFC3597] (section 5) MUST be used.
The Algorithm field value MUST be represented either as an unsigned The Algorithm field value MUST be represented either as an unsigned
decimal integer or as an algorithm mnemonic as specified in Appendix decimal integer or as an algorithm mnemonic as specified in Appendix
A.1. A.1.
The Labels field value MUST be represented as an unsigned decimal The Labels field value MUST be represented as an unsigned decimal
integer. integer.
The Original TTL field value MUST be represented as an unsigned The Original TTL field value MUST be represented as an unsigned
decimal integer. decimal integer.
The Signature Expiration Time and Inception Time field values MUST be The Signature Expiration Time and Inception Time field values MUST be
represented either as seconds since 1 January 1970 00:00:00 UTC or in represented either as seconds since 1 January 1970 00:00:00 UTC or in
the form YYYYMMDDHHmmSS in UTC, where: the form YYYYMMDDHHmmSS in UTC, where:
YYYY is the year (0000-9999, but see Section 3.1.5); YYYY is the year (0001-9999, but see Section 3.1.5);
MM is the month number (01-12); MM is the month number (01-12);
DD is the day of the month (01-31); DD is the day of the month (01-31);
HH is the hour in 24 hours notation (00-23); HH is the hour in 24 hours notation (00-23);
mm is the minute (00-59); and mm is the minute (00-59); and
SS is the second (00-59). SS is the second (00-59).
The Key Tag field MUST be represented as an unsigned decimal integer. The Key Tag field MUST be represented as an unsigned decimal integer.
The Signer's Name field value MUST be represented as a domain name. The Signer's Name field value MUST be represented as a domain name.
skipping to change at page 14, line 14 skipping to change at page 13, line 14
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
20030220173103 2642 example.com. 20030220173103 2642 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
The first four fields specify the owner name, TTL, Class, and RR type The first four fields specify the owner name, TTL, Class, and RR type
(RRSIG). The "A" represents the Type Covered field. The value 5 (RRSIG). The "A" represents the Type Covered field. The value 5
identifies the algorithm used (RSA/SHA1) to create the signature. identifies the algorithm used (RSA/SHA1) to create the signature.
The value 3 is the number of Labels in the original owner name. The The value 3 is the number of Labels in the original owner name. The
value 86400 in the RRSIG RDATA is the Original TTL for the covered A value 86400 in the RRSIG RDATA is the Original TTL for the covered A
RRset. 20030322173103 and 20030220173103 are the expiration and RRset. 20030322173103 and 20030220173103 are the expiration and
inception dates, respectively. 2642 is the Key Tag, and example.com. inception dates, respectively. 2642 is the Key Tag, and example.com.
is the Signer's Name. The remaining text is a Base64 encoding of the is the Signer's Name. The remaining text is a Base64 encoding of the
signature. signature.
Note that combination of RRSIG RR owner name, class, and Type Covered Note that combination of RRSIG RR owner name, class, and Type Covered
indicate that this RRSIG covers the "host.example.com" A RRset. The indicate that this RRSIG covers the "host.example.com" A RRset. The
Label value of 3 indicates that no wildcard expansion was used. The Label value of 3 indicates that no wildcard expansion was used. The
Algorithm, Signer's Name, and Key Tag indicate this signature can be Algorithm, Signer's Name, and Key Tag indicate this signature can be
authenticated using an example.com zone DNSKEY RR whose algorithm is authenticated using an example.com zone DNSKEY RR whose algorithm is
5 and key tag is 2642. 5 and key tag is 2642.
4. The NSEC Resource Record 4. The NSEC Resource Record
The NSEC resource record lists two separate things: the owner name of The NSEC resource record lists two separate things: the next owner
the next authoritative RRset in the canonical ordering of the zone, name (in the canonical ordering of the zone) which contains
and the set of RR types present at the NSEC RR's owner name. The authoritative data or a delegation point NS RRset, and the set of RR
complete set of NSEC RRs in a zone both indicate which authoritative types present at the NSEC RR's owner name. The complete set of NSEC
RRsets exist in a zone and also form a chain of authoritative owner RRs in a zone both indicate which authoritative RRsets exist in a
names in the zone. This information is used to provide authenticated zone and also form a chain of authoritative owner names in the zone.
denial of existence for DNS data, as described in This information is used to provide authenticated denial of existence
[I-D.ietf-dnsext-dnssec-protocol]. for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol].
Because every authoritative name in a zone must be part of the NSEC Because every authoritative name in a zone must be part of the NSEC
chain, NSEC RRs must be present for names containing a CNAME RR. chain, NSEC RRs must be present for names containing a CNAME RR.
This is a change to the traditional DNS specification [RFC1034] that This is a change to the traditional DNS specification [RFC1034] that
stated that if a CNAME is present for a name, it is the only type stated that if a CNAME is present for a name, it is the only type
allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist
for the same name as a CNAME resource record in a signed zone. for the same name as a CNAME resource record in a signed zone.
See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone
signer determines precisely which NSEC RRs it needs to include in a signer determines precisely which NSEC RRs it needs to include in a
zone. zone.
The type value for the NSEC RR is 47. The type value for the NSEC RR is 47.
The NSEC RR is class independent. The NSEC RR is class independent.
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
field. This is in the spirit of negative caching [RFC2308]. field. This is in the spirit of negative caching [RFC2308].
4.1 NSEC RDATA Wire Format 4.1 NSEC RDATA Wire Format
The RDATA of the NSEC RR is as shown below: The RDATA of the NSEC RR is as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name / / Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps / / Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1 The Next Domain Name Field 4.1.1 The Next Domain Name Field
The Next Domain Name field contains the owner name of the next The Next Domain field contains the next owner name (in the canonical
authoritative owner name in the canonical ordering of the zone; see ordering of the zone) which has authoritative data or contains a
Section 6.1 for an explanation of canonical ordering. The value of delegation point NS RRset; see Section 6.1 for an explanation of
the Next Domain Name field in the last NSEC record in the zone is the canonical ordering. The value of the Next Domain Name field in the
name of the zone apex (the owner name of the zone's SOA RR). last NSEC record in the zone is the name of the zone apex (the owner
name of the zone's SOA RR). This indicates that the owner name of
the NSEC RR is the last name in the canonical ordering of the zone.
A sender MUST NOT use DNS name compression on the Next Domain Name A sender MUST NOT use DNS name compression on the Next Domain Name
field when transmitting an NSEC RR. field when transmitting an NSEC RR.
Owner names of RRsets not authoritative for the given zone (such as Owner names of RRsets not authoritative for the given zone (such as
glue records) MUST NOT be listed in the Next Domain Name unless at glue records) MUST NOT be listed in the Next Domain Name unless at
least one authoritative RRset exists at the same owner name. least one authoritative RRset exists at the same owner name.
4.1.2 The Type Bit Maps Field 4.1.2 The Type Bit Maps Field
The Type Bit Maps field identifies the RRset types which exist at the The Type Bit Maps field identifies the RRset types which exist at the
NSEC RR's owner name. NSEC RR's owner name.
The RR type space is split into 256 window blocks, each representing The RR type space is split into 256 window blocks, each representing
the low-order 8 bits of the 16-bit RR type space. Each block that has the low-order 8 bits of the 16-bit RR type space. Each block that
at least one active RR type is encoded using a single octet window has at least one active RR type is encoded using a single octet
number (from 0 to 255), a single octet bitmap length (from 1 to 32) window number (from 0 to 255), a single octet bitmap length (from 1
indicating the number of octets used for the window block's bitmap, to 32) indicating the number of octets used for the window block's
and up to 32 octets (256 bits) of bitmap. bitmap, and up to 32 octets (256 bits) of bitmap.
Blocks are present in the NSEC RR RDATA in increasing numerical Blocks are present in the NSEC RR RDATA in increasing numerical
order. order.
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
where "|" denotes concatenation. where "|" denotes concatenation.
Each bitmap encodes the low-order 8 bits of RR types within the Each bitmap encodes the low-order 8 bits of RR types within the
window block, in network bit order. The first bit is bit 0. For window block, in network bit order. The first bit is bit 0. For
window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
to RR type 2 (NS), and so forth. For window block 1, bit 1 to RR type 2 (NS), and so forth. For window block 1, bit 1
corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to corresponds to RR type 257, bit 2 to RR type 258. If a bit is set,
1, it indicates that an RRset of that type is present for the NSEC it indicates that an RRset of that type is present for the NSEC RR's
RR's owner name. If a bit is set to 0, it indicates that no RRset of owner name. If a bit is clear, it indicates that no RRset of that
that type is present for the NSEC RR's owner name. type is present for the NSEC RR's owner name.
Bits representing pseudo-types MUST be set to 0, since they do not Bits representing pseudo-types MUST be clear, since they do not
appear in zone data. If encountered, they MUST be ignored upon appear in zone data. If encountered, they MUST be ignored upon
reading. reading.
Blocks with no types present MUST NOT be included. Trailing zero Blocks with no types present MUST NOT be included. Trailing zero
octets in the bitmap MUST be omitted. The length of each block's octets in the bitmap MUST be omitted. The length of each block's
bitmap is determined by the type code with the largest numerical bitmap is determined by the type code with the largest numerical
value, within that block, among the set of RR types present at the value, within that block, among the set of RR types present at the
NSEC RR's owner name. Trailing zero octets not specified MUST be NSEC RR's owner name. Trailing zero octets not specified MUST be
interpreted as zero octets. interpreted as zero octets.
The bitmap for the NSEC RR at a delegation point requires special The bitmap for the NSEC RR at a delegation point requires special
attention. Bits corresponding to the delegation NS RRset and the RR attention. Bits corresponding to the delegation NS RRset and the RR
types for which the parent zone has authoritative data MUST be set to types for which the parent zone has authoritative data MUST be set;
1; bits corresponding to any non-NS RRset for which the parent is not bits corresponding to any non-NS RRset for which the parent is not
authoritative MUST be set to 0. authoritative MUST be clear.
A zone MUST NOT include an NSEC RR for any domain name that only A zone MUST NOT include an NSEC RR for any domain name that only
holds glue records. holds glue records.
4.1.3 Inclusion of Wildcard Names in NSEC RDATA 4.1.3 Inclusion of Wildcard Names in NSEC RDATA
If a wildcard owner name appears in a zone, the wildcard label ("*") If a wildcard owner name appears in a zone, the wildcard label ("*")
is treated as a literal symbol and is treated the same as any other is treated as a literal symbol and is treated the same as any other
owner name for purposes of generating NSEC RRs. Wildcard owner names owner name for purposes of generating NSEC RRs. Wildcard owner names
appear in the Next Domain Name field without any wildcard expansion. appear in the Next Domain Name field without any wildcard expansion.
skipping to change at page 17, line 36 skipping to change at page 16, line 37
The Next Domain Name field is represented as a domain name. The Next Domain Name field is represented as a domain name.
The Type Bit Maps field is represented as a sequence of RR type The Type Bit Maps field is represented as a sequence of RR type
mnemonics. When the mnemonic is not known, the TYPE representation mnemonics. When the mnemonic is not known, the TYPE representation
as described in [RFC3597] (section 5) MUST be used. as described in [RFC3597] (section 5) MUST be used.
4.3 NSEC RR Example 4.3 NSEC RR Example
The following NSEC RR identifies the RRsets associated with The following NSEC RR identifies the RRsets associated with
alfa.example.com. and identifies the next authoritative name after alfa.example.com. and identifies the next authoritative name after
alfa.example.com. alfa.example.com.
alfa.example.com. 86400 IN NSEC host.example.com. ( alfa.example.com. 86400 IN NSEC host.example.com. (
A MX RRSIG NSEC TYPE1234 ) A MX RRSIG NSEC TYPE1234 )
The first four text fields specify the name, TTL, Class, and RR type The first four text fields specify the name, TTL, Class, and RR type
(NSEC). The entry host.example.com. is the next authoritative name (NSEC). The entry host.example.com. is the next authoritative name
after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
TYPE1234 RRsets associated with the name alfa.example.com. TYPE1234 RRsets associated with the name alfa.example.com.
The RDATA section of the NSEC RR above would be encoded as: The RDATA section of the NSEC RR above would be encoded as:
0x04 'h' 'o' 's' 't' 0x04 'h' 'o' 's' 't'
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
0x03 'c' 'o' 'm' 0x00 0x03 'c' 'o' 'm' 0x00
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
skipping to change at page 19, line 8 skipping to change at page 18, line 8
Assuming that the validator can authenticate this NSEC record, it Assuming that the validator can authenticate this NSEC record, it
could be used to prove that beta.example.com does not exist, or could could be used to prove that beta.example.com does not exist, or could
be used to prove there is no AAAA record associated with be used to prove there is no AAAA record associated with
alfa.example.com. Authenticated denial of existence is discussed in alfa.example.com. Authenticated denial of existence is discussed in
[I-D.ietf-dnsext-dnssec-protocol]. [I-D.ietf-dnsext-dnssec-protocol].
5. The DS Resource Record 5. The DS Resource Record
The DS Resource Record refers to a DNSKEY RR and is used in the DNS The DS Resource Record refers to a DNSKEY RR and is used in the DNS
DNSKEY authentication process. A DS RR refers to a DNSKEY RR by DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
storing the key tag, algorithm number, and a digest of the DNSKEY RR. storing the key tag, algorithm number, and a digest of the DNSKEY RR.
Note that while the digest should be sufficient to identify the Note that while the digest should be sufficient to identify the
public key, storing the key tag and key algorithm helps make the public key, storing the key tag and key algorithm helps make the
identification process more efficient. By authenticating the DS identification process more efficient. By authenticating the DS
record, a resolver can authenticate the DNSKEY RR to which the DS record, a resolver can authenticate the DNSKEY RR to which the DS
record points. The key authentication process is described in record points. The key authentication process is described in
[I-D.ietf-dnsext-dnssec-protocol]. [I-D.ietf-dnsext-dnssec-protocol].
The DS RR and its corresponding DNSKEY RR have the same owner name, The DS RR and its corresponding DNSKEY RR have the same owner name,
but they are stored in different locations. The DS RR appears only but they are stored in different locations. The DS RR appears only
skipping to change at page 20, line 8 skipping to change at page 19, line 8
| Key Tag | Algorithm | Digest Type | | Key Tag | Algorithm | Digest Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ / / /
/ Digest / / Digest /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.1 The Key Tag Field 5.1.1 The Key Tag Field
The Key Tag field lists the key tag of the DNSKEY RR referred to by The Key Tag field lists the key tag of the DNSKEY RR referred to by
the DS record. the DS record, in network byte order.
The Key Tag used by the DS RR is identical to the Key Tag used by The Key Tag used by the DS RR is identical to the Key Tag used by
RRSIG RRs. Appendix B describes how to compute a Key Tag. RRSIG RRs. Appendix B describes how to compute a Key Tag.
5.1.2 The Algorithm Field 5.1.2 The Algorithm Field
The Algorithm field lists the algorithm number of the DNSKEY RR The Algorithm field lists the algorithm number of the DNSKEY RR
referred to by the DS record. referred to by the DS record.
The algorithm number used by the DS RR is identical to the algorithm The algorithm number used by the DS RR is identical to the algorithm
number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the
number types. algorithm number types.
5.1.3 The Digest Type Field 5.1.3 The Digest Type Field
The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
RR. The Digest Type field identifies the algorithm used to construct RR. The Digest Type field identifies the algorithm used to construct
the digest. Appendix A.2 lists the possible digest algorithm types. the digest. Appendix A.2 lists the possible digest algorithm types.
5.1.4 The Digest Field 5.1.4 The Digest Field
The DS record refers to a DNSKEY RR by including a digest of that The DS record refers to a DNSKEY RR by including a digest of that
DNSKEY RR. DNSKEY RR.
The digest is calculated by concatenating the canonical form of the The digest is calculated by concatenating the canonical form of the
fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
and then applying the digest algorithm. and then applying the digest algorithm.
skipping to change at page 20, line 51 skipping to change at page 19, line 51
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
The size of the digest may vary depending on the digest algorithm and The size of the digest may vary depending on the digest algorithm and
DNSKEY RR size. As of the time of writing, the only defined digest DNSKEY RR size. As of the time of writing, the only defined digest
algorithm is SHA-1, which produces a 20 octet digest. algorithm is SHA-1, which produces a 20 octet digest.
5.2 Processing of DS RRs When Validating Responses 5.2 Processing of DS RRs When Validating Responses
The DS RR links the authentication chain across zone boundaries, so The DS RR links the authentication chain across zone boundaries, so
the DS RR requires extra care in processing. The DNSKEY RR referred the DS RR requires extra care in processing. The DNSKEY RR referred
to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST
have Flags bit 7 set to value 1. If the DNSKEY flags do not indicate have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC
a DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in
be used in the validation process. the validation process.
5.3 The DS RR Presentation Format 5.3 The DS RR Presentation Format
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
The Key Tag field MUST be represented as an unsigned decimal integer. The Key Tag field MUST be represented as an unsigned decimal integer.
The Algorithm field MUST be represented either as an unsigned decimal The Algorithm field MUST be represented either as an unsigned decimal
integer or as an algorithm mnemonic specified in Appendix A.1. integer or as an algorithm mnemonic specified in Appendix A.1.
skipping to change at page 21, line 42 skipping to change at page 20, line 42
egXd/M5+X7OrzKBaMbCVdFLU egXd/M5+X7OrzKBaMbCVdFLU
Uh6DhweJBjEVv5f2wwjM9Xzc Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw== ljwvFw==
) ; key id = 60485 ) ; key id = 60485
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
98631FAD1A292118 ) 98631FAD1A292118 )
The first four text fields specify the name, TTL, Class, and RR type The first four text fields specify the name, TTL, Class, and RR type
(DS). Value 60485 is the key tag for the corresponding (DS). Value 60485 is the key tag for the corresponding
"dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
used by this "dskey.example.com." DNSKEY RR. The value 1 is the used by this "dskey.example.com." DNSKEY RR. The value 1 is the
algorithm used to construct the digest, and the rest of the RDATA algorithm used to construct the digest, and the rest of the RDATA
text is the digest in hexadecimal. text is the digest in hexadecimal.
6. Canonical Form and Order of Resource Records 6. Canonical Form and Order of Resource Records
This section defines a canonical form for resource records, a This section defines a canonical form for resource records, a
canonical ordering of DNS names, and a canonical ordering of resource canonical ordering of DNS names, and a canonical ordering of resource
records within an RRset. A canonical name order is required to records within an RRset. A canonical name order is required to
skipping to change at page 24, line 18 skipping to change at page 23, line 18
the protocol parameters used in this document have already been the protocol parameters used in this document have already been
assigned by previous specifications. However, since the evolution of assigned by previous specifications. However, since the evolution of
DNSSEC has been long and somewhat convoluted, this section attempts DNSSEC has been long and somewhat convoluted, this section attempts
to describe the current state of the IANA registries and other to describe the current state of the IANA registries and other
protocol parameters which are (or once were) related to DNSSEC. protocol parameters which are (or once were) related to DNSSEC.
Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA
considerations. considerations.
DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS
Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47,
and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [RFC3755] and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
also marked type 30 (NXT) as Obsolete, and restricted use of types [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted
24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
protocol described in [RFC2931] and the transaction KEY Resource security protocol described in [RFC2931] and the transaction KEY
Record described in [RFC2930]. Resource Record described in [RFC2930].
DNS Security Algorithm Numbers: [RFC2535] created an IANA registry DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
for DNSSEC Resource Record Algorithm field numbers, and assigned for DNSSEC Resource Record Algorithm field numbers, and assigned
values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755]
altered this registry to include flags for each entry regarding altered this registry to include flags for each entry regarding
its use with the DNS security extensions. Each algorithm entry its use with the DNS security extensions. Each algorithm entry
could refer to an algorithm that can be used for zone signing, could refer to an algorithm that can be used for zone signing,
transaction security (see [RFC2931]) or both. Values 6-251 are transaction security (see [RFC2931]) or both. Values 6-251 are
available for assignment by IETF standards action. See Appendix A available for assignment by IETF standards action. See Appendix A
for a full listing of the DNS Security Algorithm Numbers entries for a full listing of the DNS Security Algorithm Numbers entries
at the time of writing and their status of use in DNSSEC. at the time of writing and their status of use in DNSSEC.
[RFC3658] created an IANA registry for DNSSEC DS Digest Types, and [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
assigned value 0 to reserved and value 1 to SHA-1. assigned value 0 to reserved and value 1 to SHA-1.
KEY Protocol Values: [RFC2535] created an IANA Registry for KEY KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
Protocol Values, but [RFC3445] re-assigned all values other than 3 Protocol Values, but [RFC3445] re-assigned all values other than 3
to reserved and closed this IANA registry. The registry remains to reserved and closed this IANA registry. The registry remains
closed, and all KEY and DNSKEY records are required to have closed, and all KEY and DNSKEY records are required to have
Protocol Octet value of 3. Protocol Octet value of 3.
Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
this registry only contains an assignment for bit 7 (the ZONE bit) this registry only contains an assignment for bit 7 (the ZONE bit)
and a reservation for bit 15 for the Secure Entry Point flag (SEP and a reservation for bit 15 for the Secure Entry Point flag (SEP
bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by
IETF Standards Action. IETF Standards Action.
8. Security Considerations 8. Security Considerations
This document describes the format of four DNS resource records used This document describes the format of four DNS resource records used
by the DNS security extensions, and presents an algorithm for by the DNS security extensions, and presents an algorithm for
calculating a key tag for a public key. Other than the items calculating a key tag for a public key. Other than the items
described below, the resource records themselves introduce no described below, the resource records themselves introduce no
security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] security considerations. Please see [I-D.ietf-dnsext-dnssec-intro]
and [I-D.ietf-dnsext-dnssec-protocol] for additional security and [I-D.ietf-dnsext-dnssec-protocol] for additional security
considerations related to the use of these records. considerations related to the use of these records.
The DS record points to a DNSKEY RR using a cryptographic digest, the The DS record points to a DNSKEY RR using a cryptographic digest, the
key algorithm type and a key tag. The DS record is intended to key algorithm type and a key tag. The DS record is intended to
identify an existing DNSKEY RR, but it is theoretically possible for identify an existing DNSKEY RR, but it is theoretically possible for
an attacker to generate a DNSKEY that matches all the DS fields. The an attacker to generate a DNSKEY that matches all the DS fields. The
probability of constructing such a matching DNSKEY depends on the probability of constructing such a matching DNSKEY depends on the
skipping to change at page 26, line 5 skipping to change at page 24, line 33
digest given in a DS record would be a sufficiently difficult problem digest given in a DS record would be a sufficiently difficult problem
that such an attack is not a serious threat at this time. that such an attack is not a serious threat at this time.
The key tag is used to help select DNSKEY resource records The key tag is used to help select DNSKEY resource records
efficiently, but it does not uniquely identify a single DNSKEY efficiently, but it does not uniquely identify a single DNSKEY
resource record. It is possible for two distinct DNSKEY RRs to have resource record. It is possible for two distinct DNSKEY RRs to have
the same owner name, the same algorithm type, and the same key tag. the same owner name, the same algorithm type, and the same key tag.
An implementation which uses only the key tag to select a DNSKEY RR An implementation which uses only the key tag to select a DNSKEY RR
might select the wrong public key in some circumstances. might select the wrong public key in some circumstances.
The table of algorithms in Appendix A and the key tag calculation
algorithms in Appendix B include the RSA/MD5 algorithm for
completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
explained in [RFC3110].
9. Acknowledgments 9. Acknowledgments
This document was created from the input and ideas of the members of This document was created from the input and ideas of the members of
the DNS Extensions Working Group and working group mailing list. The the DNS Extensions Working Group and working group mailing list. The
editors would like to express their thanks for the comments and editors would like to express their thanks for the comments and
suggestions received during the revision of these security extension suggestions received during the revision of these security extension
specifications. While explicitly listing everyone who has specifications. While explicitly listing everyone who has
contributed during the decade during which DNSSEC has been under contributed during the decade during which DNSSEC has been under
development would be an impossible task, development would be an impossible task,
[I-D.ietf-dnsext-dnssec-intro] includes a list of some of the [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the
skipping to change at page 27, line 27 skipping to change at page 26, line 27
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
progress), May 2004. progress), May 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC
1521, September 1993.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997. April 1997.
skipping to change at page 28, line 11 skipping to change at page 27, line 6
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000. SIG(0)s)", RFC 2931, September 2000.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001. Name System (DNS)", RFC 3110, May 2001.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002. Resource Record (RR)", RFC 3445, December 2002.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003. (RR)", RFC 3658, December 2003.
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", RFC 3755, April 2004. Signer", RFC 3755, April 2004.
[RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
Entry Point Flag", RFC 3757, April 2004. Entry Point Flag", RFC 3757, April 2004.
10.2 Informative References 10.2 Informative References
[I-D.ietf-dnsext-nsec-rdata] [I-D.ietf-dnsext-nsec-rdata]
Schlyter, J., "KEY RR Secure Entry Point Flag", Schlyter, J., "DNSSEC NSEC RDATA Format",
draft-ietf-dnsext-nsec-rdata-05 (work in progress), March draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
2004. 2004.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000. RR)", RFC 2930, September 2000.
Authors' Addresses Authors' Addresses
skipping to change at page 30, line 8 skipping to change at page 29, line 8
National Institute for Standards and Technology National Institute for Standards and Technology
100 Bureau Drive 100 Bureau Drive
Gaithersburg, MD 20899-8920 Gaithersburg, MD 20899-8920
USA USA
EMail: scott.rose@nist.gov EMail: scott.rose@nist.gov
Appendix A. DNSSEC Algorithm and Digest Types Appendix A. DNSSEC Algorithm and Digest Types
The DNS security extensions are designed to be independent of the The DNS security extensions are designed to be independent of the
underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS
resource records all use a DNSSEC Algorithm Number to identify the resource records all use a DNSSEC Algorithm Number to identify the
cryptographic algorithm in use by the resource record. The DS cryptographic algorithm in use by the resource record. The DS
resource record also specifies a Digest Algorithm Number to identify resource record also specifies a Digest Algorithm Number to identify
the digest algorithm used to construct the DS record. The currently the digest algorithm used to construct the DS record. The currently
defined Algorithm and Digest Types are listed below. Additional defined Algorithm and Digest Types are listed below. Additional
Algorithm or Digest Types could be added as advances in cryptography Algorithm or Digest Types could be added as advances in cryptography
warrant. warrant.
A DNSSEC aware resolver or name server MUST implement all MANDATORY A DNSSEC aware resolver or name server MUST implement all MANDATORY
algorithms. algorithms.
A.1 DNSSEC Algorithm Types A.1 DNSSEC Algorithm Types
The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify
skipping to change at page 31, line 4 skipping to change at page 30, line 4
254 Private [PRIVATEOID] y see below OPTIONAL 254 Private [PRIVATEOID] y see below OPTIONAL
255 reserved 255 reserved
6 - 251 Available for assignment by IETF Standards Action. 6 - 251 Available for assignment by IETF Standards Action.
A.1.1 Private Algorithm Types A.1.1 Private Algorithm Types
Algorithm number 253 is reserved for private use and will never be Algorithm number 253 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with a wire encoded RR and the signature area in the RRSIG RR begin with a wire encoded
domain name, which MUST NOT be compressed. The domain name indicates domain name, which MUST NOT be compressed. The domain name indicates
the private algorithm to use and the remainder of the public key area the private algorithm to use and the remainder of the public key area
is determined by that algorithm. Entities should only use domain is determined by that algorithm. Entities should only use domain
names they control to designate their private algorithms. names they control to designate their private algorithms.
Algorithm number 254 is reserved for private use and will never be Algorithm number 254 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with an unsigned RR and the signature area in the RRSIG RR begin with an unsigned
length byte followed by a BER encoded Object Identifier (ISO OID) of length byte followed by a BER encoded Object Identifier (ISO OID) of
that length. The OID indicates the private algorithm in use and the that length. The OID indicates the private algorithm in use and the
remainder of the area is whatever is required by that algorithm. remainder of the area is whatever is required by that algorithm.
Entities should only use OIDs they control to designate their private Entities should only use OIDs they control to designate their private
algorithms. algorithms.
A.2 DNSSEC Digest Types A.2 DNSSEC Digest Types
A "Digest Type" field in the DS resource record types identifies the A "Digest Type" field in the DS resource record types identifies the
cryptographic digest algorithm used by the resource record. The cryptographic digest algorithm used by the resource record. The
following table lists the currently defined digest algorithm types. following table lists the currently defined digest algorithm types.
VALUE Algorithm STATUS VALUE Algorithm STATUS
0 Reserved - 0 Reserved -
1 SHA-1 MANDATORY 1 SHA-1 MANDATORY
2-255 Unassigned - 2-255 Unassigned -
Appendix B. Key Tag Calculation Appendix B. Key Tag Calculation
The Key Tag field in the RRSIG and DS resource record types provides The Key Tag field in the RRSIG and DS resource record types provides
a mechanism for selecting a public key efficiently. In most cases, a a mechanism for selecting a public key efficiently. In most cases, a
combination of owner name, algorithm, and key tag can efficiently combination of owner name, algorithm, and key tag can efficiently
identify a DNSKEY record. Both the RRSIG and DS resource records identify a DNSKEY record. Both the RRSIG and DS resource records
have corresponding DNSKEY records. The Key Tag field in the RRSIG have corresponding DNSKEY records. The Key Tag field in the RRSIG
and DS records can be used to help select the corresponding DNSKEY RR and DS records can be used to help select the corresponding DNSKEY RR
efficiently when more than one candidate DNSKEY RR is available. efficiently when more than one candidate DNSKEY RR is available.
However, it is essential to note that the key tag is not a unique However, it is essential to note that the key tag is not a unique
identifier. It is theoretically possible for two distinct DNSKEY RRs identifier. It is theoretically possible for two distinct DNSKEY RRs
to have the same owner name, the same algorithm, and the same key to have the same owner name, the same algorithm, and the same key
tag. The key tag is used to limit the possible candidate keys, but it tag. The key tag is used to limit the possible candidate keys, but
does not uniquely identify a DNSKEY record. Implementations MUST NOT it does not uniquely identify a DNSKEY record. Implementations MUST
assume that the key tag uniquely identifies a DNSKEY RR. NOT assume that the key tag uniquely identifies a DNSKEY RR.
The key tag is the same for all DNSKEY algorithm types except The key tag is the same for all DNSKEY algorithm types except
algorithm 1 (please see Appendix B.1 for the definition of the key algorithm 1 (please see Appendix B.1 for the definition of the key
tag for algorithm 1). The key tag algorithm is the sum of the wire tag for algorithm 1). The key tag algorithm is the sum of the wire
format of the DNSKEY RDATA broken into 2 octet groups. First the format of the DNSKEY RDATA broken into 2 octet groups. First the
RDATA (in wire format) is treated as a series of 2 octet groups, RDATA (in wire format) is treated as a series of 2 octet groups,
these groups are then added together ignoring any carry bits. these groups are then added together ignoring any carry bits.
A reference implementation of the key tag algorithm is as an ANSI C A reference implementation of the key tag algorithm is as an ANSI C
function is given below with the RDATA portion of the DNSKEY RR is function is given below with the RDATA portion of the DNSKEY RR is
skipping to change at page 34, line 8 skipping to change at page 33, line 8
DNSKEY RR with algorithm 1, the key tag is defined to be the most DNSKEY RR with algorithm 1, the key tag is defined to be the most
significant 16 bits of the least significant 24 bits in the public significant 16 bits of the least significant 24 bits in the public
key modulus (in other words, the 4th to last and 3rd to last octets key modulus (in other words, the 4th to last and 3rd to last octets
of the public key modulus). of the public key modulus).
Please note that Algorithm 1 is NOT RECOMMENDED. Please note that Algorithm 1 is NOT RECOMMENDED.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 70 change blocks. 
239 lines changed or deleted 210 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/