< draft-ietf-dnsext-dnssec-records-02.txt   draft-ietf-dnsext-dnssec-records-03.txt >
Network Working Group R. Arends DNS Extensions R. Arends
Internet-Draft Internet-Draft Telematica Instituut
Expires: April 29, 2003 M. Larson Expires: August 26, 2003 R. Austein
ISC
M. Larson
VeriSign VeriSign
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
October 29, 2002 February 25, 2003
Resource Records for the DNS Security Extensions Resource Records for the DNS Security Extensions
draft-ietf-dnsext-dnssec-records-02 draft-ietf-dnsext-dnssec-records-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 39
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 http://
www.ietf.org/ietf/1id-abstracts.txt. 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 April 29, 2003. This Internet-Draft will expire on August 26, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document is part of a family of documents that describe 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
KEY, DS, SIG, and NXT resource records. The purpose and format of KEY, DS, SIG, and NXT resource records. The purpose and format of
each resource record is descibed in detail and an example of each each resource record is described in detail and an example of each
resource record is given. resource record is given.
This document obsoletes RFC 2535 and incorporates changes from all
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 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . 4 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . 4 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . 5 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
2. The KEY Resource Record . . . . . . . . . . . . . . . . . 6 2. The KEY Resource Record . . . . . . . . . . . . . . . . . . 6
2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . . 6
2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 7 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 7 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . 7 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7
2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7 2.1.5 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . . 7
2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . 7 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . . 7
3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9 2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9 3. The SIG Resource Record . . . . . . . . . . . . . . . . . . 9
3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10 3.1 SIG RDATA Wire Format . . . . . . . . . . . . . . . . . . . 9
3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10
3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10
3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10
3.1.5 Signature Expiration and Inception Fields . . . . . . . . 11 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11
3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 11 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11
3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11
3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11
3.2 Calculating A Signature . . . . . . . . . . . . . . . . . 12 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Calculating An RRset Signature . . . . . . . . . . . . . . 12 3.2 The SIG RR Presentation Format . . . . . . . . . . . . . . . 12
3.2.2 Calculating An Transaction Signature . . . . . . . . . . . 12 3.3 SIG RR Example . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 The SIG RR Presentation Format . . . . . . . . . . . . . . 13 4. The NXT Resource Record . . . . . . . . . . . . . . . . . . 15
3.4 Example of a SIG RR . . . . . . . . . . . . . . . . . . . 13 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15
4. The NXT Resource Record . . . . . . . . . . . . . . . . . 15 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15
4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 15 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 15
4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 15 4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . . 16
4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 16 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . . 16
4.1.2.1 Alternate Formats for the Type Bit Map Field . . . . . . . 16 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . 16 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18
4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 16 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18
4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 18
5. The DS Resource Record . . . . . . . . . . . . . . . . . . 18 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19
5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19
5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 18 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 19 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . . 19
5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 19 5.3 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 19 6. Canonical Form and Order of Resource Records . . . . . . . . 21
5.2 The DS RR Presentation Format . . . . . . . . . . . . . . 19 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21
5.3 DS Record Example . . . . . . . . . . . . . . . . . . . . 20 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 21 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . 24
References . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 25 Normative References . . . . . . . . . . . . . . . . . . . . 26
A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . 26 Informative References . . . . . . . . . . . . . . . . . . . 27
A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
A.1.1 Indiret and Private Algorithm Types . . . . . . . . . . . 26 A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 29
A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 27 A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 29
B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 28 A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 29
B.1 Key Tag for Algorithm 1 - RSA/MD5 . . . . . . . . . . . . 29 A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 30
C. Canonical Form and Order of Resource Records . . . . . . 30 B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 31
C.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 30 B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 32
C.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 30 Full Copyright Statement . . . . . . . . . . . . . . . . . . 33
C.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 31
C.4 Canonical Ordering of RR Types . . . . . . . . . . . . . . 31
Full Copyright Statement . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC) introduce four resource records: The DNS Security Extensions (DNSSEC) introduce four new DNS resource
the KEY, SIG, NXT, and DS resource records. This document defines record types: KEY, SIG, NXT, and DS. This document defines the
the purpose of each resource record (RR), the RR's RDATA format, and purpose of each resource record (RR), the RR's RDATA format, and its
its ASCII representation. An example of each RR type is also given. 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
described in RFC1034 [1] and RFC1035 [2].
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 the Domain Name System (DNS). An add source authentication the Domain Name System (DNS). An
introduction to DNSSEC and definition of common terms can be found in introduction to DNSSEC and definition of common terms can be found in
[13]. A description of DNS protocol modifications can be found in [10]. A description of DNS protocol modifications can be found in
[14]. This document defines the DNSSEC resource records. [11]. This document defines the DNSSEC resource records.
The reader to assumed to be familiar with the basic DNS concepts
described in RFC1034 [1] and RFC1035 [2] and should also be familiar
with common DNSSEC terminology as defined in [13].
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 [4]. document are to be interpreted as described in RFC 2119 [5].
1.3 Editors Notes 1.3 Editors Notes
1.3.1 Open Technical Issues 1.3.1 Open Technical Issues
The NXT section (Section 4) requires input from the working group. The NXT section (Section 4) may be updated in the next version if
Since the opt-in issue is not resolved, this text describes the NXT DNSSEC-Opt-In [13] becomes part of DNSSEC.
record as it was defined in RFC 2535. This section may need to be
updated, depending on the outcome of the opt-in discussion.
The cryptographic algorithm types (Appendix A) requires input from The cryptographic algorithm types (Appendix A) requires input from
the working group. The DSA algorithm was moved to OPTIONAL. This the working group. The DSA algorithm was moved to OPTIONAL. This
had strong consensus in workshops and various discussions and a had strong consensus in workshops and various discussions and a
seperate internet draft solely to move DSA from MANDATORY to OPTIONAL separate internet draft solely to move DSA from MANDATORY to OPTIONAL
seemed excessive. This draft solicts input on that proposed change. seemed excessive. This draft solicits input on that proposed change.
The indirect and private algorithms types (Appendix A) are also worth
noting. See the text in that section.
1.3.2 Technical Changes or Corrections 1.3.2 Technical Changes or Corrections
Please report technical corrections to dnssec-editors@east.isi.edu. Please report technical corrections to dnssec-editors@east.isi.edu.
To assist the editors, please indicate the text in error and point To assist the editors, please indicate the text in error and point
out the RFC that defines the correct behavior. For a technical out the RFC that defines the correct behavior. For a technical
change where there is no RFC that defines the correct behavior (or change where no RFC that defines the correct behavior, or if there's
RFCs provide conflicting answers), please post the issue to more than one applicable RFC and the definitions conflict, please
namedroppers. post the issue to namedroppers.
An example correction to dnssec-editors might be: Page X says An example correction to dnssec-editors might be: Page X says
"DNSSEC RRs SHOULD be automatically returned in responses." This was "DNSSEC RRs SHOULD be automatically returned in responses." This was
true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the 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 DNSSEC RR types MUST NOT be included in responses unless the resolver
indicated support for DNSSEC. indicated support for DNSSEC.
1.3.3 Typos and Minor Corrections 1.3.3 Typos and Minor Corrections
Please report any typos corrections to dnssec-editors@east.isi.edu. Please report any typos corrections to dnssec-editors@east.isi.edu.
To assist the editors, please provide enough context for us to To assist the editors, please provide enough context for us to find
quickly find the incorrect text. the incorrect text quickly.
An example message to dnssec-editors might be: page X says "the An example message to dnssec-editors might be: page X says "the
DNSSEC standard has been in development for over 1 years". It DNSSEC standard has been in development for over 1 years". It
should read "over 10 years". should read "over 10 years".
2. The KEY Resource Record 2. The KEY Resource Record
DNSSEC uses public key cryptogrpahy 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 KEY resource record sets (RRsets). The public keys are stored in KEY
resource records and are used in the DNSSEC authentication process resource records and are used in the DNSSEC authentication process
described in [14]. In a typical example, a zone signs its described in [11]. In a typical example, a zone signs its
authorititave RRsets using a private key and stores the corresponding authoritative RRsets using a private key and stores the corresponding
public key in a KEY RR. A resolver can then use these signatures to public key in a KEY RR. A resolver can then use these signatures to
authenticate RRsets from the zone. authenticate RRsets from the zone.
The KEY RR is also used to store public keys associated with other The KEY RR may also be used to store public keys associated with
DNS operations, such as SIG(0) [14] and TKEY [9]. In all cases, the other DNS operations such as TKEY [15]. In all cases, the KEY RR
KEY RR plays a special role in secure DNS resolution and DNS message plays a special role in secure DNS resolution and DNS message
processing. The KEY RR is not intended as a record for storing processing. The KEY RR is not intended as a record for storing
arbitrary public keys. The KEY RR MUST NOT be used to store arbitrary public keys. The KEY RR MUST NOT be used to store
certificates or public keys that do not directly relate to the DNS certificates or public keys that do not directly relate to the DNS
infrastructure. Examples of certificates and public keys that MUST infrastructure. Examples of certificates and public keys that MUST
NOT be stored in the KEY RR include X.509 certificates, IPSEC public NOT be stored in the KEY RR include X.509 certificates, IPSEC public
keys, and SSH public keys. keys, and SSH public keys.
The type number for the KEY RR is 25. The Type value for the KEY RR type is 25.
The KEY RR is class independent. The KEY RR is class independent.
There are no special TTL requirements on the KEY record. DNSSEC best There are no special TTL requirements on the KEY record.
practices documents are encouraged to provide TTL recommendations.
2.1 KEY RDATA Wire Format 2.1 KEY RDATA Wire Format
The RDATA for a KEY RR consists of a 2 octet Flags Fields, a Protocol The RDATA for a KEY RR consists of a 2 octet Flags Field, a 1 octet
Octet, a one octet Algorithm Number, and the Public Key. 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Protocol | Algorithm | | Flags | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| / / /
/ 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 is 1, then Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
the KEY record holds a DNS zone key and the KEY's owner name MUST be then the KEY record holds a DNS zone key and the KEY's owner name
the name of a zone. If bit 7 is 0, then the KEY record holds some MUST be the name of a zone. If bit 7 has value 0, then the KEY
other type of DNS public key, such as a public key used by SIG(0) or record holds some other type of DNS public key, such as a public key
TKEY. used by TKEY.
Bits 0-6 and 8-15 are reserved for future use and MUST be zero. Bits 0-6 and 8-15 are reserved and MUST have value 0 upon creation of
the KEY RR, and MUST be ignored upon reception.
2.1.2 The Protocol Octet Field Editors' Note: draft-ietf-dnsext-keyrr-key-signing-flag changes this
by allocating bit 15 as the KSK bit.
The Protocol Octet field MUST be 3. 2.1.2 The Protocol Field
2.1.3 The Algorithm and Public Key Fields The Protocol Field MUST have value 3.
2.1.3 The Algorithm Field
The Algorithm field identifies the public key's cryptographic The Algorithm field identifies the public key's cryptographic
algorithm and determines the format of the Public Key field. A list algorithm and determines the format of the Public Key field. A list
of DNSSEC algorithm types can be found in Appendix A.1 of DNSSEC algorithm types can be found in Appendix A.1
2.1.4 Notes on KEY RDATA Design 2.1.4 The Public Key Field
Although the Protocol Octet field is always 3, it is retained for The Public Key Field holds the public key material.
backwards compatibility with an earlier version of the KEY record.
The use of bit 7 as the Zone Key Flag is also due to backwards 2.1.5 Notes on KEY RDATA Design
compatiblity issues.
Although the Protocol Field always has value 3, it is retained for
backward compatibility with an earlier version of the KEY record.
2.2 The KEY RR Presentation Format 2.2 The KEY RR Presentation Format
A KEY RR may appear as a single line or multiple lines separated with
newline characters if those lines are contained with parantheses.
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
The Flag field is represented as an unsigned integer. The Flag field is represented as an unsigned decimal integer with a
value of either 0 or 256.
The Protocol Octet field is represented as the unsigned integer 3. The Protocol Field is represented as an unsigned decimal integer with
a value of 3.
The Algorithm field is represented as an unsigned integer or as an The Algorithm field is represented either as an unsigned decimal
algorithm mnemonic specified in Appendix A.1. integer or as an algorithm mnemonic as specified in Appendix A.1.
The Public Key field is a Base 64 encoding of the Public Key Field. The Public Key field is represented as a Base64 encoding of the
Public Key. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding, see [3] Section 5.2.
2.3 KEY RR Example 2.3 KEY RR Example
The following KEY RR stores a DNS zone key for isi.edu. The following KEY RR stores a DNS zone key for example.com.
isi.edu. 86400 IN KEY 256 3 5 ( AQPT0sh3WjVeRY3WqpBjtf example.com. 86400 IN KEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3Cbl
<snip of base64 encoded text> +BBZH4b/0PY1kxkmvHjcZc8nokfzj31
xxDw==) GajIQKY+5CptLr3buXA10hWqTkF7H6R
foRqXQeogmMHfpftf6zMv1LyBUgia7z
a6ZEzOJBOztyvhjL742iU/TpPSEDhm2
SNKLijfUppn1UaNvv4w== )
The first four fields specify the owner name, TTL, Class, and RR type The first four text fields specify the owner name, TTL, Class, and RR
(KEY). 256 indicates the Flags field has the zone key bit is set. 3 type (KEY). Value 256 indicates that the Zone Key bit (bit 7) in the
is the fixed Protocol Octet value. 5 indicates the public key Flags field has value 1. Value 3 is the fixed Protocol value. Value
algorithm. Appendix A.1 identifies algorithm type 5 as RSA/SHA1 and 5 indicates the public key algorithm. Appendix A.1 identifies
indicates that the format of the RSA/SHA1 public key field is defined algorithm type 5 as RSA/SHA1 and indicates that the format of the
in [12]. The remaining text is a base 64 encoding of the public key. RSA/SHA1 public key field is defined in [8]. The remaining text is a
base 64 encoding of the public key.
3. The SIG Resource Record 3. The SIG Resource Record
DNSSEC uses public key cryptogrpahy to sign and authenticate DNS DNSSEC uses public key cryptography to sign and authenticate DNS
resource record sets (RRsets). The signatures are stored in SIG resource record sets (RRsets). Signatures are stored in SIG resource
resource records and are used in the DNSSEC authentication process records and are used in the DNSSEC authentication process described
described in [14]. In a typical example, a zone signs its in [11]. In a typical example, a zone signs its authoritative RRsets
authorititave RRsets using a private key and stores the corresponding using a private key and stores the corresponding signatures in SIG
signatures in SIG RRs. A resolver can then use these signatures to RRs. A resolver can then use these SIG RRs to authenticate RRsets
authenticate RRsets from the zone. from the zone.
A SIG record contains the signature for an RRset with a particular A SIG record contains the signature for an RRset with a particular
name, class, and type. The SIG RR is said to "cover" this RRset. name, class, and type. The SIG RR specifies a validity interval for
The SIG RR also specifies a validity interval for the signature and the signature and uses the Algorithm, the Signer's Name, and the Key
uses an algorithm signer's name, and key tag to identify the public Tag to identify the public key (KEY RR) that can be used to verify
key (KEY record) that can be used to verify the signature. the signature.
The signature in SIG RR may also cover a transaction rather than an The SIG RR may cover a transaction instead of an RRset. In this
RRset [14]. In this case, the "Type Covered" field is set to 0 and case, the "Type Covered" field value is 0, the SIG RR MUST NOT appear
the SIG RR is refered to as SIG(0) resource record. in any zone, and its use and processing are outside the scope of this
document. Please see [7] for further details.
The type number for the SIG RR type is 24. The Type value for the SIG RR type is 24.
The SIG RR is class independent, but MUST have the same class as the The SIG RR MUST have the same class as the RRset it covers.
RRset it covers.
The SIG RR TTL SHOULD match the TTL of the RRset it covers. The SIG RR TTL value SHOULD match the TTL value of the RRset it
covers.
3.1 The SIG RDATA 3.1 SIG RDATA Wire Format
The RDATA portion of a SIG RR is shown below: The RDATA for a SIG 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type covered | algorithm | labels | | Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| original TTL | | Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration | | Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature inception | | Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | | | Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/ / / /
/ signature / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1 The Type Covered Field 3.1.1 The Type Covered Field
The Type Covered field identifies the RRset type covered by the SIG The Type Covered field identifies the type of the RRset which is
record. covered by this SIG record.
If Type Covered field is set to 0, the record is referred to as a If Type Covered field has a value of 0, the record is referred to as
SIG(0) RR and its signature covers a transaction rather than a a transaction signature; please see [7] for further details.
specific RRset. [14] descirbes how to sign transactions using SIG(0)
resource records.
3.1.2 The Algorithm Number Field 3.1.2 The Algorithm Number Field
The Algorithm Number field identies the cryptographic algorithm used The Algorithm Number field identifies the cryptographic algorithm
to create the signature. A list of DNSSEC algorithm types can be used to create the signature. A list of DNSSEC algorithm types can
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 SIG The Labels field specifies the number of labels in the original SIG
RR owner name. It is included to handle signatures associated with RR owner name. It is included to handle signatures associated with
wildcard owner names. wildcard owner names.
To validate the signature, a resolver requires the original owner To validate a signature, the validator requires the original owner
name that was used when the signature was created. In most cases, name that was used when the signature was created. If the original
the owner name used when the signature was created is identical to owner name contains a wildcard label ("*"), the owner name may have
the owner name sent in any response. However, a wildcard owner name been expanded by the server during the response process, in which
will be expanded during the query/response process and [14] describes case the validator will need to reconstruct the original owner name
how the label count is used to reconstruct the original (unexpanded) in order to validate the signature. [11] describes how to use the
owner name. Labels field to reconstruct the original owner name.
The Labels field does not count null labels for root and does not The value of the Label field MUST NOT count either the null (root)
count any initial "*" in a wildcard name. The Labels field MUST be label that terminates the owner name or the wildcard label (if
less than or equal to the number of labels in the SIG owner name. present). The value of the Label field MUST be less than or equal to
For example, "www.example.com." has a label count of 3 and the number of labels in the SIG owner name. For example,
"*.example.com." has a label count of 2. "www.example.com." has a Label field value of 3, and "*.example.com."
has a Label field value of 2. Root (".") has a Label field value of
0.
Note that, although the wildcard label is not included in the count
stored in the Label field of the SIG RR, the wildcard label is part
of the 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 original TTL of the covered The Original TTL field specifies the TTL of the covered RRset as it
RRset. appears in the authoritative zone.
To validate the signature, a resolver requires the original TTL used The Original TTL field is necessary because a caching resolver
when the signature was created. However, caching servers will decrements the TTL value of a cached RRset. In order to validate a
decrement the TTL and [14] describes how the Original TTL field count signature, a resolver requires the original TTL. [11] describes how
is used to reconstruct the original (undecremented) TTL. to use the Original TTL field value to reconstruct the original TTL.
If the Type Covered field is non-zero, the Original TTL value MUST be The Original TTL value MUST be greater than or equal to the TTL value
greater than or equal to the TTL of the SIG record itself. If the of the SIG record itself.
Type Covered field is 0 (i.e. a SIG(0) RR), the Original TTL field
SHOULD be zero.
3.1.5 Signature Expiration and Inception Fields 3.1.5 Signature Expiration and Inception Fields
The Signature Inception and Signature Expiration fields specify a The Signature Expiration and Inception fields specify a validity
validity period for the signature. The SIG record MUST NOT be used period for the signature. The SIG record MUST NOT be used for
for authentication prior to the inception date and MUST NOT be used authentication prior to the inception date and MUST NOT be used for
for authentication after the expiratiation date. authentication after the expiration date.
Inception and expiration dates are given as 32-bit unsigned numbers Signature Expiration and Inception field values are in POSIX.1 time
of seconds since the start of 1 January 1970 GMT, ignoring leap format, a 32-bit unsigned number of seconds elapsed since 1 January
seconds. Ring arithmetic [3] to handle 32-bit wrap around. As 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The
result, these times can never be more than 68 years in the past or longest interval which can be expressed by this format without
the future and the times are ambiguous modulo ~136 years. A SIG RR wrapping is approximately 136 years. A SIG RR can have an Expiration
can have an expiration time numerically smaller than the inception field value which is numerically smaller than the Inception field
time if the expiration time is near the 32-bit wrap around point and/ value if the expiration field value is near the 32-bit wrap-around
or the signature is long lived. point or if the signature is long lived. Because of this, all
comparisons involving these fields MUST use "Serial number
arithmetic" as defined in [4]. 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 3.1.6 The Key Tag Field
The Key Tag field contains the key tag of the public key (KEY RR) The Key Tag field contains the key tag value of the KEY RR that
used to authenticate this signature. The process of calculating a validates this signature. The process of calculating the Key Tag
key tag is given in Appendix B. value is given in Appendix B.
3.1.7 The Signer's Name Field 3.1.7 The Signer's Name Field
The Signer's Name field identifies the name of the KEY RR used to The Signer's Name field value identifies the owner name of the KEY RR
authenticate this signature. If the Type Covered field is non-zero, used to authenticate this signature. The Signer's Name field MUST
the Signer's Name MUST contain the name of the zone containing the contain the name of the zone of the covered RRset, unless the Type
covered RRset and the SIG. The signer's name MAY be compressed with Covered field value is 0. A sender MUST NOT use DNS name compression
standard DNS name compression when being transmitted over the on the Signer's Name field when transmitting a SIG RR. A receiver
network. which receives a SIG RR containing a compressed Signer's Name field
SHOULD decompress the field value.
If the Type Covered field is 0 (i.e. a SIG(0) RR), the signer's name
MUST be the name of the host originating the DNS message as described
in [10].
3.1.8 The Signature Field 3.1.8 The Signature Field
The Signature field contains the cryptographic signature. If the The Signature field contains the cryptographic signature which covers
Type Covered field is non-zero, the signature covers the SIG RDATA the SIG RDATA (excluding the Signature field) and the RRset specified
(excluding the Signature field) and the RRset specified by the SIG by the SIG owner name, SIG class, and SIG Type Covered field.
owner name, SIG class, and SIG Type Covered field.
3.2 Calculating A Signature
A signature covers either an RRset or a transaction. RRset
signatures and transaction signatures are distinguished by the Type
Covered field. RRset signatures have a non-zero Type Covered field.
SIG RRs SHOULD NOT be generated for any "meta-type" such as ANY or
AXFR.
3.2.1 Calculating An RRset Signature 3.1.8.1 Signature Calculation
A signature covers the SIG RDATA (excluding the Signature Field A signature covers the SIG RDATA (excluding the Signature Field) and
itself) and covers the RRset specified by the SIG owner name, SIG covers the RRset specified by the SIG owner name, SIG class, and SIG
class, and SIG Type Covered field. The RRset is in cannonical form Type Covered field. The RRset is in canonical form (see Section 6)
(see Appendix C) and the set RR(1),...RR(n) is signed as follows: and the set RR(1),...RR(n) is signed as follows:
signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where
"|" denotes append "|" denotes concatenation;
SIG_RDATA is the wire format of the SIG RDATA fields with SIG_RDATA is the wire format of the SIG RDATA fields with
the Signer's Name field in cannonical form. the Signer's Name field in canonical form and
the Signature field excluded. the Signature field excluded;
RR(i) = fqdn | class | type | TTL | RDATA length | RDATA RR(i) = owner | class | type | TTL | RDATA length | RDATA;
fqdn is the Fully Qualified Domain Name in canonical "owner" is the fully qualified owner name of the RRset in
form. canonical form (for RRs with wildcard owner names, the
wildcard label is included in the owner name);
All RR(i) MUST have the same fqdn as the SIG RR. Each RR MUST have the same owner name as the SIG RR;
All RR(i) MUST have the same class as the SIG RR. Each RR MUST have the same class as the SIG RR;
All RR(i) MUST have the RR type listed in SIG RR's Each RR in the RRset MUST have the RR type listed in the
Type Covered field. SIG RR's Type Covered field;
All RR(i) MUST have the TTL listed in the SIG Original Each RR in the RRset MUST have the TTL listed in the SIG
TTL Field Original TTL Field;
All names in the RDATA field are in canonical form Any DNS names in the RDATA field of each RR MUST be in
canonical form; and
The set of all RR(i) is sorted into cannonical order. The RRset MUST be sorted in canonical order.
3.2.2 Calculating An Transaction Signature 3.2 The SIG RR Presentation Format
3.3 The SIG RR Presentation Format
A SIG RR may appear as a single logical line. The presentation The presentation format of the RDATA portion is as follows:
format of the RDATA portion is as follows:
The Type Covered field is represented by either an unsigned integer The Type Covered field value is represented either as an unsigned
or the mnemonic for the RR type. decimal integer or as the mnemonic for the covered RR type.
The Algorithm field is represented as an unsigned integer or as an The Algorithm field value is represented either as an unsigned
algorithm mnemonic specified in Appendix A.1. decimal integer or as an algorithm mnemonic as specified in Appendix
A.1.
The Labels field is represented as an unsigned integer. The Labels field value is represented as an unsigned decimal integer.
The Original TTL field is represented as an unsigned integer. It MAY The Original TTL field value is represented as an unsigned decimal
be omitted if it is equal the TTL of the SIG RR. integer.
The Signature Inception Time and Expiration Time fields are The Signature Inception Time and Expiration Time field values are
represented in the form YYYYMMDDHHmmSS, where: represented in the form YYYYMMDDHHmmSS in UTC, where:
YYYY is the year YYYY is the year (0000-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) mm is the minute (00-59);
SS is the second (00-59) SS is the second (00-59).
The Key Tag field is represented as an unsigned integer. The Key Tag field is represented as an unsigned decimal integer.
The Signer's Name field is represented as a domain name. The Signer's Name field value is represented as a fully qualified
domain name.
The Signature field is a Base 64 encoding of the signature. The Signature field is represented as a Base64 encoding of the
signature. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding see [3] Section 5.2.
3.4 Example of a SIG RR 3.3 SIG RR Example
The following a SIG RR stores the signature for the the A RRset of The following a SIG RR stores the signature for the A RRset of
host.example.com: host.example.com:
host.example.com. 30 IN SIG A 3 3 30 20011231120000 ( host.example.com. 86400 IN SIG A 5 3 86400 20030322173103 (
20011108100000 65531 example.com 20030220173103 2642 example.com.
CGr0uS55C4l/2RRc2NrMJbRt4oP+xVxwgMkC oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
rJFXXDsybfEDdwoajAY= ) PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
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
(SIG). The "A" represents the Type Covered field. is the algorithm (SIG). The "A" represents the Type Covered field. The value 5
used to create this signature. The first 3 identifies the Algorithm identifies the Algorithm used (RSA-SHA1) to create the signature.
used to create the signature. The second 3 is the number of Labels The value 3 is the number of Labels in the original owner name. The
in the original owner name and the 30 is the Original TTL for this value 86400 in the SIG RDATA is the Original TTL for the covered A
SIG RR and the covered A RRset. The two dates are the expiration and RRset. 20030322173103 and 20030220173103 are the expiration and
inception dates. 65531 is the Key Tag and example.com. is the inception dates, respectively. 2642 is the Key Tag, and example.com.
Signer's Name. The remaining text is a base 64 encoding of the is the Signer's Name. The remaining text is a Base64 encoding of the
signature. signature.
Note that combination of SIG RR owner name, class, and and Type Note that combination of SIG RR owner name, class, and Type Covered
Covered indicate this SIG covers the "host.example.com" A RRset. The indicate that this SIG covers the "host.example.com" A RRset. The
Label value of 3 indicates 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 KEY RR whose algorithm is 3 authenticated using an example.com zone KEY RR whose algorithm is 5
and key tag is 65531. and key tag is 2642.
4. The NXT Resource Record 4. The NXT Resource Record
The NXT resource record lists the RR types present at the NXT's owner The NXT resource record lists two separate things: the owner name of
name and lists the next canonical name in the zone. The collection the next authoritative RRset in the canonical ordering of the zone,
of NXT or "next" resource records indicate what RRsets exist in a and the set of RR types present at the NXT RR's owner name. The
zone and provide a chain of all authoritative owner names in that complete set of NXT RRs in a zone both indicate which authoritative
zone. This information can be used for authenticated denial of RRsets exist in a zone and also form a chain of authoritative owner
existence, as desribed in [14]. names in the zone. This information is used to provide authenticated
denial of existence for DNS data, as described in [11].
Note that although a zone may contain non-authoritiative glue address
records, these non-authoritative glue records MUST NOT be used when
contructing the NXT resource record chain.
The type number for the NXT RR is 30. The type value for the NXT RR is 30.
The NXT RR is class independent. The NXT RR is class independent.
The NXT RR TTL SHOULD NOT exceed the minimum TTL in the zone's SOA
RR.
4.1 NXT RDATA Wire Format 4.1 NXT RDATA Wire Format
The RDATA of the NXT RR is as shown below: The RDATA of the NXT 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 map / / Type Bit Map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1 The Next Domain Name Field 4.1.1 The Next Domain Name Field
The Next Domain Name field contains the next authoritive owner name The Next Domain Name field contains the owner name of the next
in canonical order, where canonical order is defined in Appendix C.1. authoritative RRset in the canonical ordering of the zone; see
For the last owner name in the zone, the Next Domain Name field Section 6.1 for an explanation of canonical ordering. The value of
contains the zone apex name. the Next Domain Name field in the last NXT record in the zone is the
name of the zone apex (the owner name name of the zone's SOA RR).
The Next Domain Name field allows message compression. A sender MUST NOT use DNS name compression on the Next Domain Name
field when transmitting an NXT RR. A receiver which receives an NXT
RR containing a compressed Next Domain Name field SHOULD decompress
the field value.
Note that non-authoritative glue address record names may exist in a Owner names of non-authoritative RRsets (such as glue records) MUST
zone, but these non-authoritative glue records MUST NOT be listed in NOT be listed in the Next Domain Name unless at least one
the Next Domain Name. Any non-authoritative glue records are ignored authoritative RRset exists at the same owner name.
(treated as though they were never present) when constructing an NXT.
4.1.2 The Type Bit Map Field 4.1.2 The Type Bit Map Field
The Type Bit Map field identifies the RRset types that exist at the The Type Bit Map field identifies the RRset types which exist at the
NXT's owner name. NXT RR's owner name.
Each bit in the Type Bit Map field corresponds to an RR type. Bit Each bit in the Type Bit Map field corresponds to an RR type. Bit 1
one corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS),
(NS), and so forth. If a bit is set to 1, it indicates that an RRset and so forth. If a bit is set to 1, it indicates that an RRset of
of that type exists for the NXT's owner name. If a bit is set to that type is present for the NXT's owner name. If a bit is set to 0,
zero, it indicates that no RRset of that type exists for the NXT's it indicates that no RRset of that type present for the NXT's owner
owner name. name.
Trailing zero octets MUST be omitted. Thus the length of the Type Bit 1 MUST NOT indicate glue address records.
Bit Map field varies and is dependent on the largest RR type present
for the NXT's owner name. Trailing zero octets not specified MUST be
interpreted as zero octets.
Non-authoritative glue address record types MUST NOT be used when Bit 41 MUST have the value of 0, since the OPT pseudo-RR [6] can
constructing the type bit map field. The OPT RR [8] type (41) also never appear in zone data.
MUST NOT be used when constructing the type bit map field since it is
not part of the zone data. In other words, the OPT RR type bit (bit
41) MUST be zero.
4.1.2.1 Alternate Formats for the Type Bit Map Field Trailing zero octets MUST be omitted. The length of the Type Bit Map
field varies, and is determined by the type code with the largest
numerical value among the set of RR types present at the NXT RR's
owner name. Trailing zero octets not specified MUST be interpreted
as zero octets.
The above Type Bit Map format MUST NOT be used when an RR type number The above Type Bit Map format MUST NOT be used when an RR type code
greater than 127 is in use. with numerical value greater than 127 is present.
Bit 0 in the Type Bit Map Field is used to indicate an alternate Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A
format for the Type Bit Map field. If bit 0 is set to 1, it value of 0 in bit 0 denotes the format described above, therefore bit
indicates some other format is being used for this field. No 0 MUST have a value of 0. The format and meaning of a Type Bit Map
alternate formats are defined as of this writing. with a value of 1 in bit 0 is undefined.
4.1.3 Inclusion of Wildcard Names in NXT RDATA 4.1.3 Inclusion of Wildcard Names in NXT RDATA
If a wildcard owner name appears in a zone, the wildcard is treated If a wildcard owner name appears in a zone, the wildcard label ("*")
as a literal symbol and is treated the same as any other owner name. is treated as a literal symbol and is treated the same as any other
Wildcard owner names appear (unexpanded) in the Next Domain Name owner name for purposes of generating NXT RRs. Wildcard owner names
field without any wildcard expansion. [14] describes the impact of appear in the Next Domain Name field without any wildcard expansion.
wildcards on authetnicated denial of existence. [11] describes the impact of wildcards on authenticated denial of
existence.
4.2 The NXT RR Presentation Format 4.2 The NXT RR Presentation Format
A NXT RR may appear as a single line. The presentation format of the The presentation format of the RDATA portion is as follows:
RDATA portion is as follows:
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 Map field is represented as a sequence of RR type The Type Bit Map field is represented either as a sequence of RR type
mnemonics or as a sequence of unsigned integers denoting the RR mnemonics or as a sequence of unsigned decimal integers denoting the
types. RR type codes.
4.3 NXT RR Example 4.3 NXT RR Example
The following NXT RR identifies the RRsets associated with The following NXT RR identifies the RRsets associated with
a.example.com and identifies the next authoritative name after alfa.example.com. and identifies the next authoritative name after
a.example.com. alfa.example.com.
a.example.com. 86400 IN NXT c.example.com. A MX NXT alfa.example.com. 86400 IN NXT host.example.com. A MX SIG NXT
The first four fields specify the name, TTL, Class, and RR type The first four text fields specify the name, TTL, Class, and RR type
(NXT). The entry c.example.com is the next authoritative name after (NXT). The entry host.example.com. is the next authoritative name
a.example.com (in cannonical order). The A MX and NXT nnemonics after alfa.example.com. (in canonical order). The A, MX, SIG and
indicate there are A, MX, and NXT RRsets associated with the name NXT mnemonics indicate there are A, MX, SIG and NXT RRsets associated
a.example.com. with the name alfa.example.com.
Note the NXT record can be used for authenticted denial of existence. Note the NXT record can be used for authenticated denial of
If the example NXT record were authenticed, it could be used to prove existence. If the example NXT record were authenticated, it could be
that b.example.com does not exist or could be used to prove there is used to prove that beta.example.com. does not exist, or could be
no AAAA record assoicated with a.example.com. Authenticated denial used to prove there is no AAAA record associated with
of existence is discussed in [14] alfa.example.com. Authenticated denial of existence is discussed in
[11]
5. The DS Resource Record 5. The DS Resource Record
The DS Resource Record points to a KEY RR and is used in the DNS KEY The DS Resource Record refers to a KEY RR and is used in the DNS KEY
authentication process. A DS RR points to a KEY RR by storing the authentication process. A DS RR refers to a KEY RR by storing the
key tag, algorithm number, and a digest of KEY RR. Note that while key tag, algorithm number, and a digest of KEY RR. Note that while
the digest should be sufficient to identify key, storing the key tag the digest should be sufficient to identify the key, storing the key
and key algorithm helps make the identification process more tag and key algorithm helps make the identification process more
efficient and more secure. By authenticating the DS record, a efficient. By authenticating the DS record, a resolver can
resolver can authenticate the KEY RR pointed to by the DS record. authenticate the KEY RR to which the DS record points. The key
The key authentication proces is described in [14]. authentication process is described in [11].
The DS RR and its corresponding KEY RR both have the same owner name, The DS RR and its corresponding KEY RR have the same owner name, but
but they are stored in different locations. The DS RR is the first they are stored in different locations. The DS RR appears only on
resource record that appears only on the upper side of a delegation. the upper (parental) side of a delegation, and is authoritative data
In other words, the DS RR for "example.com" is stored in "com" (the in the parent zone. For example, the DS RR for "example.com" is
upper side of the delegation). The corresponding KEY RR is stored in stored in the "com" zone (the parent zone) rather than in the
the "example.com" zone (the lower side of the delegation). This "example.com" zone (the child zone). The corresponding KEY RR is
simplifies DNS zone management and zone signing, but introduces stored in the "example.com" zone (the child zone). This simplifies
special response processing requirements that are described in [14]. DNS zone management and zone signing, but introduces special response
processing requirements for the DS RR; these are described in [11].
The type number for the DS record is 43. The type number for the DS record is 43.
The DS resource record is class independent. The DS resource record is class independent.
There are no special TTL requirements on the DS resource record. There are no special TTL requirements on the DS resource record.
DNSSEC best practices documents are encouraged to provide TTL
recommendations.
5.1 DS RDATA Wire Format 5.1 DS RDATA Wire Format
The RDATA for a DS RR consists of 2 octet Key Tag, a one octet The RDATA for a DS RR consists of 2 octet Key Tag field, a one octet
Algorithm Number, a one octet Digest Type, and a Digest. Algorithm field, a one 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 KEY RR pointed to by the The Key Tag field lists the key tag of the KEY RR referred to by the
DS record. The KEY RR MUST be a a zone key. In other words, the KEY DS record. The KEY RR MUST be a zone key. The KEY RR Flags MUST
RR Flags must have Flags bit 7 set to 1. have Flags bit 7 set to value 1.
The key tag used by the DS RR is identical to the key tag used by the The Key Tag used by the DS RR is identical to the Key Tag used by the
SIG RR and Appendix B describes how to compute a key tag. SIG RR and 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 KEY RR pointed The Algorithm field lists the algorithm number of the KEY RR referred
to by the DS record. 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 the SIG RR and KEY RR. Appendix A.1 lists the number used by the SIG RR and KEY RR. Appendix A.1 lists the
algorithm number types. algorithm number types.
5.1.3 The Digest Type Field 5.1.3 The Digest Type Field
The DS RR points to a KEY RR by including a digest of that KEY RR. The DS RR refers to a KEY RR by including a digest of that KEY RR.
The Digest Type field identifes the algorithm used to construct the The Digest Type field identifies the algorithm used to construct the
digest and Appendix A.2 lists the possible digest algorithm types. digest and Appendix A.2 lists the possible digest algorithm types.
5.1.4 The Digest Field 5.1.4 The Digest Field
The DS record points to a KEY RR by including a digest of that KEY The DS record refers to a KEY RR by including a digest of that KEY
RR. The Digest field hold the digest. RR. The Digest field holds the digest.
For a given KEY RR, the digest is calculated by appending the KEY The digest is calculated by concatenating the canonical form of the
RR's cannonical fully qualified owner name with the KEY RDATA and fully qualified owner name of the KEY RR (abbreviated below as "key
then applying the digest algorithm. RR name") with the KEY RDATA, and then applying the digest algorithm.
digest = digest_algorithm( cannonical FQDN of KEY RR | KEY_RR_rdata) digest = digest_algorithm( KEY RR name | KEY RDATA);
"|" denotes append "|" denotes concatenation
KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key.
The size of the digest can vary depending on the digest algorithm and The size of the digest may vary depending on the digest algorithm and
KEY RR size. However, the only currently defined digest algorithm is KEY RR size. Currently, the defined digest algorithm is SHA-1, which
SHA-1 and it always produces a 24 byte digest regardless of KEY RR produces a 20 octet digest.
size.
5.2 The DS RR Presentation Format 5.2 The DS RR Presentation Format
A DS RR may appear as a single line or multiple lines separated with
newline characters if those lines are contained within parantheses.
The presentation format of the RDATA portion is as follows: The presentation format of the RDATA portion is as follows:
The Key Tag field is represented as an unsigned integer. The Key Tag field is represented as an unsigned decimal integer.
The Algorithm field is represented as an unsigned integer or as an The Algorithm field is represented either as an unsigned decimal
algorithm mnemonic specified in Appendix A.1. integer or as an algorithm mnemonic specified in Appendix A.1.
The Digest Type field is represented as an unsigned integer. The Digest Type field is represented as an unsigned decimal integer.
The Digest is presented in hexadecimal. The Digest is represented as a sequence of case-insensitive
hexadecimal digits. Whitespace is allowed within the hexadecimal
text.
5.3 DS Record Example 5.3 DS RR Example
The following example shows a KEY RR and its corresponding DS RR. The following example shows a KEY RR and its corresponding DS RR.
dskey.example. 86400 IN KEY 256 3 1 ( AQPwHb4UL1U9RHaU8qP+Ts5bVOU dskey.example.com. 86400 IN KEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
1s7fYbj2b3CCbzNdj4+/ECd18yKiy fwJr1AYtsmx3TGkJaNXVbfi/
UQqKqQFWW5T3iVc8SJOKnueJHt/Jb 2pHm822aJ5iI9BMzNXxeYCmZ
/wt) ; key tag = 28668 DRD99WYwYqUSdjMmmAphXdvx
dskey.example. 3600 IN DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE egXd/M5+X7OrzKBaMbCVdFLU
Uh6DhweJBjEVv5f2wwjM9Xzc
nOf+EPbtG9DMBmADjFDc2w/r
ljwvFw==
) ; key id = 60485
The first four fields specify the name, TTL, Class, and RR type (DS). dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
28668 is the key tag for the corresponding "dskey.example." KEY RR 98631FAD1A292118 )
and 1 algorithm used by this "dskey.example." KEY RR. The second 1
is the algorithm used to construct the digest and the final string is
the digest in hex.
6. IANA Considerations 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." KEY RR, and value 5 denotes the algorithm used
by this "dskey.example.com." KEY RR. The value 1 is the algorithm
used to construct the digest, and the rest of the RDATA text is the
digest in hexadecimal.
This document introduces no new IANA considerations. 6. Canonical Form and Order of Resource Records
This document only clarifies the use of existing DNS resource This section defines a canonical form for resource records, a
records. However for completeness, the IANA considerations from canonical ordering of DNS names, and a canonical ordering of resource
these previous documents are summarized below. No IANA changes are records within an RRset. A canonical name order is required to
made by this document. construct the NXT name chain. A canonical RR form and ordering
within an RRset are required to construct and verify SIG RRs.
RFC 2535 updated the IANA registry for DNS Resource Record Types and 6.1 Canonical DNS Name Order
assigned types 24,25, and 30 to the SIG, KEY, and NXT (respectively).
[DS RFC] assigned DNS Resource Record Type 43 to DS.
RFC 2535 created an IANA registry for DNSSEC Resource Record For purposes of DNS security, owner names are ordered by treating
Algorithm Numbers. Values to 1-4, and 252-255 were assigned by RFC individual labels as unsigned left-justified octet strings. The
2535. Value 5 was assigned by RFC 3110. absence of a octet sorts before a zero value octet, and upper case
US-ASCII letters are treated as if they were lower case US-ASCII
letters.
[DS RFC] created an IANA registry for DNSSEC DS Digest Types and To compute the canonical ordering of a set of DNS names, start by
assigned value 0 to reserved and value 1 to RSA/SHA-1. 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.
RFC 2535 created an IANA Registry to KEY Protocol Octet Values, but For example, the following names are sorted in canonical DNS name
[KeyRestrict RFC] set all assigned values other than 3 to reserved order. The most significant label is "example". At this level,
and closed this IANA registry. The registry remains closed and all "example" sorts first, followed by names ending in "a.example", then
KEY records are required to have Protocol Octet value of 3. names ending "z.example". The names within each level are sorted in
the same way.
The Flag bits in the KEY RR are not assigned by IANA and there is no 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 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, or A6, all uppercase US-ASCII letters in the DNS
names within the RDATA of the RR 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
authoritative zone containing the RR or the Original TTL field of
the covering SIG RR.
Editors' Note: the above definition sacrifices readability for an
attempt at precision. Please send better text!
6.3 Canonical RR Ordering Within An RRset
For purposes of DNS security, RRs with same owner name, same class,
and same type are sorted by sorting the canonical forms of the RRs
while treating the RDATA portion of the canonical form of each RR as
a left justified unsigned octet sequence. The absence of an octet
sorts before the zero octet.
7. IANA Considerations
This document introduces one new IANA consideration. RFC 2535 [14]
created an IANA registry for DNS Security Algorithm Numbers. This
document re-assigns DNS Security Algorithm Number 252 to be
"reserved". This value is no longer available for assignment by
IANA.
This document clarifies the use of existing DNS resource records.
For completeness, the IANA considerations from the previous documents
which defined these resource records are summarized below. No IANA
changes are made by this document other than the one change described
in the first paragraph of this section.
[14] updated the IANA registry for DNS Resource Record Types, and
assigned types 24,25, and 30 to the SIG, KEY, and NXT RRs,
respectively. [9] assigned DNS Resource Record Type 43 to DS.
[14] created an IANA registry for DNSSEC Resource Record Algorithm
Numbers. Values to 1-4, and 252-255 were assigned by [14]. Value 5
was assigned by [8]. Value 252 is re-assigned by this document, as
noted above.
[9] created an IANA registry for DNSSEC DS Digest Types, and assigned
value 0 to reserved and value 1 to SHA-1.
[14] created an IANA Registry for KEY Protocol Values, but [16] re-
assigned all assigned values other than 3 to reserved and closed this
IANA registry. The registry remains closed, and all KEY records are
required to have Protocol Octet value of 3.
The Flag bits in the KEY RR are not assigned by IANA, and there is no
IANA registry for these flags. All changes to the meaning of the KEY IANA registry for these flags. All changes to the meaning of the KEY
RR Flag bits require a standards action. RR Flag bits require a standards action.
7. Security Considerations The meaning of a value of 1 in bit zero of the Type Bit Map of an NXT
RR can only be assigned by a standards action.
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
desribed below, the resource records themselves introduce no security described below, the resource records themselves introduce no
considerations. The use of these records is specified in a seperate security considerations. The use of these records is specified in a
document and security considerations related to the use these separate document, and security considerations related to the use
resource records are discussed in that document. these resource records are discussed in that document.
The DS record points to a KEY RR using a cryptographic digest, the The DS record points to a KEY 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 KEY RR, but it is theoretically possibile for an identify an existing KEY RR, but it is theoretically possible for an
attacker to generate a KEY that matches all the DS fields. The attacker to generate a KEY that matches all the DS fields. The
probability of constructing such a matching KEY depends on the type probability of constructing such a matching KEY depends on the type
of digest algorithm in use and the only currently defined digest of digest algorithm in use. The only currently defined digest
algorithm is SHA1. It is considered very difficult to constuct a algorithm is SHA-1, and the working group believes that constructing
public key that matches the algorithm, key tag, and SHA1 digest given a public key which would match the algorithm, key tag, and SHA-1
in a DS record. 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 efficiently select KEY resource records, The key tag is used to help select KEY resource records efficiently,
but it does not uniquely identify a KEY resource record. It is but it does not uniquely identify a single KEY resource record. It
possible that two distinct KEY RRs could have the same owner name, is possible for two distinct KEY RRs to have the same owner name, the
same algorithm type and same key tag. An implementation that used same algorithm type, and the same key tag. An implementation which
only the key tag to select a KEY RR may select the wrong public key used only the key tag to select a KEY RR might select the wrong
for a given scenario. Implementations MUST NOT assume the key tag is public key in some circumstances. Implementations MUST NOT assume
unique public key identifier and this is clearly stated in the text. the key tag is unique public key identifier; this is clearly stated
in Appendix B.
8. Acknowledgements 9. Acknowledgments
This document was created from the input and ideas of several members This document was created from the input and ideas of several members
of the DNS Extensions Working Group and working group mailing list. of the DNS Extensions Working Group and working group mailing list.
The co-authors of this draft would like to express their thanks for The co-authors of this draft would like to express their thanks for
the comments and suggestions received during the revision of these the comments and suggestions received during the revision of these
security extension specifications. security extension specifications.
References Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD [1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987. 13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [3] 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.
[4] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
RFC 2181, July 1997. August 1999.
[6] Eastlake, D., "Domain Name System Security Extensions", RFC [7] Eastlake, D., "DNS Request and Transaction Signatures (
2535, March 1999. SIG(0)s)", RFC 2931, September 2000.
[7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
(DNS)", RFC 2536, March 1999. System (DNS)", RFC 3110, May 2001.
[8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [9] Gudmundsson, O., "Delegation Signer Resource Record", draft-
August 1999. ietf-dnsext-delegation-signer-12 (work in progress), December
2002.
[9] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
2930, September 2000. "DNS Security Introduction and Requirements", draft-ietf-
dnsext-dnssec-intro-05 (work in progress), February 2003.
[10] Eastlake, D., "DNS Request and Transaction Signatures ( [11] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
SIG(0)s)", RFC 2931, September 2000. "Protocol Modifications for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-protocol-00 (work in progress),
Februari 2003.
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic [12] Gustafsson, A., "Handling of Unknown DNS RR Types", draft-ietf-
Update", RFC 3007, November 2000. dnsext-unknown-rrs-04 (work in progress), September 2002.
[12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name [13] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft-
System (DNS)", RFC 3110, May 2001. ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003.
[13] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC Intro", Informative References
October 2002.
[14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC [14] Eastlake, D., "Domain Name System Security Extensions", RFC
Protocol", October 2002. 2535, March 1999.
[15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource [15] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
Record", draft-ietf-dnsext-restrict-key-for-dnssec-02 (work in 2930, September 2000.
progress), March 2002.
[16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Bankastraat 41-E Telematica Instituut
1094 EB Amsterdam Drienerlolaan 5
7522 NB Enschede
NL NL
EMail: roy@logmess.com EMail: roy.arends@telin.nl
Rob Austein
Internet Software Consortium
40 Gavin Circle
Reading, MA 01867
USA
EMail: sra@isc.org
Matt Larson Matt Larson
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21345 Ridgetop Circle
Dulles, VA 20166-6503 Dulles, VA 20166-6503
USA USA
EMail: mlarson@verisign.com EMail: mlarson@verisign.com
Dan Massey Dan Massey
skipping to change at page 25, line 29 skipping to change at page 28, line 4
EMail: mlarson@verisign.com EMail: mlarson@verisign.com
Dan Massey Dan Massey
USC Information Sciences Institute USC Information Sciences Institute
3811 N. Fairfax Drive 3811 N. Fairfax Drive
Arlington, VA 22203 Arlington, VA 22203
USA USA
EMail: masseyd@isi.edu EMail: masseyd@isi.edu
Scott Rose Scott Rose
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 exstentions are designed to be independent of the The DNS security extensions are designed to be independent of the
underlying cryptographic algorithms. The KEY, SIG, and DS resource underlying cryptographic algorithms. The KEY, SIG, and DS resource
records all use a DNSSEC Algorithm Number to identify the records all use a DNSSEC Algorithm Number to identify the
crytographic 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
skipping to change at page 26, line 36 skipping to change at page 29, line 36
types and provides references to their supporting documents: types and provides references to their supporting documents:
VALUE Algorithm RFC STATUS VALUE Algorithm RFC STATUS
0 Reserved - - 0 Reserved - -
1 RSA/MD5 RFC 2537 NOT RECOMMENDED 1 RSA/MD5 RFC 2537 NOT RECOMMENDED
2 Diffie-Hellman RFC 2539 OPTIONAL 2 Diffie-Hellman RFC 2539 OPTIONAL
3 DSA RFC 2536 OPTIONAL 3 DSA RFC 2536 OPTIONAL
4 elliptic curve TBA OPTIONAL 4 elliptic curve TBA OPTIONAL
5 RSA/SHA1 RFC 3110 MANDATORY 5 RSA/SHA1 RFC 3110 MANDATORY
6-251 available for assignment - 6-251 available for assignment -
252 indirect see below OPTIONAL 252 reserved -
253 private see below OPTIONAL 253 private see below OPTIONAL
254 private see below OPTIONAL 254 private see below OPTIONAL
255 reserved - - 255 reserved - -
A.1.1 Indiret and Private Algorithm Types A.1.1 Private Algorithm Types
RFC 2535 describes Algorithm number 252 as an indirect key format
where the actual key material is elsewhere. This format was to be
defined in a separate document. In the years between RFC 2535 and
this document, no indirect key document has been prodcued.
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 KEY RR assigned to a specific algorithm. The public key area in the KEY RR
and the signature area in the SIG RR begin with a wire encoded domain and the signature area in the SIG RR begin with a wire encoded domain
name. Only local domain name compression is permitted. The domain name. Only local domain name compression is permitted. The domain
name indicates the private algorithm to use and the remainder of the name indicates the private algorithm to use and the remainder of the
public key area is determined by that algorithm. Entities should public key area is determined by that algorithm. Entities should
only use domain names they control to designate their private only use domain names they control to designate their private
algorithms. 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 KEY RR assigned to a specific algorithm. The public key area in the KEY RR
and the signature area in the SIG RR begin with an unsigned length and the signature area in the SIG RR begin with an unsigned length
byte followed by a BER encoded Object Identifier (ISO OID) of that byte followed by a BER encoded Object Identifier (ISO OID) of that
length. The OID indicates the private algorithm in use and the 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.
Editors Note: There is currently no use of or operational experience
with these algorithms. The editors (at least Dan!) recommend that
these algorithm types be eliminated. We don't need this in the base
spec and every other algorithm type requires a seperate document to
describe it in detail. Note eliminating these from the base spec
would not elminate any future functionality since there are 200+
available algorithm numbers. Anyone who feels they need this type of
algorithm (or a similar algorithm) can write the document clearly
describing it.
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 RSA/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 provides a mechanism for efficiently selecting a The Key Tag field in the SIG and DS resource record types provides a
public key. In most cases, a combination of owner name, algorithm, mechanism for selecting a public key efficiently. In most cases, a
and key tag can efficiently identify a KEY record. For example, combination of owner name, algorithm, and key tag can efficiently
both the SIG and DS resource records have corresponding KEY records. identify a KEY record. Both the SIG and DS resource records have
A Key Tag field in the SIG and DS records can be used to help corresponding KEY records. The Key Tag field in the SIG and DS
efficiently select the corresponding KEY RR when there is more than records can be used to help select the corresponding KEY RR
one candidate KEY RR available. efficiently when more than one candidate KEY 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 KEY RRs to identifier. It is theoretically possible for two distinct KEY RRs to
have the same owner name, same algorithm, and same key tag. The key have the same owner name, the same algorithm, and the same key tag.
tag is used to efficiently limit the possible candidate keys but it The key tag is used to limit the possible candidate keys, but it does
does not uniquely identify a KEY record. Implementations MUST NOT not uniquely identify a KEY record. Implementations MUST NOT assume
assume the key tag uniquely idenifies a KEY RR. that the key tag uniquely identifies a KEY RR.
The following ANSI C reference implementation is provided for
calculating a Key Tag. This reference implementation applies to all
algorithm types except algorithm 1 (see Appendix B.1). The input is
the public key material in base 64, not the entire RDATA of the KEY
record that contains the public key. The code is written for
clarity, not efficiency.
/* assumes int is at least 16 bits
first byte of the key tag is the most significant byte of return
value
second byte of the key tag is the least significant byte of
return value
*/
int keytag (
unsigned char key[], /* the RDATA part of the KEY RR */
unsigned int keysize, /* the RDLENGTH */
)
{
long int ac; /* assumed to be 32 bits or larger */
for ( ac = 0, i = 0; i &lt keysize; ++i )
ac += (i&amp1) ? key[i] : key[i]&lt&lt8;
ac += (ac>>16) &amp 0xFFFF;
return ac &amp 0xFFFF;
}
B.1 Key Tag for Algorithm 1 - RSA/MD5
Algorithm 1 - RSA/MD5 key tag is the only algoritm that does not use
the key tag defined above. For a KEY RR with algorithm 1, the key
tag is the most signifigant 16 bits of the least signifigant 24 bits
in the public key modulus. In others, the 4th to last and 3rd to
last octets in the key modulus. Note that Algorithm 1 is NOT
RECOMMENDED.
Appendix C. Canonical Form and Order of Resource Records
This section defines a canonical form for resource records (RRs) and
defines a name order and overall order. A canonical name order is
required to construct the NXT name chain. A canonical RR form and
ordering within an RRset is required to construct and verify SIG RRs.
C.1 Canonical DNS Name Order
For purposes of DNS security, owner names are sorted by treating
individual labels as unsigned left justified octet strings. The
absence of a octet sorts before a zero value octet and upper case
letters are treated as lower case letters.
To sort names in a zone, first sort all names based on only the
highest level label. Next if multiple names appear within a level,
sort based on the next highest level label. Repeat until all names
have been sorted down to leaf node labels.
For example, the following names are sorted in canonical DNS name
order. The highest label is label level is foo.example. At this
level, foo.example sorts first, followed by all names ending in
a.foo.example and then all names ending z.foo.example. The names
withing the a.foo.example level and z.foo.example level are sorted.
foo.example The key tag is the same for all KEY algorithm types except algorithm
a.foo.example 1 (please see Appendix B.1 for the definition of the key tag for
yljkjljk.a.foo.example algorithm 1). For all algorithms other than algorithm 1, the key tag
Z.a.foo.example is defined to be the output which would be generated by running the
zABC.a.FOO.EXAMPLE ANSI C function shown below with the RDATA portion of the KEY RR as
z.foo.example input. It is not necessary to use the following reference code
*.z.foo.example verbatim, but the numerical value of the Key Tag MUST be identical to
\200.z.foo.example what the reference implementation would generate for the same input.
C.2 Canonical RR Form 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 below rather than the ones complement
checksum.
For purposes of DNS security, the canonical form for an RR is the The following ANSI C reference implementation calculates the value of
wire format of the RR with 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 KEY RR. The code is written for
clarity, not efficiency.
(1) all domain names fully expanded /*
(no name compression via pointers) * Assumes that int is at least 16 bits.
(2) all domain name letters set to lower case * First octet of the key tag is the most significant 8 bits of the
(3) any owner name wild cards in master file form * return value;
(no substitution made for *) * Second octet of the key tag is the least significant 8 bits of the
(4) the original TTL substituted for the current TTL. * return value.
*/
C.3 Canonical RR Ordering Within An RRset unsigned int
keytag (
unsigned char key[], /* the RDATA part of the KEY RR */
unsigned int keysize /* the RDLENGTH */
)
{
unsigned long ac; /* assumed to be 32 bits or larger */
int i; /* loop index */
For purposes of DNS security, RRs with same owner name and same type for ( ac = 0, i = 0; i < keysize; ++i )
are sorted by treating the RDATA as a left justified unsigned octet ac += (i & 1) ? key[i] : key[i] << 8;
sequence. The absence of an octet sorts before the zero octet. ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}
C.4 Canonical Ordering of RR Types B.1 Key Tag for Algorithm 1 (RSA/MD5)
RRs with the same owner name but different types are sorted based on The key tag for algorithm 1 (RSA/MD5) is defined differently than the
the RR type number. The exception to this rule are SIG RRs, which key tag for all other algorithms, for historical reasons. For a KEY
are placed immediately after the type they cover. 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).
For example, an A record would be put before an MX record because Please note that Algorithm 1 is NOT RECOMMENDED.
type 1 (A) and is lower than type 15 (MX). If the A and MX records
were both signed, the order would be A < SIG(A) < MX < SIG(MX).
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 199 change blocks. 
630 lines changed or deleted 682 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/