1628 lines
62 KiB
Plaintext
1628 lines
62 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group R. Arends
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 1]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 2]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 3]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 4]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 5]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 6]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 7]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 8]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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
|
||
|
||
The Key Tag field contains the key tag value of the DNSKEY RR that
|
||
validates this signature, in network byte order. Appendix B explains
|
||
how to calculate Key Tag values.
|
||
|
||
3.1.7. The Signer's Name Field
|
||
|
||
The Signer's Name field value identifies the owner name of the DNSKEY
|
||
RR that a validator is supposed to use to validate this signature.
|
||
The Signer's Name field MUST contain the name of the zone of the
|
||
covered RRset. A sender MUST NOT use DNS name compression on the
|
||
Signer's Name field when transmitting a RRSIG RR.
|
||
|
||
3.1.8. The Signature Field
|
||
|
||
The Signature field contains the cryptographic signature that covers
|
||
the RRSIG RDATA (excluding the Signature field) and the RRset
|
||
specified by the RRSIG owner name, RRSIG class, and RRSIG Type
|
||
Covered field. The format of this field depends on the algorithm in
|
||
use, and these formats are described in separate companion documents.
|
||
|
||
3.1.8.1. Signature Calculation
|
||
|
||
A signature covers the RRSIG RDATA (excluding the Signature Field)
|
||
and covers the data RRset specified by the RRSIG owner name, RRSIG
|
||
class, and RRSIG Type Covered fields. The RRset is in canonical form
|
||
(see Section 6), and the set RR(1),...RR(n) is signed as follows:
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 9]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
|
||
|
||
"|" denotes concatenation;
|
||
|
||
RRSIG_RDATA is the wire format of the RRSIG RDATA fields
|
||
with the Signer's Name field in canonical form and
|
||
the Signature field excluded;
|
||
|
||
RR(i) = owner | type | class | TTL | RDATA length | RDATA
|
||
|
||
"owner" is the fully qualified owner name of the RRset in
|
||
canonical form (for RRs with wildcard owner names, the
|
||
wildcard label is included in the owner name);
|
||
|
||
Each RR MUST have the same owner name as the RRSIG RR;
|
||
|
||
Each RR MUST have the same class as the RRSIG RR;
|
||
|
||
Each RR in the RRset MUST have the RR type listed in the
|
||
RRSIG RR's Type Covered field;
|
||
|
||
Each RR in the RRset MUST have the TTL listed in the
|
||
RRSIG Original TTL Field;
|
||
|
||
Any DNS names in the RDATA field of each RR MUST be in
|
||
canonical form; and
|
||
|
||
The RRset MUST be sorted in canonical order.
|
||
|
||
See Sections 6.2 and 6.3 for details on canonical form and ordering
|
||
of RRsets.
|
||
|
||
3.2. The RRSIG RR Presentation Format
|
||
|
||
The presentation format of the RDATA portion is as follows:
|
||
|
||
The Type Covered field is represented as an RR type mnemonic. When
|
||
the mnemonic is not known, the TYPE representation as described in
|
||
[RFC3597], Section 5, MUST be used.
|
||
|
||
The Algorithm field value MUST be represented either as an unsigned
|
||
decimal integer or as an algorithm mnemonic, as specified in Appendix
|
||
A.1.
|
||
|
||
The Labels field value MUST be represented as an unsigned decimal
|
||
integer.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 10]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
The Original TTL field value MUST be represented as an unsigned
|
||
decimal integer.
|
||
|
||
The Signature Expiration Time and Inception Time field values MUST be
|
||
represented either as an unsigned decimal integer indicating seconds
|
||
since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
|
||
UTC, where:
|
||
|
||
YYYY is the year (0001-9999, but see Section 3.1.5);
|
||
MM is the month number (01-12);
|
||
DD is the day of the month (01-31);
|
||
HH is the hour, in 24 hour notation (00-23);
|
||
mm is the minute (00-59); and
|
||
SS is the second (00-59).
|
||
|
||
Note that it is always possible to distinguish between these two
|
||
formats because the YYYYMMDDHHmmSS format will always be exactly 14
|
||
digits, while the decimal representation of a 32-bit unsigned integer
|
||
can never be longer than 10 digits.
|
||
|
||
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 Signature field is represented as a Base64 encoding of the
|
||
signature. Whitespace is allowed within the Base64 text. See
|
||
Section 2.2.
|
||
|
||
3.3. RRSIG RR Example
|
||
|
||
The following RRSIG RR stores the signature for the A RRset of
|
||
host.example.com:
|
||
|
||
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
|
||
20030220173103 2642 example.com.
|
||
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
|
||
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
|
||
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
|
||
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
|
||
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
|
||
|
||
The first four fields specify the owner name, TTL, Class, and RR type
|
||
(RRSIG). The "A" represents the Type Covered field. The value 5
|
||
identifies the algorithm used (RSA/SHA1) to create the signature.
|
||
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
|
||
RRset. 20030322173103 and 20030220173103 are the expiration and
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 11]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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
|
||
signature.
|
||
|
||
Note that combination of RRSIG RR owner name, class, and Type Covered
|
||
indicates that this RRSIG covers the "host.example.com" A RRset. The
|
||
Label value of 3 indicates that no wildcard expansion was used. The
|
||
Algorithm, Signer's Name, and Key Tag indicate that this signature
|
||
can be authenticated using an example.com zone DNSKEY RR whose
|
||
algorithm is 5 and whose key tag is 2642.
|
||
|
||
4. The NSEC Resource Record
|
||
|
||
The NSEC resource record lists two separate things: the next owner
|
||
name (in the canonical ordering of the zone) that contains
|
||
authoritative data or a delegation point NS RRset, and the set of RR
|
||
types present at the NSEC RR's owner name [RFC3845]. The complete
|
||
set of NSEC RRs in a zone indicates which authoritative RRsets exist
|
||
in a zone and also form a chain of authoritative owner names in the
|
||
zone. This information is used to provide authenticated denial of
|
||
existence for DNS data, as described in [RFC4035].
|
||
|
||
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.
|
||
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. An RRSIG (see Section 3) and NSEC MUST
|
||
exist for the same name as does a CNAME resource record in a signed
|
||
zone.
|
||
|
||
See [RFC4035] for discussion of how a zone signer determines
|
||
precisely which NSEC RRs it has to include in a zone.
|
||
|
||
The type value for the NSEC RR is 47.
|
||
|
||
The NSEC RR is class independent.
|
||
|
||
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
|
||
field. This is in the spirit of negative caching ([RFC2308]).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 12]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
4.1. NSEC RDATA Wire Format
|
||
|
||
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
|
||
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 /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
/ Type Bit Maps /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
4.1.1. The Next Domain Name Field
|
||
|
||
The Next Domain field contains the next owner name (in the canonical
|
||
ordering of the zone) that has authoritative data or contains a
|
||
delegation point NS RRset; see Section 6.1 for an explanation of
|
||
canonical ordering. The value of the Next Domain Name field in the
|
||
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
|
||
field when transmitting an NSEC RR.
|
||
|
||
Owner names of RRsets for which the given zone is not authoritative
|
||
(such as glue records) MUST NOT be listed in the Next Domain Name
|
||
unless at least one authoritative RRset exists at the same owner
|
||
name.
|
||
|
||
4.1.2. The Type Bit Maps Field
|
||
|
||
The Type Bit Maps field identifies the RRset types that exist at the
|
||
NSEC RR's owner name.
|
||
|
||
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 at least one active RR type is encoded using a single octet
|
||
window number (from 0 to 255), a single octet bitmap length (from 1
|
||
to 32) indicating the number of octets used for the window block's
|
||
bitmap, and up to 32 octets (256 bits) of bitmap.
|
||
|
||
Blocks are present in the NSEC RR RDATA in increasing numerical
|
||
order.
|
||
|
||
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
|
||
|
||
where "|" denotes concatenation.
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 13]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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 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
|
||
corresponds to RR type 257, and bit 2 to RR type 258. If a bit is
|
||
set, it indicates that an RRset of that type is present for the NSEC
|
||
RR's owner name. If a bit is clear, it indicates that no RRset of
|
||
that type is present for the NSEC RR's owner name.
|
||
|
||
Bits representing pseudo-types MUST be clear, as they do not appear
|
||
in zone data. If encountered, they MUST be ignored upon being read.
|
||
|
||
Blocks with no types present MUST NOT be included. Trailing zero
|
||
octets in the bitmap MUST be omitted. The length of each block's
|
||
bitmap is determined by the type code with the largest numerical
|
||
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
|
||
interpreted as zero octets.
|
||
|
||
The bitmap for the NSEC RR at a delegation point requires special
|
||
attention. Bits corresponding to the delegation NS RRset and the RR
|
||
types for which the parent zone has authoritative data MUST be set;
|
||
bits corresponding to any non-NS RRset for which the parent is not
|
||
authoritative MUST be clear.
|
||
|
||
A zone MUST NOT include an NSEC RR for any domain name that only
|
||
holds glue records.
|
||
|
||
4.1.3. Inclusion of Wildcard Names in NSEC RDATA
|
||
|
||
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
|
||
owner name for the purposes of generating NSEC RRs. Wildcard owner
|
||
names appear in the Next Domain Name field without any wildcard
|
||
expansion. [RFC4035] describes the impact of wildcards on
|
||
authenticated denial of existence.
|
||
|
||
4.2. The NSEC RR Presentation Format
|
||
|
||
The presentation format of the RDATA portion is as follows:
|
||
|
||
The Next Domain Name field is represented as a domain name.
|
||
|
||
The Type Bit Maps field is represented as a sequence of RR type
|
||
mnemonics. When the mnemonic is not known, the TYPE representation
|
||
described in [RFC3597], Section 5, MUST be used.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 14]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
4.3. NSEC RR Example
|
||
|
||
The following NSEC RR identifies the RRsets associated with
|
||
alfa.example.com. and identifies the next authoritative name after
|
||
alfa.example.com.
|
||
|
||
alfa.example.com. 86400 IN NSEC host.example.com. (
|
||
A MX RRSIG NSEC TYPE1234 )
|
||
|
||
The first four text fields specify the name, TTL, Class, and RR type
|
||
(NSEC). The entry host.example.com. is the next authoritative name
|
||
after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
|
||
and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
|
||
and TYPE1234 RRsets associated with the name alfa.example.com.
|
||
|
||
The RDATA section of the NSEC RR above would be encoded as:
|
||
|
||
0x04 'h' 'o' 's' 't'
|
||
0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
|
||
0x03 'c' 'o' 'm' 0x00
|
||
0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
|
||
0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
|
||
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
|
||
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
|
||
0x00 0x00 0x00 0x00 0x20
|
||
|
||
Assuming that the validator can authenticate this NSEC record, it
|
||
could be used to prove that beta.example.com does not exist, or to
|
||
prove that there is no AAAA record associated with alfa.example.com.
|
||
Authenticated denial of existence is discussed in [RFC4035].
|
||
|
||
5. The DS Resource Record
|
||
|
||
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
|
||
storing the key tag, algorithm number, and a digest of the DNSKEY RR.
|
||
Note that while the digest should be sufficient to identify the
|
||
public key, storing the key tag and key algorithm helps make the
|
||
identification process more efficient. By authenticating the DS
|
||
record, a resolver can authenticate the DNSKEY RR to which the DS
|
||
record points. The key authentication process is described in
|
||
[RFC4035].
|
||
|
||
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
|
||
on the upper (parental) side of a delegation, and is authoritative
|
||
data in the parent zone. For example, the DS RR for "example.com" is
|
||
stored in the "com" zone (the parent zone) rather than in the
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 15]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
"example.com" zone (the child zone). The corresponding DNSKEY RR is
|
||
stored in the "example.com" zone (the child zone). This simplifies
|
||
DNS zone management and zone signing but introduces special response
|
||
processing requirements for the DS RR; these are described in
|
||
[RFC4035].
|
||
|
||
The type number for the DS record is 43.
|
||
|
||
The DS resource record is class independent.
|
||
|
||
The DS RR has no special TTL requirements.
|
||
|
||
5.1. DS RDATA Wire Format
|
||
|
||
The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
|
||
Algorithm field, a 1 octet Digest Type field, and a Digest 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
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Key Tag | Algorithm | Digest Type |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
/ /
|
||
/ Digest /
|
||
/ /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
5.1.1. The Key Tag Field
|
||
|
||
The Key Tag field lists the key tag of the DNSKEY RR referred to by
|
||
the DS record, in network byte order.
|
||
|
||
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.
|
||
|
||
5.1.2. The Algorithm Field
|
||
|
||
The Algorithm field lists the algorithm number of the DNSKEY RR
|
||
referred to by the DS record.
|
||
|
||
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 types.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 16]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
5.1.3. The Digest Type Field
|
||
|
||
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
|
||
the digest. Appendix A.2 lists the possible digest algorithm types.
|
||
|
||
5.1.4. The Digest Field
|
||
|
||
The DS record refers to a DNSKEY RR by including a digest of that
|
||
DNSKEY RR.
|
||
|
||
The digest is calculated by concatenating the canonical form of the
|
||
fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
|
||
and then applying the digest algorithm.
|
||
|
||
digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
|
||
|
||
"|" denotes concatenation
|
||
|
||
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
|
||
|
||
The size of the digest may vary depending on the digest algorithm and
|
||
DNSKEY RR size. As of the time of this writing, the only defined
|
||
digest algorithm is SHA-1, which produces a 20 octet digest.
|
||
|
||
5.2. Processing of DS RRs When Validating Responses
|
||
|
||
The DS RR links the authentication chain across zone boundaries, so
|
||
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
|
||
have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC
|
||
zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
|
||
used in the validation process.
|
||
|
||
5.3. The DS RR Presentation Format
|
||
|
||
The presentation format of the RDATA portion is as follows:
|
||
|
||
The Key Tag field MUST be represented as an unsigned decimal integer.
|
||
|
||
The Algorithm field MUST be represented either as an unsigned decimal
|
||
integer or as an algorithm mnemonic specified in Appendix A.1.
|
||
|
||
The Digest Type field MUST be represented as an unsigned decimal
|
||
integer.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 17]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
The Digest MUST be represented as a sequence of case-insensitive
|
||
hexadecimal digits. Whitespace is allowed within the hexadecimal
|
||
text.
|
||
|
||
5.4. DS RR Example
|
||
|
||
The following example shows a DNSKEY RR and its corresponding DS RR.
|
||
|
||
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
|
||
fwJr1AYtsmx3TGkJaNXVbfi/
|
||
2pHm822aJ5iI9BMzNXxeYCmZ
|
||
DRD99WYwYqUSdjMmmAphXdvx
|
||
egXd/M5+X7OrzKBaMbCVdFLU
|
||
Uh6DhweJBjEVv5f2wwjM9Xzc
|
||
nOf+EPbtG9DMBmADjFDc2w/r
|
||
ljwvFw==
|
||
) ; key id = 60485
|
||
|
||
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
|
||
98631FAD1A292118 )
|
||
|
||
The first four text fields specify the name, TTL, Class, and RR type
|
||
(DS). Value 60485 is the key tag for the corresponding
|
||
"dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
|
||
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
|
||
text is the digest in hexadecimal.
|
||
|
||
6. Canonical Form and Order of Resource Records
|
||
|
||
This section defines a canonical form for resource records, a
|
||
canonical ordering of DNS names, and a canonical ordering of resource
|
||
records within an RRset. A canonical name order is required to
|
||
construct the NSEC name chain. A canonical RR form and ordering
|
||
within an RRset are required in order to construct and verify RRSIG
|
||
RRs.
|
||
|
||
6.1. Canonical DNS Name Order
|
||
|
||
For the purposes of DNS security, owner names are ordered by treating
|
||
individual labels as unsigned left-justified octet strings. The
|
||
absence of a octet sorts before a zero value octet, and uppercase
|
||
US-ASCII letters are treated as if they were lowercase US-ASCII
|
||
letters.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 18]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
To compute the canonical ordering of a set of DNS names, start by
|
||
sorting the names according to their most significant (rightmost)
|
||
labels. For names in which the most significant label is identical,
|
||
continue sorting according to their next most significant label, and
|
||
so forth.
|
||
|
||
For example, the following names are sorted in canonical DNS name
|
||
order. The most significant label is "example". At this level,
|
||
"example" sorts first, followed by names ending in "a.example", then
|
||
by names ending "z.example". The names within each level are sorted
|
||
in the same way.
|
||
|
||
example
|
||
a.example
|
||
yljkjljk.a.example
|
||
Z.a.example
|
||
zABC.a.EXAMPLE
|
||
z.example
|
||
\001.z.example
|
||
*.z.example
|
||
\200.z.example
|
||
|
||
6.2. Canonical RR Form
|
||
|
||
For the purposes of DNS security, the canonical form of an RR is the
|
||
wire format of the RR where:
|
||
|
||
1. every domain name in the RR is fully expanded (no DNS name
|
||
compression) and fully qualified;
|
||
|
||
2. all uppercase US-ASCII letters in the owner name of the RR are
|
||
replaced by the corresponding lowercase US-ASCII letters;
|
||
|
||
3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
|
||
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
|
||
SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
|
||
the DNS names contained within the RDATA are replaced by the
|
||
corresponding lowercase US-ASCII letters;
|
||
|
||
4. if the owner name of the RR is a wildcard name, the owner name is
|
||
in its original unexpanded form, including the "*" label (no
|
||
wildcard substitution); and
|
||
|
||
5. the RR's TTL is set to its original value as it appears in the
|
||
originating authoritative zone or the Original TTL field of the
|
||
covering RRSIG RR.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 19]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
6.3. Canonical RR Ordering within an RRset
|
||
|
||
For the purposes of DNS security, RRs with the same owner name,
|
||
class, and type are sorted by treating the RDATA portion of the
|
||
canonical form of each RR as a left-justified unsigned octet sequence
|
||
in which the absence of an octet sorts before a zero octet.
|
||
|
||
[RFC2181] specifies that an RRset is not allowed to contain duplicate
|
||
records (multiple RRs with the same owner name, class, type, and
|
||
RDATA). Therefore, if an implementation detects duplicate RRs when
|
||
putting the RRset in canonical form, it MUST treat this as a protocol
|
||
error. If the implementation chooses to handle this protocol error
|
||
in the spirit of the robustness principle (being liberal in what it
|
||
accepts), it MUST remove all but one of the duplicate RR(s) for the
|
||
purposes of calculating the canonical form of the RRset.
|
||
|
||
7. IANA Considerations
|
||
|
||
This document introduces no new IANA considerations, as all of the
|
||
protocol parameters used in this document have already been assigned
|
||
by previous specifications. However, since the evolution of DNSSEC
|
||
has been long and somewhat convoluted, this section attempts to
|
||
describe the current state of the IANA registries and other protocol
|
||
parameters that are (or once were) related to DNSSEC.
|
||
|
||
Please refer to [RFC4035] for additional IANA considerations.
|
||
|
||
DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
|
||
the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS
|
||
Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47,
|
||
and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
|
||
[RFC3755] also marked type 30 (NXT) as Obsolete and restricted use
|
||
of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
|
||
security protocol described in [RFC2931] and to the transaction
|
||
KEY Resource Record described in [RFC2930].
|
||
|
||
DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
|
||
for DNSSEC Resource Record Algorithm field numbers and assigned
|
||
values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755]
|
||
altered this registry to include flags for each entry regarding
|
||
its use with the DNS security extensions. Each algorithm entry
|
||
could refer to an algorithm that can be used for zone signing,
|
||
transaction security (see [RFC2931]), or both. Values 6-251 are
|
||
available for assignment by IETF standards action ([RFC3755]).
|
||
See Appendix A for a full listing of the DNS Security Algorithm
|
||
Numbers entries at the time of this writing and their status for
|
||
use in DNSSEC.
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 20]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
[RFC3658] created an IANA registry for DNSSEC DS Digest Types and
|
||
assigned value 0 to reserved and value 1 to SHA-1.
|
||
|
||
KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
|
||
Protocol Values, but [RFC3445] reassigned all values other than 3
|
||
to reserved and closed this IANA registry. The registry remains
|
||
closed, and all KEY and DNSKEY records are required to have a
|
||
Protocol Octet value of 3.
|
||
|
||
Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
|
||
registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
|
||
this registry only contains assignments for bit 7 (the ZONE bit)
|
||
and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
|
||
As stated in [RFC3755], bits 0-6 and 8-14 are available for
|
||
assignment by IETF Standards Action.
|
||
|
||
8. Security Considerations
|
||
|
||
This document describes the format of four DNS resource records used
|
||
by the DNS security extensions and presents an algorithm for
|
||
calculating a key tag for a public key. Other than the items
|
||
described below, the resource records themselves introduce no
|
||
security considerations. Please see [RFC4033] and [RFC4035] for
|
||
additional security considerations related to the use of these
|
||
records.
|
||
|
||
The DS record points to a DNSKEY RR by using a cryptographic digest,
|
||
the key algorithm type, and a key tag. The DS record is intended to
|
||
identify an existing DNSKEY RR, but it is theoretically possible for
|
||
an attacker to generate a DNSKEY that matches all the DS fields. The
|
||
probability of constructing a matching DNSKEY depends on the type of
|
||
digest algorithm in use. The only currently defined digest algorithm
|
||
is SHA-1, and the working group believes that constructing a public
|
||
key that would match the algorithm, key tag, and SHA-1 digest given
|
||
in a DS record would be a sufficiently difficult problem that such an
|
||
attack is not a serious threat at this time.
|
||
|
||
The key tag is used to help select DNSKEY resource records
|
||
efficiently, but it does not uniquely identify a single DNSKEY
|
||
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.
|
||
An implementation that uses only the key tag to select a DNSKEY RR
|
||
might select the wrong public key in some circumstances. Please see
|
||
Appendix B for further details.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 21]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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. Acknowledgements
|
||
|
||
This document was created from the input and ideas of the members of
|
||
the DNS Extensions Working Group and working group mailing list. The
|
||
editors would like to express their thanks for the comments and
|
||
suggestions received during the revision of these security extension
|
||
specifications. Although explicitly listing everyone who has
|
||
contributed during the decade in which DNSSEC has been under
|
||
development would be impossible, [RFC4033] includes a list of some of
|
||
the participants who were kind enough to comment on these documents.
|
||
|
||
10. References
|
||
|
||
10.1. Normative References
|
||
|
||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
[RFC1035] Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
|
||
August 1996.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
|
||
NCACHE)", RFC 2308, March 1998.
|
||
|
||
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
|
||
System (DNS)", RFC 2536, March 1999.
|
||
|
||
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
|
||
( SIG(0)s )", RFC 2931, September 2000.
|
||
|
||
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
|
||
Domain Name System (DNS)", RFC 3110, May 2001.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 22]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
|
||
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
|
||
(RR) Types", RFC 3597, September 2003.
|
||
|
||
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
|
||
(RR)", RFC 3658, December 2003.
|
||
|
||
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
|
||
Signer (DS)", RFC 3755, May 2004.
|
||
|
||
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
|
||
System KEY (DNSKEY) Resource Record (RR) Secure Entry
|
||
Point (SEP) Flag", RFC 3757, April 2004.
|
||
|
||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "DNS Security Introduction and Requirements", RFC
|
||
4033, March 2005.
|
||
|
||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Protocol Modifications for the DNS Security
|
||
Extensions", RFC 4035, March 2005.
|
||
|
||
10.2. Informative References
|
||
|
||
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
|
||
Extensions", RFC 2535, March 1999.
|
||
|
||
[RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
|
||
Name System (DNS)", RFC 2537, March 1999.
|
||
|
||
[RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
|
||
Domain Name System (DNS)", RFC 2539, March 1999.
|
||
|
||
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
|
||
RR)", RFC 2930, September 2000.
|
||
|
||
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
|
||
RDATA Format", RFC 3845, August 2004.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 23]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
Appendix A. DNSSEC Algorithm and Digest Types
|
||
|
||
The DNS security extensions are designed to be independent of the
|
||
underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS
|
||
resource records all use a DNSSEC Algorithm Number to identify the
|
||
cryptographic algorithm in use by the resource record. The DS
|
||
resource record also specifies a Digest Algorithm Number to identify
|
||
the digest algorithm used to construct the DS record. The currently
|
||
defined Algorithm and Digest Types are listed below. Additional
|
||
Algorithm or Digest Types could be added as advances in cryptography
|
||
warrant them.
|
||
|
||
A DNSSEC aware resolver or name server MUST implement all MANDATORY
|
||
algorithms.
|
||
|
||
A.1. DNSSEC Algorithm Types
|
||
|
||
The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
|
||
security algorithm being used. These values are stored in the
|
||
"Algorithm number" field in the resource record RDATA.
|
||
|
||
Some algorithms are usable only for zone signing (DNSSEC), some only
|
||
for transaction security mechanisms (SIG(0) and TSIG), and some for
|
||
both. Those usable for zone signing may appear in DNSKEY, RRSIG, and
|
||
DS RRs. Those usable for transaction security would be present in
|
||
SIG(0) and KEY RRs, as described in [RFC2931].
|
||
|
||
Zone
|
||
Value Algorithm [Mnemonic] Signing References Status
|
||
----- -------------------- --------- ---------- ---------
|
||
0 reserved
|
||
1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
|
||
2 Diffie-Hellman [DH] n [RFC2539] -
|
||
3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
|
||
4 Elliptic Curve [ECC] TBA -
|
||
5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
|
||
252 Indirect [INDIRECT] n -
|
||
253 Private [PRIVATEDNS] y see below OPTIONAL
|
||
254 Private [PRIVATEOID] y see below OPTIONAL
|
||
255 reserved
|
||
|
||
6 - 251 Available for assignment by IETF Standards Action.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 24]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
A.1.1. Private Algorithm Types
|
||
|
||
Algorithm number 253 is reserved for private use and will never be
|
||
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
|
||
domain name, which MUST NOT be compressed. The domain name indicates
|
||
the private algorithm to use, and the remainder of the public key
|
||
area is determined by that algorithm. Entities should only use
|
||
domain names they control to designate their private algorithms.
|
||
|
||
Algorithm number 254 is reserved for private use and will never be
|
||
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
|
||
length byte followed by a BER encoded Object Identifier (ISO OID) of
|
||
that length. The OID indicates the private algorithm in use, and the
|
||
remainder of the area is whatever is required by that algorithm.
|
||
Entities should only use OIDs they control to designate their private
|
||
algorithms.
|
||
|
||
A.2. DNSSEC Digest Types
|
||
|
||
A "Digest Type" field in the DS resource record types identifies the
|
||
cryptographic digest algorithm used by the resource record. The
|
||
following table lists the currently defined digest algorithm types.
|
||
|
||
VALUE Algorithm STATUS
|
||
0 Reserved -
|
||
1 SHA-1 MANDATORY
|
||
2-255 Unassigned -
|
||
|
||
Appendix B. Key Tag Calculation
|
||
|
||
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
|
||
combination of owner name, algorithm, and key tag can efficiently
|
||
identify a DNSKEY record. Both the RRSIG and DS resource records
|
||
have corresponding DNSKEY records. The Key Tag field in the RRSIG
|
||
and DS records can be used to help select the corresponding DNSKEY RR
|
||
efficiently when more than one candidate DNSKEY RR is available.
|
||
|
||
However, it is essential to note that the key tag is not a unique
|
||
identifier. It is theoretically possible for two distinct DNSKEY RRs
|
||
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 does not uniquely identify a DNSKEY record. Implementations MUST
|
||
NOT assume that the key tag uniquely identifies a DNSKEY RR.
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 25]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
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
|
||
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
|
||
RDATA (in wire format) is treated as a series of 2 octet groups.
|
||
These groups are then added together, ignoring any carry bits.
|
||
|
||
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
|
||
used as input. It is not necessary to use the following reference
|
||
code verbatim, but the numerical value of the Key Tag MUST be
|
||
identical to what the reference implementation would generate for the
|
||
same input.
|
||
|
||
Please note that the algorithm for calculating the Key Tag is almost
|
||
but not completely identical to the familiar ones-complement checksum
|
||
used in many other Internet protocols. Key Tags MUST be calculated
|
||
using the algorithm described here rather than the ones complement
|
||
checksum.
|
||
|
||
The following ANSI C reference implementation calculates the value of
|
||
a Key Tag. This reference implementation applies to all algorithm
|
||
types except algorithm 1 (see Appendix B.1). The input is the wire
|
||
format of the RDATA portion of the DNSKEY RR. The code is written
|
||
for clarity, not efficiency.
|
||
|
||
/*
|
||
* Assumes that int is at least 16 bits.
|
||
* First octet of the key tag is the most significant 8 bits of the
|
||
* return value;
|
||
* Second octet of the key tag is the least significant 8 bits of the
|
||
* return value.
|
||
*/
|
||
|
||
unsigned int
|
||
keytag (
|
||
unsigned char key[], /* the RDATA part of the DNSKEY RR */
|
||
unsigned int keysize /* the RDLENGTH */
|
||
)
|
||
{
|
||
unsigned long ac; /* assumed to be 32 bits or larger */
|
||
int i; /* loop index */
|
||
|
||
for ( ac = 0, i = 0; i < keysize; ++i )
|
||
ac += (i & 1) ? key[i] : key[i] << 8;
|
||
ac += (ac >> 16) & 0xFFFF;
|
||
return ac & 0xFFFF;
|
||
}
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 26]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
B.1. Key Tag for Algorithm 1 (RSA/MD5)
|
||
|
||
The key tag for algorithm 1 (RSA/MD5) is defined differently from the
|
||
key tag for all other algorithms, for historical reasons. For a
|
||
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
|
||
key modulus (in other words, the 4th to last and 3rd to last octets
|
||
of the public key modulus).
|
||
|
||
Please note that Algorithm 1 is NOT RECOMMENDED.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 27]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Roy Arends
|
||
Telematica Instituut
|
||
Brouwerijstraat 1
|
||
7523 XC Enschede
|
||
NL
|
||
|
||
EMail: roy.arends@telin.nl
|
||
|
||
|
||
Rob Austein
|
||
Internet Systems Consortium
|
||
950 Charter Street
|
||
Redwood City, CA 94063
|
||
USA
|
||
|
||
EMail: sra@isc.org
|
||
|
||
|
||
Matt Larson
|
||
VeriSign, Inc.
|
||
21345 Ridgetop Circle
|
||
Dulles, VA 20166-6503
|
||
USA
|
||
|
||
EMail: mlarson@verisign.com
|
||
|
||
|
||
Dan Massey
|
||
Colorado State University
|
||
Department of Computer Science
|
||
Fort Collins, CO 80523-1873
|
||
|
||
EMail: massey@cs.colostate.edu
|
||
|
||
|
||
Scott Rose
|
||
National Institute for Standards and Technology
|
||
100 Bureau Drive
|
||
Gaithersburg, MD 20899-8920
|
||
USA
|
||
|
||
EMail: scott.rose@nist.gov
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 28]
|
||
|
||
RFC 4034 DNSSEC Resource Records March 2005
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2005).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING 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.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
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
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at ietf-
|
||
ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Arends, et al. Standards Track [Page 29]
|
||
|