Request for Comments: 4034 Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
3755, 3757, 3845 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
Resource Records for the DNS Security Extensions
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document is part of a family of documents that describe the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a
collection of resource records and protocol modifications that
provide source authentication for the DNS. This document defines the
public key (DNSKEY), delegation signer (DS), resource record digital
signature (RRSIG), and authenticated denial of existence (NSEC)
resource records. The purpose and format of each resource record is
described in detail, and an example of each resource record is given.
This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Related Documents . . . . . . . . . . . 3
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3
2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4
2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4
2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4
2.1.2. The Protocol Field . . . . . . . . . . . . . . 5
2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5
2.1.4. The Public Key Field . . . . . . . . . . . . . 5
2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5
2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5
2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6
3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6
3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7
3.1.1. The Type Covered Field . . . . . . . . . . . . 7
3.1.2. The Algorithm Number Field . . . . . . . . . . 8
3.1.3. The Labels Field . . . . . . . . . . . . . . . 8
3.1.4. Original TTL Field . . . . . . . . . . . . . . 8
3.1.5. Signature Expiration and Inception Fields. . . 9
3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9
3.1.7. The Signer’s Name Field. . . . . . . . . . . . 9
3.1.8. The Signature Field. . . . . . . . . . . . . . 9
3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10
3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
4.1.1. The Next Domain Name Field . . . . . . . . . . 13
4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13
4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14
4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14
4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16
5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16
5.1.3. The Digest Type Field. . . . . . . . . . . . . 17
5.1.4. The Digest Field . . . . . . . . . . . . . . . 17
5.2. Processing of DS RRs When Validating Responses . . . . 17
5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17
5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
6. Canonical Form and Order of Resource Records . . . . . . . . 18
6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18
6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations. . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . 23
A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
A.1.1. Private Algorithm Types. . . . . . . . . . . . 25
A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
The DNS Security Extensions (DNSSEC) introduce four new DNS resource
record types: DNS Public Key (DNSKEY), Resource Record Signature
(RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This
document defines the purpose of each resource record (RR), the RR’s
RDATA format, and its presentation format (ASCII representation).
1.1. Background and Related Documents
This document is part of a family of documents defining DNSSEC, which
should be read together as a set.
[RFC4033] contains an introduction to DNSSEC and definition of common
terms; the reader is assumed to be familiar with this document.
[RFC4033] also contains a list of other documents updated by and
obsoleted by this document set.
[RFC4035] defines the DNSSEC protocol operations.
The reader is also assumed to be familiar with the basic DNS concepts
described in [RFC1034], [RFC1035], and the subsequent documents that
update them, particularly [RFC2181] and [RFC2308].
This document defines the DNSSEC resource records. All numeric DNS
type codes given in this document are decimal integers.
1.2. Reserved Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. The DNSKEY Resource Record
DNSSEC uses public key cryptography to sign and authenticate DNS
resource record sets (RRsets). The public keys are stored in DNSKEY
resource records and are used in the DNSSEC authentication process
described in [RFC4035]: A zone signs its authoritative RRsets by
using a private key and stores the corresponding public key in a
DNSKEY RR. A resolver can then use the public key to validate
signatures covering the RRsets in the zone, and thus to authenticate
them.
The DNSKEY RR is not intended as a record for storing arbitrary
public keys and MUST NOT be used to store certificates or public keys
that do not directly relate to the DNS infrastructure.
The Type value for the DNSKEY RR type is 48.
The DNSKEY RR is class independent.
The DNSKEY RR has no special TTL requirements.
2.1. DNSKEY RDATA Wire Format
The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
Field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Public Key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1. The Flags Field
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 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 and MUST
NOT be used to verify RRSIGs that cover RRsets.
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
key intended for use as a secure entry point. This flag is only
intended to be a hint to zone signing or debugging software as to the
intended use of this DNSKEY record; validators MUST NOT alter their
behavior during the signature validation process in any way based on
the setting of this bit. This also means that a DNSKEY RR with the
SEP bit set would also need the Zone Key flag set in order to be able
to generate signatures legally. A DNSKEY RR with the SEP set 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
creation of the DNSKEY RR and MUST be ignored upon receipt.
2.1.2. The Protocol Field
The Protocol Field MUST have value 3, and the DNSKEY RR MUST be
treated as invalid during signature verification if it is found to be
some value other than 3.
2.1.3. The Algorithm Field
The Algorithm field identifies the public key’s cryptographic
algorithm and determines the format of the Public Key field. A list
of DNSSEC algorithm types can be found in Appendix A.1
2.1.4. The Public Key Field
The Public Key Field holds the public key material. The format
depends on the algorithm of the key being stored and is described in
separate documents.
2.1.5. Notes on DNSKEY RDATA Design
Although the Protocol Field always has value 3, it is retained for
backward compatibility with early versions of the KEY record.
2.2. The DNSKEY RR Presentation Format
The presentation format of the RDATA portion is as follows:
The Flag field MUST be represented as an unsigned decimal integer.
Given the currently defined flags, the possible values are: 0, 256,
and 257.
The Protocol Field MUST be represented as an unsigned decimal integer
with a value of 3.
The Algorithm field MUST be represented either as an unsigned decimal
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
Public Key. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding, see [RFC3548].
2.3. DNSKEY RR Example
The following DNSKEY RR stores a DNS zone key for example.com.
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
Cbl+BBZH4b/0PY1kxkmvHjcZc8no
kfzj31GajIQKY+5CptLr3buXA10h
WqTkF7H6RfoRqXQeogmMHfpftf6z
Mv1LyBUgia7za6ZEzOJBOztyvhjL
742iU/TpPSEDhm2SNKLijfUppn1U
aNvv4w== )
The first four text fields specify the owner name, TTL, Class, and RR
type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in
the Flags field has value 1. Value 3 is the fixed Protocol value.
Value 5 indicates the public key algorithm. Appendix A.1 identifies
algorithm type 5 as RSA/SHA1 and indicates that the format of the
RSA/SHA1 public key field is defined in [RFC3110]. The remaining
text is a Base64 encoding of the public key.
3. The RRSIG Resource Record
DNSSEC uses public key cryptography to sign and authenticate DNS
resource record sets (RRsets). Digital signatures are stored in
RRSIG resource records and are used in the DNSSEC authentication
process described in [RFC4035]. A validator can use these RRSIG RRs
to authenticate RRsets from the zone. The RRSIG RR MUST only be used
to carry verification material (digital signatures) used to secure
DNS operations.
An RRSIG record contains the signature for an RRset with a particular
name, class, and type. The RRSIG RR specifies a validity interval
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
validator can use to verify the signature.
Because every authoritative RRset in a zone must be protected by a
digital signature, RRSIG RRs must be present for names containing a
CNAME RR. This is a change to the traditional DNS specification
[RFC1034], which stated that if a CNAME is present for a name, it is
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
zone.
The Type value for the RRSIG RR type is 46.
The RRSIG RR is class independent.
An RRSIG RR MUST have the same class as the RRset it covers.
The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
covers. This is an exception to the [RFC2181] rules for TTL values
of individual RRs within a RRset: individual RRSIG RRs with the same
owner name will have different TTL values if the RRsets they cover
have different TTL values.
3.1. RRSIG RDATA Wire Format
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
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
Signature field.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer’s Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1. The Type Covered Field
The Type Covered field identifies the type of the RRset that is
covered by this RRSIG record.
3.1.2. The Algorithm Number Field
The Algorithm Number field identifies the cryptographic algorithm
used to create the signature. A list of DNSSEC algorithm types can
be found in Appendix A.1
3.1.3. The Labels Field
The Labels field specifies the number of labels in the original RRSIG
RR owner name. The significance of this field is that a validator
uses it to determine whether the answer was synthesized from a
wildcard. If so, it can be used to determine what owner name was
used in generating the signature.
To validate a signature, the validator needs 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
expanded by the server during the response process, in which case the
validator will have to reconstruct the original owner name in order
to validate the signature. [RFC4035] describes how to use the Labels
field to reconstruct the original owner name.
The value of the Labels field MUST NOT count either the null (root)
label that terminates the owner name or the wildcard label (if
present). The value of the Labels field MUST be less than or equal
to the number of labels in the RRSIG owner name. For example,
"www.example.com." has a Labels field value of 3, and
"*.example.com." has a Labels field value of 2. Root (".") has a
Labels field value of 0.
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
RRset’s owner name when the signature is generated or verified.
3.1.4. Original TTL Field
The Original TTL field specifies the TTL of the covered RRset as it
appears in the authoritative zone.
The Original TTL field is necessary because a caching resolver
decrements the TTL value of a cached RRset. In order to validate a
signature, a validator requires the original TTL. [RFC4035]
describes how to use the Original TTL field value to reconstruct the
original TTL.
3.1.5. Signature Expiration and Inception Fields
The Signature Expiration and Inception fields specify a validity
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 after the expiration date.
The Signature Expiration and Inception field values specify a date
and time in the form of a 32-bit unsigned number of seconds elapsed
since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
byte order. The longest interval that can be expressed by this
format without wrapping is approximately 136 years. An RRSIG RR can
have an Expiration field value that is numerically smaller than 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
of this, all comparisons involving these fields MUST use "Serial
number arithmetic", as defined in [RFC1982]. As a direct
consequence, the values contained in these fields cannot refer to
dates more than 68 years in either the past or the future.
3.1.6. The Key Tag Field