< draft-ietf-dnsext-dnssec-records-01.txt   draft-ietf-dnsext-dnssec-records-02.txt >
DNS Extensions R. Arends Network Working Group R. Arends
Internet-Draft Nominum Internet-Draft
Expires: August 2, 2002 M. Larson Expires: April 29, 2003 M. Larson
VeriSign VeriSign
D. Massey D. Massey
USC/ISI USC/ISI
S. Rose S. Rose
NIST NIST
February 2002 October 29, 2002
Resource Records for DNS Security Extensions Resource Records for the DNS Security Extensions
draft-ietf-dnsext-dnssec-records-01 draft-ietf-dnsext-dnssec-records-02
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 37
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 August 2, 2002. This Internet-Draft will expire on April 29, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
The DNS Security Extensions (DNSSEC) introduce four resource records: This document is part of a family of documents that describe the DNS
the KEY, DS, SIG, and NXT resource records. This document defines
the purpose and the RDATA format for each of these records. This
document is part of a family of documents that describe the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a Security Extensions (DNSSEC). The DNS Security Extensions are a
collection of new resource records and protocol modifications that collection of resource records and protocol modifications that
provide source authentication for the DNS. This document obsoletes provide source authentication for the DNS. This document defines the
RFC 2535 and incorporates changes from all updates to RFC 2535. KEY, DS, SIG, and NXT resource records. The purpose and format of
each resource record is descibed in detail and an example of each
resource record is given.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document obsoletes RFC 2535 and incorporates changes from all
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this updates to RFC 2535.
document are to be interpreted as described in RFC 2119 [4].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 DNSSEC Document Family . . . . . . . . . . . . . . . . . . 4 1.1 Background and Related Documents . . . . . . . . . . . . . 4
2. The Key Resource Record . . . . . . . . . . . . . . . . . 5 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . 4
2.1.1.1 Explanation for Choice of Bit 7 . . . . . . . . . . . . . 6 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . 4
2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 6 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . 5
2.1.2.1 Explanation for a Fixed Value Protocol Octet Field . . . . 6 2. The KEY Resource Record . . . . . . . . . . . . . . . . . 6
2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 6 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6
2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 7
2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 7
2.1.4 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . 7
2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7
2.3 KEY RR Examples . . . . . . . . . . . . . . . . . . . . . 7 2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 8
3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9 3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9
3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9 3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10
3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10
3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10
3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10
3.1.5 Signature Expiration and Inception Fields . . . . . . . . 10 3.1.5 Signature Expiration and Inception Fields . . . . . . . . 11
3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 10 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 11
3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11
3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11
3.2 The NXT RR Presentation Format (placeholder) . . . . . . . 11 3.2 Calculating A Signature . . . . . . . . . . . . . . . . . 12
3.3 Calculating the signature . . . . . . . . . . . . . . . . 11 3.2.1 Calculating An RRset Signature . . . . . . . . . . . . . . 12
4. The NXT Resource Record . . . . . . . . . . . . . . . . . 13 3.2.2 Calculating An Transaction Signature . . . . . . . . . . . 12
4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 13 3.3 The SIG RR Presentation Format . . . . . . . . . . . . . . 13
4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 13 3.4 Example of a SIG RR . . . . . . . . . . . . . . . . . . . 13
4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 13 4. The NXT Resource Record . . . . . . . . . . . . . . . . . 15
4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 14 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 15
5. The DS Resource Record . . . . . . . . . . . . . . . . . . 15 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 15
5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 16
5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 15 4.1.2.1 Alternate Formats for the Type Bit Map Field . . . . . . . 16
5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 15 4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . 16
5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 16 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 16
5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 16 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . 17
5.2 DS Record Example . . . . . . . . . . . . . . . . . . . . 16 5. The DS Resource Record . . . . . . . . . . . . . . . . . . 18
5.3 Resolver Example . . . . . . . . . . . . . . . . . . . . . 16 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18
6. DNSSEC message bits . . . . . . . . . . . . . . . . . . . 18 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 18
6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 18 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 19
6.2 The DO Extended Flags Field Bit . . . . . . . . . . . . . 18 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 20 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . 21 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 22 5.3 DS Record Example . . . . . . . . . . . . . . . . . . . . 20
References . . . . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . 22
A. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23
Full Copyright Statement . . . . . . . . . . . . . . . . . 26 References . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 25
A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . 26
A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 26
A.1.1 Indiret and Private Algorithm Types . . . . . . . . . . . 26
A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 27
B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 28
B.1 Key Tag for Algorithm 1 - RSA/MD5 . . . . . . . . . . . . 29
C. Canonical Form and Order of Resource Records . . . . . . 30
C.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 30
C.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 30
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 reader to assumed to be familiar with common DNSSEC terminology
as defined in [13] and familiar with the basic DNS concepts described
in RFC1034 [1] and RFC1035 [2].
The DNS Security Extensions (DNSSEC) introduce four resource records: The DNS Security Extensions (DNSSEC) introduce four resource records:
KEY, DS, SIG, and NXT resource records. This document defines the the KEY, SIG, NXT, and DS resource records. This document defines
purpose of each resource record, the RDATA format, the ASCII the purpose of each resource record (RR), the RR's RDATA format, and
representation, and an example of each RR type is given. Sections 2- its ASCII representation. An example of each RR type is also given.
5 describe the KEY, DS, SIG, and NXT records. Section 6 describe the
DNSSEC header bits.
1.1 DNSSEC Document Family 1.1 Background and Related Documents
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
(RFC TBA). A description of DNS protocol modifications can be found [13]. A description of DNS protocol modifications can be found in
in (RFC TBA). This document defines the DNSSEC resource records. [14]. This document defines the DNSSEC resource records.
2. The Key Resource Record 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].
Public keys used by the DNS infrastructure are stored in KEY resource 1.2 Reserved Words
records. A secure DNS zone will store its public key in a KEY RR and
this KEY RR can be used to authenticate other RR sets in the zone.
The KEY RR MAY also be used to store other types of DNS public keys,
such as the keys used by SIG(0) [10] or TKEY [9]. These public keys
are used to authenticate DNS messages such as a request to
dynamically update a DNS zone.
The KEY RR MUST only be used for public keys used for DNS purposes, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
all other uses are obsolete. The KEY RR plays an essential role in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
the secure processing of DNS messages and is included in various document are to be interpreted as described in RFC 2119 [4].
responses. The KEY RR MUST NOT be used to store certificates or
public keys that do not directly relate to the DNS infrastructure. 1.3 Editors Notes
Examples of certificates and public keys that MUST NOT be stored in
the KEY RR include X.509 certificates, IPSEC public keys, and SSH 1.3.1 Open Technical Issues
public keys.
The NXT section (Section 4) requires input from the working group.
Since the opt-in issue is not resolved, this text describes the NXT
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 working group. The DSA algorithm was moved to OPTIONAL. This
had strong consensus in workshops and various discussions and a
seperate internet draft solely to move DSA from MANDATORY to OPTIONAL
seemed excessive. This draft solicts 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
Please report technical corrections to dnssec-editors@east.isi.edu.
To assist the editors, please indicate the text in error and point
out the RFC that defines the correct behavior. For a technical
change where there is no RFC that defines the correct behavior (or
RFCs provide conflicting answers), please post the issue to
namedroppers.
An example correction to dnssec-editors might be: Page X says
"DNSSEC RRs SHOULD be automatically returned in responses." This was
true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
DNSSEC RR types MUST NOT be included in responses unless the resolver
indicated support for DNSSEC.
1.3.3 Typos and Minor Corrections
Please report any typos corrections to dnssec-editors@east.isi.edu.
To assist the editors, please provide enough context for us to
quickly find the incorrect text.
An example message to dnssec-editors might be: page X says "the
DNSSEC standard has been in development for over 1 years". It
should read "over 10 years".
2. The KEY Resource Record
DNSSEC uses public key cryptogrpahy to sign and authenticate DNS
resource record sets (RRsets). The public keys are stored in KEY
resource records and are used in the DNSSEC authentication process
described in [14]. In a typical example, a zone signs its
authorititave RRsets using a private key and stores the corresponding
public key in a KEY RR. A resolver can then use these signatures to
authenticate RRsets from the zone.
The KEY RR is also used to store public keys associated with other
DNS operations, such as SIG(0) [14] and TKEY [9]. In all cases, the
KEY RR plays a special role in secure DNS resolution and DNS message
processing. The KEY RR is not intended as a record for storing
arbitrary public keys. The KEY RR MUST NOT be used to store
certificates or public keys that do not directly relate to the DNS
infrastructure. Examples of certificates and public keys that MUST
NOT be stored in the KEY RR include X.509 certificates, IPSEC public
keys, and SSH public keys.
The type number for the KEY RR is 25. The type number for the KEY RR 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
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 Fields, a Protocol
Octet, a one octet Algorithm number, and the public key. Octet, a one octet Algorithm Number, and the Public Key.
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". Bits 0-6 and 8-15 Bit 7 of the Flags field is the Zone Key flag. If bit 7 is 1, then
are reserved for future use. Bits 0-6 and 8-15 MUST be set to 0 and the KEY record holds a DNS zone key and the KEY's owner name MUST be
MUST be ignored during processing. the name of a zone. If bit 7 is 0, then the KEY record holds some
other type of DNS public key, such as a public key used by SIG(0) or
The zone key flag (bit 7) determines whether the KEY holds a DNS zone TKEY.
key. If bit 7 is 1, then the KEY record holds a DNS zone key. If
bit 7 is 0, then the KEY record holds some other type of DNSSEC
infrastructure public key, such as a public key used by SIG(0) or
TKEY. Resolvers MUST check the zone key flag in order to determine
if the KEY record holds a DNS zone key.
2.1.1.1 Explanation for Choice of Bit 7
The choice of bit 7 as the zone key flag was made in order to provide Bits 0-6 and 8-15 are reserved for future use and MUST be zero.
backwards compatibility with an earlier version of the KEY record.
This earlier version was defined in [6] and [15] eliminated all flags
except the bit 7 zone key flag.
2.1.2 The Protocol Octet Field 2.1.2 The Protocol Octet Field
The Protocol Octet value MUST be 3. The Protocol Octet field MUST be 3.
2.1.2.1 Explanation for a Fixed Value Protocol Octet Field
The Protocol Octet field is included for backwards compatibility with
an earlier version of the KEY record. This earlier version of the
KEY record was defined in [6] and [15] restricted the possible
Protocol Octet values to 3.
2.1.3 The Algorithm and Public Key Fields 2.1.3 The Algorithm and Public Key Fields
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. algorithm and determines the format of the Public Key field. A list
of DNSSEC algorithm types can be found in Appendix A.1
Algorithm values are defined in separate documents. The following
table shows the currently defined Algorithm formats:
VALUE Algorithm RFC STATUS
0 Reserved - -
1 RSA/MD5 RFC 2536 NOT RECOMMENDED
2 Diffie-Hellman RFC 2539 OPTIONAL
3 DSA RFC 2536 MANDATORY
4 elliptic curve Work in Progress
5 RSA/SHA1 RFC 3110 MANDATORY
6-251 available for assignment -
252 reserved - indirect keys
253 private - domain name
254 private - OID
255 reserved - -
It is expected that a signed zone will contain at least one KEY
record with one of the MANDATORY algorithms. A DNS security aware
resolver MUST implement all MANDATORY and SHOULD implement all
OPTIONAL algorithms. Currently RSA/MD5 is NOT RECOMMENDED for zone
signing, but it may be found in older DNS implementations.
Therefore, if may be useful for a security aware resolver to
implement RSA/MD5 as well as RSA/SHA1.
Algorithm number 252 is reserved for indirect key format where the 2.1.4 Notes on KEY RDATA Design
actual key material is elsewhere (non-DNS). This format will be
defined in a separate document.
Algorithm numbers 253 and 254 are reserved for private use and will Although the Protocol Octet field is always 3, it is retained for
never be assigned a specific algorithm. For number 253, the public backwards compatibility with an earlier version of the KEY record.
key area and the signature begin with a wire encoded domain name The use of bit 7 as the Zone Key Flag is also due to backwards
indicating the algorithm the key uses. Only local domain name compatiblity issues.
compression is permitted. The remainder of the public key area is
privately defined. For number 254, the public key area for the KEY
RR and the signature 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
domain names and OIDs they control to designate their private
algorithms.
2.2 The KEY RR Presentation Format 2.2 The KEY RR Presentation Format
A KEY RR may appear as a single line. The presentation format of the A KEY RR may appear as a single line or multiple lines separated with
RDATA portion is as follows: newline characters if those lines are contained with parantheses.
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 integer.
The Protocol Octet field is represented as the unsigned integer 3. The Protocol Octet field is represented as the unsigned integer 3.
The Algorithm Field is represented as an unsigned integer or as The Algorithm field is represented as an unsigned integer or as an
mnemonic specified. The mnemonic is listed in the document defining algorithm mnemonic specified in Appendix A.1.
the algorithm.
The Public Key Field is a Base 64 encoding of the Public Key Field.
2.3 KEY RR Examples The Public Key field is a Base 64 encoding of the Public Key Field.
2.3.1 Example 1 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 isi.edu.
isi.edu. 86400 IN KEY 256 3 5 ( AQPT0sh3WjVeRY3WqpBjtf isi.edu. 86400 IN KEY 256 3 5 ( AQPT0sh3WjVeRY3WqpBjtf
<snip of base64 encoded text> <snip of base64 encoded text>
xxDw==) xxDw==)
256 indicates the flags field has the zone key bit is set. 3 is the The first four fields specify the owner name, TTL, Class, and RR type
fixed Protocol Octet value. 5 indicates the public key algorithm is (KEY). 256 indicates the Flags field has the zone key bit is set. 3
RSA/SHA1 RFC 3110]. The remaining text is base 64 encoding of the is the fixed Protocol Octet value. 5 indicates the public key
public key and the format of the public key is defined in [12]. 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
Resolvers might use this public key to authenticate signed RR sets in [12]. The remaining text is a base 64 encoding of the public key.
such as the A RR set for www.isi.edu. The authentication process
used by resolvers is described in [14].
2.3.2 Example 2
The following KEY RR stores a public key used by SIG(0)
ddnskey.isi.edu. 86400 IN KEY 0 3 3 ( AQPT0sh3WjVeRY3WqpBjtf
<snip of base64 encoded text>
xxDw==)
0 indicates the flags field does not have the zone key bit is not
set. 3 is the fixed Protocol Octet value. 5 indicates the public
key algorithm is DSA [7]. The remaining text is base 64 encoding of
the public key and the format of the public key is defined in [7].
This public key can be used to sign dynamic DNS updates for the
isi.edu zone. The process is for signing the dynamic DNS updates is
described in [11].
3. The SIG Resource Record 3. The SIG Resource Record
The SIG or "signature" resource record (RR) is the fundamental way DNSSEC uses public key cryptogrpahy to sign and authenticate DNS
that data is authenticated in the secure Domain Name System (DNS). resource record sets (RRsets). The signatures are stored in SIG
As such it is the heart of the security provided. resource records and are used in the DNSSEC authentication process
described in [14]. In a typical example, a zone signs its
authorititave RRsets using a private key and stores the corresponding
signatures in SIG RRs. A resolver can then use these signatures to
authenticate RRsets from the zone.
The SIG RR authenticates an RRset [5] of a particular type, class, A SIG record contains the signature for an RRset with a particular
and name and binds it to a time interval and the signer's name. The name, class, and type. The SIG RR is said to "cover" this RRset.
signer is the key (and associated KEY record) from which the RR The SIG RR also specifies a validity interval for the signature and
originated. A SIG record can also be used for transaction security uses an algorithm signer's name, and key tag to identify the public
[transaction ref/section]. This type of SIG is known as SIG(0) and key (KEY record) that can be used to verify the signature.
its RDATA is in the same format, with some values loosing their
meaning and given default values. The variations are mentioned in The signature in SIG RR may also cover a transaction rather than an
[10]. RRset [14]. In this case, the "Type Covered" field is set to 0 and
the SIG RR is refered to as SIG(0) resource record.
The type number for the SIG RR type is 24. The type number for the SIG RR type is 24.
The SIG RR is class independent, but MUST have the same class as the The SIG RR is class independent, but MUST have the same class as the
RRset it covers. The TTL for the SIG RR SHOULD be the same as the
RRset it covers. RRset it covers.
The SIG RR TTL SHOULD match the TTL of the RRset it covers.
3.1 The SIG RDATA 3.1 The SIG RDATA
The RDATA portion of a SIG RR is as shown below: The RDATA portion of a SIG RR is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type covered | algorithm | labels | | type covered | algorithm | labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| original TTL | | original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration | | signature expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 7 skipping to change at page 10, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name +
| / | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/ / / /
/ signature / / signature /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1 The Type Covered Field 3.1.1 The Type Covered Field
For RRset SIGs, the type covered MUST be the same as the type of data The Type Covered field identifies the RRset type covered by the SIG
in the associated RRset. For SIG(0), this field MUST be zero [10] record.
If Type Covered field is set to 0, the record is referred to as a
SIG(0) RR and its signature covers a transaction rather than a
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 in the RDATA is the same field as found in The Algorithm Number field identies the cryptographic algorithm used
the algorithm field of the KEY record RDATA [section 2.2.3]. to create the signature. A list of DNSSEC algorithm types can be
found in Appendix A.1
3.1.3 The Labels Field 3.1.3 The Labels Field
The "labels" octet is an unsigned count of how many labels there are The Labels field specifies the number of labels in the original SIG
in the original SIG RR owner name. This does not count null labels RR owner name. It is included to handle signatures associated with
for root and any initial "*" for a wildcard. The labels count MUST wildcard owner names.
be less than or equal to the number of labels in the SIG owner name.
To validate the signature, a resolver requires the original owner
name that was used when the signature was created. In most cases,
the owner name used when the signature was created is identical to
the owner name sent in any response. However, a wildcard owner name
will be expanded during the query/response process and [14] describes
how the label count is used to reconstruct the original (unexpanded)
owner name.
The Labels field does not count null labels for root and does not
count any initial "*" in a wildcard name. The Labels field MUST be
less than or equal to the number of labels in the SIG owner name.
For example, "www.example.com." has a label count of 3 and
"*.example.com." has a label count of 2.
3.1.4 Original TTL Field 3.1.4 Original TTL Field
The "original TTL" field is included in the RDATA portion to avoid The Original TTL field specifies the original TTL of the covered
authentication problems caused by caching servers decrementing the RRset.
real TTL field. The signatures covers this field (as part of the SIG
RDATA) while the TTL field is not. In a SIG(0), the Original TTL
field (and the TTL field) MUST be zero.
The "original TTL" value MUST be greater than or equal to the TTL of To validate the signature, a resolver requires the original TTL used
the SIG record itself. when the signature was created. However, caching servers will
decrement the TTL and [14] describes how the Original TTL field count
is used to reconstruct the original (undecremented) TTL.
If the Type Covered field is non-zero, the Original TTL value MUST be
greater than or equal to the TTL of the SIG record itself. If the
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 SIG is valid from the "signature inception" time until the The Signature Inception and Signature Expiration fields specify a
"signature expiration" time. Both are unsigned numbers of seconds validity period for the signature. The SIG record MUST NOT be used
since the start of 1 January 1970, GMT, ignoring leap seconds. Ring for authentication prior to the inception date and MUST NOT be used
arithmetic is used as for DNS SOA serial numbers [3], which means for authentication after the expiratiation date.
that these times can never be more than about 68 years in the past or
the future. This means that these times are ambiguous modulo ~136.09
years.
A SIG RR may have an expiration time numerically less than the Inception and expiration dates are given as 32-bit unsigned numbers
inception time if the expiration time is near the 32-bit wrap around of seconds since the start of 1 January 1970 GMT, ignoring leap
point and/or the signature is long lived. seconds. Ring arithmetic [3] to handle 32-bit wrap around. As
result, these times can never be more than 68 years in the past or
the future and the times are ambiguous modulo ~136 years. A SIG RR
can have an expiration time numerically smaller than the inception
time if the expiration time is near the 32-bit wrap around point and/
or the signature is long lived.
3.1.6 The Key Tag Field 3.1.6 The Key Tag Field
The "Key Tag" is a two-octet quantity that is used to efficiently The Key Tag field contains the key tag of the public key (KEY RR)
select between multiple keys that may be applicable. The Key Tag used to authenticate this signature. The process of calculating a
value may differ depending on the key algorithm in use, as described key tag is given in Appendix B.
in Appendix (A).
3.1.7 The Signer's Name Field 3.1.7 The Signer's Name Field
The signer's name field MUST contain the name of the zone to which The Signer's Name field identifies the name of the KEY RR used to
the data and signature belong. The combination of signer's name, key authenticate this signature. If the Type Covered field is non-zero,
tag, and algorithm MUST identify a zone key if the SIG is to be the Signer's Name MUST contain the name of the zone containing the
considered material. In a SIG(0), the signer's name MUST be the covered RRset and the SIG. The signer's name MAY be compressed with
originating host of the DNS message [10]. standard DNS name compression when being transmitted over the
network.
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 actual signature portion of the SIG RR binds the other RDATA The Signature field contains the cryptographic signature. If the
fields to the RRset of the "type covered" RRs with that owner name Type Covered field is non-zero, the signature covers the SIG RDATA
and class. (excluding the Signature field) and the RRset specified by the SIG
owner name, SIG class, and SIG Type Covered field.
3.2 The NXT RR Presentation Format (placeholder) 3.2 Calculating A Signature
This section will be here in the next revision. 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.3 Calculating the signature 3.2.1 Calculating An RRset Signature
To generate the signature over an RRset, a data sequence is A signature covers the SIG RDATA (excluding the Signature Field
constructed as follows (where "|" is concatenation): itself) and covers the RRset specified by the SIG owner name, SIG
class, and SIG Type Covered field. The RRset is in cannonical form
(see Appendix C) and the set RR(1),...RR(n) is signed as follows:
signature = sign(RDATA | RR(1) | RR(2)... ) signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where
RR(N) = name | class | type | original TTL(stored in SIG RDATA) | "|" denotes append
RDATA
To generate a signature over a DNS message (SIG(0)), a data sequence SIG_RDATA is the wire format of the SIG RDATA fields with
is constructed as follows: the Signer's Name field in cannonical form.
the Signature field excluded.
If the DNS message is sent via UDP: RR(i) = fqdn | class | type | TTL | RDATA length | RDATA
signature = sign(RDATA | full query | full response - SIG(0)) fqdn is the Fully Qualified Domain Name in canonical
form.
If the DNS message is sent via TCP, the first packet's SIG(0) is All RR(i) MUST have the same fqdn as the SIG RR.
calculated as above, with each additional packet (if any) calculated
as follows:
signature = sign(RDATA | DNS payload - SIG(0) | previous packet) All RR(i) MUST have the same class as the SIG RR.
where "previous packet" is the previous DNS packet with accompanying All RR(i) MUST have the RR type listed in SIG RR's
SIG(0), but without any other headers (i.e. TCP/IP, etc.). Type Covered field.
In all the examples, All RR(i) MUST have the TTL listed in the SIG Original
TTL Field
RDATA is the wire format of all the RDATA fields in the SIG RR itself All names in the RDATA field are in canonical form
(including the canonical form of the signer's name) before but not
including the signature, and
RR(num) is the RRset with the same owner name and class and type The set of all RR(i) is sorted into cannonical order.
covered as the SIG RR in canonical form.
Name is the Fully Qualified Domain Name (FQDN) in canonical form. 3.2.2 Calculating An Transaction Signature
3.3 The SIG RR Presentation Format
The canonical form for a Resource Record (RR) is the wire format of A SIG RR may appear as a single logical line. The presentation
the RR. Names MUST be expanded (no name compression allowed). Name format of the RDATA portion is as follows:
characters MUST be set to lower case. Wildcards MUST be unexpanded.
The RR MUST have the original TTL.
How this data sequence is processed into the signature is algorithm The Type Covered field is represented by either an unsigned integer
dependent. These algorithm dependent formats and procedures are or the mnemonic for the RR type.
described in separate documents.
SIGs SHOULD NOT be generated for any "meta-type" such as ANY, AXFR, The Algorithm field is represented as an unsigned integer or as an
etc. algorithm mnemonic specified in Appendix A.1.
4. The NXT Resource Record The Labels field is represented as an unsigned integer.
The collection of NXT or "next" resource records (RR) is used to The Original TTL field is represented as an unsigned integer. It MAY
indicate what names and RRsets [5] exist in a zone. be omitted if it is equal the TTL of the SIG RR.
The NXT RR lists the next canonical name in the zone and lists what The Signature Inception Time and Expiration Time fields are
RR types are present for the current name of the NXT RR. represented in the form YYYYMMDDHHmmSS, where:
The set of NXT RRs in a zone is a chain of all authoritative names in YYYY is the year
that zone.
Glue address records MUST NOT be covered by a NXT RR. MM is the month number (01-12)
DD is the day of the month (01-31)
HH is the hour in 24 hours notation (00-23)
mm is the minute (00-59)
SS is the second (00-59)
The Key Tag field is represented as an unsigned integer.
The Signer's Name field is represented as a domain name.
The Signature field is a Base 64 encoding of the signature.
3.4 Example of a SIG RR
The following a SIG RR stores the signature for the the A RRset of
host.example.com:
host.example.com. 30 IN SIG A 3 3 30 20011231120000 (
20011108100000 65531 example.com
CGr0uS55C4l/2RRc2NrMJbRt4oP+xVxwgMkC
rJFXXDsybfEDdwoajAY= )
The first four fields specify the owner name, TTL, Class, and RR type
(SIG). The "A" represents the Type Covered field. is the algorithm
used to create this signature. The first 3 identifies the Algorithm
used to create the signature. The second 3 is the number of Labels
in the original owner name and the 30 is the Original TTL for this
SIG RR and the covered A RRset. The two dates are the expiration and
inception dates. 65531 is the Key Tag and example.com. is the
Signer's Name. The remaining text is a base 64 encoding of the
signature.
Note that combination of SIG RR owner name, class, and and Type
Covered indicate this SIG covers the "host.example.com" A RRset. The
Label value of 3 indicates no wildcard expansion was used. The
Algorithm, Signer's Name, and Key Tag indicate this signature can be
authenticated using an example.com zone KEY RR whose algorithm is 3
and key tag is 65531.
4. The NXT Resource Record
The NXT resource record lists the RR types present at the NXT's owner
name and lists the next canonical name in the zone. The collection
of NXT or "next" resource records indicate what RRsets exist in a
zone and provide a chain of all authoritative owner names in that
zone. This information can be used for authenticated denial of
existence, as desribed in [14].
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 number 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 zone minimum TTL. 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 owner name in The Next Domain Name field contains the next authoritive owner name
canonical order. Canonical order means sorted by label, highest in canonical order, where canonical order is defined in Appendix C.1.
level label first. The "next domain name" field of the NXT RR at the For the last owner name in the zone, the Next Domain Name field
last name in the zone contains the zone apex name. contains the zone apex name.
Glue address record names MUST NOT be covered by the "next domain The Next Domain Name field allows message compression.
name" field.
The "next domain name" field allows message compression. Note that non-authoritative glue address record names may exist in a
zone, but these non-authoritative glue records MUST NOT be listed in
the Next Domain Name. Any non-authoritative glue records are ignored
(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 format contains a single bit per RR type for The Type Bit Map field identifies the RRset types that exist at the
RRsets with the same owner name as the NXT RR. A one bit indicates NXT's owner name.
that an RRset of that type exist for the owner name. A zero bit
indicates that no RRset of that type exist for the owner name.
The first bit represents RR type zero. RR type number zero is not Each bit in the Type Bit Map field corresponds to an RR type. Bit
assigned and the corresponding bit MUST be zero. If the zero bit is one corresponds to RR type 1 (A), bit 2 corresponds to RR type 2
one, it indicates that an unspecified format is used. This format is (NS), and so forth. If a bit is set to 1, it indicates that an RRset
not used when there exist an RR type number greater than 127. of that type exists for the NXT's owner name. If a bit is set to
zero, it indicates that no RRset of that type exists for the NXT's
owner name.
The OPT RR [8] type MUST NOT be covered by the type bit map field Trailing zero octets MUST be omitted. Thus the length of the Type
since it is not part of the zone data. The corresponding OPT RR type Bit Map field varies and is dependent on the largest RR type present
bit (40) MUST be zero. for the NXT's owner name. Trailing zero octets not specified MUST be
interpreted as zero octets.
Trailing zero octets MUST be omitted. Trailing zero octets not Non-authoritative glue address record types MUST NOT be used when
specified MUST be interpreted as zero octets. Glue address record constructing the type bit map field. The OPT RR [8] type (41) also
types MUST NOT be covered by the type bit map field. 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
The above Type Bit Map format MUST NOT be used when an RR type number
greater than 127 is in use.
Bit 0 in the Type Bit Map Field is used to indicate an alternate
format for the Type Bit Map field. If bit 0 is set to 1, it
indicates some other format is being used for this field. No
alternate formats are defined as of this writing.
4.1.3 Inclusion of Wildcard Names in NXT RDATA
If a wildcard owner name appears in a zone, the wildcard is treated
as a literal symbol and is treated the same as any other owner name.
Wildcard owner names appear (unexpanded) in the Next Domain Name
field without any wildcard expansion. [14] describes the impact of
wildcards on authetnicated 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 A NXT RR may appear as a single line. 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 as a sequence of RR type
mnemonics or as an unsigned integer. mnemonics or as a sequence of unsigned integers denoting the RR
types.
4.3 NXT RR Example
The following NXT RR identifies the RRsets associated with
a.example.com and identifies the next authoritative name after
a.example.com.
a.example.com. 86400 IN NXT c.example.com. A MX NXT
The first four fields specify the name, TTL, Class, and RR type
(NXT). The entry c.example.com is the next authoritative name after
a.example.com (in cannonical order). The A MX and NXT nnemonics
indicate there are A, MX, and NXT RRsets associated with the name
a.example.com.
Note the NXT record can be used for authenticted denial of existence.
If the example NXT record were authenticed, it could be used to prove
that b.example.com does not exist or could be used to prove there is
no AAAA record assoicated with a.example.com. Authenticated denial
of existence is discussed in [14]
5. The DS Resource Record 5. The DS Resource Record
The DS record is a major change to DNS: it is the first resource The DS Resource Record points to a KEY RR and is used in the DNS KEY
record that can appear only on the upper side of a delegation. Other authentication process. A DS RR points to a KEY RR by storing the
keys MAY sign the child's apex KEY RRset. DS records MUST point to key tag, algorithm number, and a digest of KEY RR. Note that while
zone KEY records that are allowed to authenticate DNS data. the digest should be sufficient to identify key, storing the key tag
and key algorithm helps make the identification process more
efficient and more secure. By authenticating the DS record, a
resolver can authenticate the KEY RR pointed to by the DS record.
The key authentication proces is described in [14].
The DS RR and its corresponding KEY RR both have the same owner name,
but they are stored in different locations. The DS RR is the first
resource record that appears only on the upper side of a delegation.
In other words, the DS RR for "example.com" is stored in "com" (the
upper side of the delegation). The corresponding KEY RR is stored in
the "example.com" zone (the lower side of the delegation). This
simplifies DNS zone management and zone signing, but introduces
special response processing requirements that are described in [14].
The type number for the DS record is 43. The type number for the DS record is 43.
The DS record is class independent. The DS resource record is class independent.
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
This record contains these fields: key tag, algorithm, digest type, The RDATA for a DS RR consists of 2 octet Key Tag, a one octet
and the digest of a public key KEY record that is allowed and/or used Algorithm Number, a one octet Digest Type, and a Digest.
to sign the child's apex KEY RRset.
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / /
| (20 bytes for SHA-1) | / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.1 The Key Tag Field 5.1.1 The Key Tag Field
The key tag value is the same key tag value in the SIG RRs generated The Key Tag field lists the key tag of the KEY RR pointed to by the
using the KEY record this DS record points too. Having the key tag DS record. The KEY RR MUST be a a zone key. In other words, the KEY
in the RDATA provides additional reliability in matching than just RR Flags must have Flags bit 7 set to 1.
the KEY digest alone. See the key tag for details.
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.
5.1.2 The Algorithm Field 5.1.2 The Algorithm Field
The algorithm value has the same defined values as the KEY and SIG The Algorithm field lists the algorithm number of the KEY RR pointed
records. The value MUST be an algorithm number assigned in the range to by the DS record.
1..251 and the algorithm MUST be allowed to sign DNS data.
5.1.3 The Digest Type Field 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
algorithm number types.
The digest type is an identifier for the digest algorithm used. The 5.1.3 The Digest Type Field
following numbers have been assigned and the assignment of future
numbers requires IETF standards action.
VALUE Algorithm STATUS The DS RR points to a KEY RR by including a digest of that KEY RR.
0 Reserved - The Digest Type field identifes the algorithm used to construct the
1 RSA/SHA-1 MANDATORY digest and Appendix A.2 lists the possible digest algorithm types.
2-255 Unassigned -
5.1.4 The Digest Field 5.1.4 The Digest Field
The digest is calculated over the canonical name of the delegated The DS record points to a KEY RR by including a digest of that KEY
domain name followed by the whole RDATA of the KEY record (all four RR. The Digest field hold the digest.
fields). The size of the DS RDATA for type 1 (SHA-1) is 24 bytes,
regardless of key size. Other digest algorithms may have a differing
digest size, to be described in other documents.
digest = hash( cannonical FQDN on KEY RR | KEY_RR_rdata)
KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
5.2 DS Record Example
The presentation format of the DS record consists of three numbers
(key tag, algorithm and digest type) followed by the digest itself
presented in hex:
example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890
This is a example of a KEY record and corresponding DS record.
dskey.example. KEY 256 3 1 ( For a given KEY RR, the digest is calculated by appending the KEY
encoded public key RR's cannonical fully qualified owner name with the KEY RDATA and
) ; key id = 28668 then applying the digest algorithm.
DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
5.3 Resolver Example digest = digest_algorithm( cannonical FQDN of KEY RR | KEY_RR_rdata)
To create a chain of trust, a resolver goes from trusted KEY to DS to "|" denotes append
KEY.
Assume the key for domain "example." is trusted. Zone "example." KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
contains at least the following records:
example. SOA (soa stuff)
example. NS ns.example.
example. KEY (encoded public key)
example. NXT NS SOA KEY SIG NXT
example. SIG(SOA)
example. SIG(NS)
example. SIG(NXT)
example. SIG(KEY)
secure.example. NS ns1.secure.example.
secure.example. DS tag=10243 alg=3 digest_type=1
secure.example. NXT NS SIG NXT DS unsecure.example.
secure.example. SIG(NXT)
secure.example. SIG(DS)
unsecure.example NS ns1.unsecure.example.
unsecure.example. NXT NS SIG NXT .example.
unsecure.example. SIG(NXT)
In zone "secure.example." following records exist: The size of the digest can vary depending on the digest algorithm and
secure.example. SOA (soa stuff) KEY RR size. However, the only currently defined digest algorithm is
secure.example. NS ns1.secure.example. SHA-1 and it always produces a 24 byte digest regardless of KEY RR
secure.example. KEY (tag=12345 alg=3) size.
secure.example. SIG(KEY) (key-tag=12345 alg=3)
secure.example. SIG(SOA) (key-tag=12345 alg=3)
secure.example. SIG(NS) (key-tag=12345 alg=5)
In this example the private key for "example." signs the DS record 5.2 The DS RR Presentation Format
for "secure.example.", making that a secure delegation. The DS
record states which key is expected to sign the RRsets at
"secure.example.". Here "secure.example." signs its KEY RRset with
the KEY identified in the DS RRset, thus the KEY RRset is validated
and trusted.
This example has only one DS record for the child, but parents MUST A DS RR may appear as a single line or multiple lines separated with
allow multiple DS records to facilitate key rollover. It is strongly newline characters if those lines are contained within parantheses.
recommended that the DS RRset be kept small: two or three DS records The presentation format of the RDATA portion is as follows:
should be sufficient in all cases.
The resolver determines the security status of "unsecure.example." by The Key Tag field is represented as an unsigned integer.
examining the parent zone's NXT record for this name. The absence of
the DS bit indicates an unsecure delegation.
6. DNSSEC message bits The Algorithm field is represented as an unsigned integer or as an
algorithm mnemonic specified in Appendix A.1.
There are 3 new bits allocated for use with DNSSEC. The DO bit is The Digest Type field is represented as an unsigned integer.
used to indicate to a server that the resolver is able to accept
DNSSEC security RRs (KEY SIG NXT DS). The CD and AD bits are used to
indicate if non-authenticated data is accepted, and if data is
authenticated.
6.1 The AD and CD Header Bits The Digest is presented in hexadecimal.
Two bits are allocated in the header section. The CD (checking 5.3 DS Record Example
disabled) bit and the AD (authentic data) bit.
The Header contains the following fields: The following example shows a KEY RR and its corresponding DS RR.
1 1 1 1 1 1 dskey.example. 86400 IN KEY 256 3 1 ( AQPwHb4UL1U9RHaU8qP+Ts5bVOU
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1s7fYbj2b3CCbzNdj4+/ECd18yKiy
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ UQqKqQFWW5T3iVc8SJOKnueJHt/Jb
| ID | /wt) ; key tag = 28668
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ dskey.example. 3600 IN DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The usage of the CD and AD bits are defined in [14] The first four fields specify the name, TTL, Class, and RR type (DS).
28668 is the key tag for the corresponding "dskey.example." KEY RR
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.2 The DO Extended Flags Field Bit 6. IANA Considerations
The DO (DNSSEC OK) bit is allocated from the EDNS0 [8] extended flags This document introduces no new IANA considerations.
field. In the context of the OPT RR, the DO bit is the most
significant bit in the 3rd octet of the TTL field.
The TTL field of the OPT RR is defined as follows: This document only clarifies the use of existing DNS resource
records. However for completeness, the IANA considerations from
these previous documents are summarized below. No IANA changes are
made by this document.
1 1 1 1 1 1 RFC 2535 updated the IANA registry for DNS Resource Record Types and
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 assigned types 24,25, and 30 to the SIG, KEY, and NXT (respectively).
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ [DS RFC] assigned DNS Resource Record Type 43 to DS.
| EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|DO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The usage of the DO bit is defined in [14]
7. IANA Considerations RFC 2535 created an IANA registry for DNSSEC Resource Record
Algorithm Numbers. Values to 1-4, and 252-255 were assigned by RFC
2535. Value 5 was assigned by RFC 3110.
This document clarifies the use of existing types and introduces no [DS RFC] created an IANA registry for DNSSEC DS Digest Types and
new IANA considerations. assigned value 0 to reserved and value 1 to RSA/SHA-1.
The definitions of the flag bits in the KEY RR are set by working RFC 2535 created an IANA Registry to KEY Protocol Octet Values, but
group consensus and there is no IANA registry for their definition. [KeyRestrict RFC] set all assigned values other than 3 to reserved
Changes to the meaning of the bits in the flags section of the KEY and closed this IANA registry. The registry remains closed and all
RDATA must be done through working group consensus. KEY records are required to have Protocol Octet value of 3.
RFC 2535 created an IANA registry for DNSSEC Resource Record The Flag bits in the KEY RR are not assigned by IANA and there is no
algorithm Octet values. Values to 1-5, and 255 were assigned and IANA registry for these flags. All changes to the meaning of the KEY
values 6-254 were made available for assignment by IANA. This RR Flag bits require a standards action.
document re-assigns DNS KEY Resource Record Protocol Octet values 1,
2, 4, and 255 to ``reserved''. DNS Key Resource Record Protocol
Octet Value 3 remains unchanged as ``DNSSEC''.
New protocol values are no longer available for assignment by IANA 7. Security Considerations
and this document closes the IANA registry for DNS KEY Resource
Record Protocol Octet Values. Assignment of any future KEY Resource
Record Protocol Octet values requires a standards action. New
numbers for algorithm values will continue to be assigned by IANA.
IANA needs to open a new registry for the DS RR type digest This document describes the format of four DNS resource records used
algorithms. Defined types are: 0 is Reserved, 1 is SHA-1. Adding by the DNS security extensions and presents an algorithm for
new reservations requires IETF standards action. calculating a key tag for a public key. Other than the items
desribed below, the resource records themselves introduce no security
considerations. The use of these records is specified in a seperate
document and security considerations related to the use these
resource records are discussed in that document.
8. Security Considerations 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
identify an existing KEY RR, but it is theoretically possibile for an
attacker to generate a KEY that matches all the DS fields. The
probability of constructing such a matching KEY depends on the type
of digest algorithm in use and the only currently defined digest
algorithm is SHA1. It is considered very difficult to constuct a
public key that matches the algorithm, key tag, and SHA1 digest given
in a DS record.
This document describes the format of resource records used by DNS The key tag is used to help efficiently select KEY resource records,
security. The threats facing DNS are described in a separate but it does not uniquely identify a KEY resource record. It is
document and these records are used to help counter those threats. possible that two distinct KEY RRs could have the same owner name,
The records themselves introduce no new security considerations, but same algorithm type and same key tag. An implementation that used
the protocol use of these records is described in a second document. only the key tag to select a KEY RR may select the wrong public key
for a given scenario. Implementations MUST NOT assume the key tag is
unique public key identifier and this is clearly stated in the text.
9. Acknowledgements 8. Acknowledgements
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 re-writing of these the comments and suggestions received during the revision of these
security extension specifications. security extension specifications.
References 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.
skipping to change at page 23, line 44 skipping to change at page 24, line 44
[10] Eastlake, D., "DNS Request and Transaction Signatures ( [10] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000. SIG(0)s)", RFC 2931, September 2000.
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000. Update", RFC 3007, November 2000.
[12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name [12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001. System (DNS)", RFC 3110, May 2001.
[13] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC Intro", [13] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC Intro",
February 2002. October 2002.
[14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC [14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC
Protocol", February 2002. Protocol", October 2002.
[15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource [15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record", draft-ietf-dnsext-restrict-key-for-dnssec-01 (work in Record", draft-ietf-dnsext-restrict-key-for-dnssec-02 (work in
progress), January 2002. progress), March 2002.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Nominum, Inc. Bankastraat 41-E
2385 Bay Street 1094 EB Amsterdam
Redwood City, CA 94063 NL
USA
EMail: roy.arends@nominum.com EMail: roy@logmess.com
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
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-3460 Gaithersburg, MD 20899-8920
USA USA
EMail: scott.rose@nist.gov EMail: scott.rose@nist.gov
Appendix A. Key Tag Calculation Appendix A. DNSSEC Algorithm and Digest Types
The key tag field in the SIG RR is just a means of more efficiently The DNS security exstentions are designed to be independent of the
selecting the correct KEY RR to use when there is more than one KEY underlying cryptographic algorithms. The KEY, SIG, and DS resource
RR candidate available, for example, in verifying a signature. It is records all use a DNSSEC Algorithm Number to identify the
possible for more than one candidate key to have the same tag, in crytographic algorithm in use by the resource record. The DS
which case each must be tried until one works or all fail. The resource record also specifies a Digest Algorithm Number to identify
following reference implementation of how to calculate the Key Tag, the digest algorithm used to construct the DS record. The currently
for all algorithms other than algorithm 1 (which is NOT RECOMMENDED), defined Algorithm and Digest Types are listed below. Additional
is in ANSI C. The input is the key material in base 64,not the Algorithm or Digest Types could be added as advances in cryptography
entire RDATA of the KEY record that contains the public key. It is warrant.
coded for clarity, not efficiency.
A DNSSEC aware resolver or name server MUST implement all MANDATORY
algorithms.
A.1 DNSSEC Algorithm Types
An "Algorithm Number" field in the KEY, SIG, and DS resource record
types identifies the cryptographic algorithm used by the resource
record. Algorithm specific formats are described in separate
documents. The following table lists the currently defined algorithm
types and provides references to their supporting documents:
VALUE Algorithm RFC STATUS
0 Reserved - -
1 RSA/MD5 RFC 2537 NOT RECOMMENDED
2 Diffie-Hellman RFC 2539 OPTIONAL
3 DSA RFC 2536 OPTIONAL
4 elliptic curve TBA OPTIONAL
5 RSA/SHA1 RFC 3110 MANDATORY
6-251 available for assignment -
252 indirect see below OPTIONAL
253 private see below OPTIONAL
254 private see below OPTIONAL
255 reserved - -
A.1.1 Indiret and 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
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
name. Only local domain name compression is permitted. 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 KEY RR
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
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.
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 "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 RSA/SHA-1 MANDATORY
2-255 Unassigned -
Appendix B. Key Tag Calculation
The key tag field provides a mechanism for efficiently selecting a
public key. In most cases, a combination of owner name, algorithm,
and key tag can efficiently identify a KEY record. For example,
both the SIG and DS resource records have corresponding KEY records.
A Key Tag field in the SIG and DS records can be used to help
efficiently select the corresponding KEY RR when there is more than
one candidate KEY RR available.
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
have the same owner name, same algorithm, and same key tag. The key
tag is used to efficiently limit the possible candidate keys but it
does not uniquely identify a KEY record. Implementations MUST NOT
assume the key tag uniquely idenifies 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 /* assumes int is at least 16 bits
first byte of the key tag is the most significant byte of return first byte of the key tag is the most significant byte of return
value value
second byte of the key tag is the least significant byte of second byte of the key tag is the least significant byte of
return value return value
*/ */
int keytag ( int keytag (
skipping to change at page 26, line 5 skipping to change at page 29, line 5
) )
{ {
long int ac; /* assumed to be 32 bits or larger */ long int ac; /* assumed to be 32 bits or larger */
for ( ac = 0, i = 0; i &lt keysize; ++i ) for ( ac = 0, i = 0; i &lt keysize; ++i )
ac += (i&amp1) ? key[i] : key[i]&lt&lt8; ac += (i&amp1) ? key[i] : key[i]&lt&lt8;
ac += (ac>>16) &amp 0xFFFF; ac += (ac>>16) &amp 0xFFFF;
return ac &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
a.foo.example
yljkjljk.a.foo.example
Z.a.foo.example
zABC.a.FOO.EXAMPLE
z.foo.example
*.z.foo.example
\200.z.foo.example
C.2 Canonical RR Form
For purposes of DNS security, the canonical form for an RR is the
wire format of the RR with
(1) all domain names fully expanded
(no name compression via pointers)
(2) all domain name letters set to lower case
(3) any owner name wild cards in master file form
(no substitution made for *)
(4) the original TTL substituted for the current TTL.
C.3 Canonical RR Ordering Within An RRset
For purposes of DNS security, RRs with same owner name and same type
are sorted by treating the RDATA as a left justified unsigned octet
sequence. The absence of an octet sorts before the zero octet.
C.4 Canonical Ordering of RR Types
RRs with the same owner name but different types are sorted based on
the RR type number. The exception to this rule are SIG RRs, which
are placed immediately after the type they cover.
For example, an A record would be put before an MX record because
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 (2002). 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
 End of changes. 130 change blocks. 
488 lines changed or deleted 737 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/