wdiff draft-ietf-dnsext-dnssec-records-01.txt draft-ietf-dnsext-dnssec-records-02.txt

DNS Extensions
Network Working Group R. Arends
Internet-Draft Nominum
Expires: August 2, 2002 April 29, 2003 M. Larson
VeriSign
D. Massey
USC/ISI
S. Rose
NIST
February
October 29, 2002

Resource Records for the DNS Security Extensions
draft-ietf-dnsext-dnssec-records-01
draft-ietf-dnsext-dnssec-records-02

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 2, 2002. April 29, 2003.

Abstract

The DNS Security Extensions (DNSSEC) introduce four resource records:
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
collection of new resource records and protocol modifications that
provide source authentication for the DNS. This document defines the
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.

This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 DNSSEC Document Family Background and Related Documents . . . . . . . . . . . . . 4
1.2 Reserved Words . . . . . 4
2. The Key Resource Record . . . . . . . . . . . . . . . . . 5
2.1 KEY RDATA Wire Format 4
1.3 Editors Notes . . . . . . . . . . . . . . . . . . 5
2.1.1 The Flags Field . . . . 4
1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . 5
2.1.1.1 Explanation for Choice of Bit 7 . 4
1.3.2 Technical Changes or Corrections . . . . . . . . . . . . 6
2.1.2 . 4
1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . 5
2. The Protocol Octet Field KEY Resource Record . . . . . . . . . . . . . . . . . 6
2.1.2.1 Explanation for a Fixed Value Protocol Octet Field
2.1 KEY RDATA Wire Format . . . . . . . 6
2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 6
2.2
2.1.1 The KEY RR Presentation Format Flags Field . . . . . . . . . . . . . . . . . 7
2.3 KEY RR Examples . . . . 6
2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 7
2.3.1 Example 1
2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 7
2.1.4 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . 7
2.3.2 Example 2
2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7
2.3 KEY RR Example . . . . . . . . . . 8 . . . . . . . . . . . . 7
3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9
3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10
3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10
3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10
3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10
3.1.5 Signature Expiration and Inception Fields . . . . . . . . 10 11
3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 10 11
3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11
3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11
3.2 Calculating A Signature . . . . . . . . . . . . . . . . . 12
3.2.1 Calculating An RRset Signature . . . . . . . . . . . . . . 12
3.2.2 Calculating An Transaction Signature . . . . . . . . . . . 12
3.3 The NXT SIG RR Presentation Format (placeholder) . . . . . . . 11
3.3 Calculating the signature . . . . . . . 13
3.4 Example of a SIG RR . . . . . . . . . 11 . . . . . . . . . . 13
4. The NXT Resource Record . . . . . . . . . . . . . . . . . 13 15
4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 13 15
4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 13 15
4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 13 16
4.1.2.1 Alternate Formats for the Type Bit Map Field . . . . . . . 16
4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . 16
4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 14 16
4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . 17
5. The DS Resource Record . . . . . . . . . . . . . . . . . . 15 18
5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 18
5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 15 18
5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 15 19
5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 16 19
5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 16 19
5.2 The DS RR Presentation Format . . . . . . . . . . . . . . 19
5.3 DS Record Example . . . . . . . . . . . . . . . . . . . . 16
5.3 Resolver Example 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . 16
6. DNSSEC message bits . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . 18
6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 18
6.2 The DO Extended Flags Field Bit . 23
References . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . 25
A. DNSSEC Algorithm and Digest Types . . . . . . 21
9. Acknowledgements . . . . . . 26
A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . 22
References . . . 26
A.1.1 Indiret and Private Algorithm Types . . . . . . . . . . . 26
A.2 DNSSEC Digest Types . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . 27
B. Key Tag Calculation . . . . . . . . . . . 24
A. . . . . . . . . 28
B.1 Key Tag Calculation for Algorithm 1 - RSA/MD5 . . . . . . . . . . . . 29
C. Canonical Form and Order of Resource Records . . . . . . 30
C.1 Canonical DNS Name Order . 25 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 26 32

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 KEY, DS, SIG, NXT, and NXT DS resource records. This document defines
the purpose of each resource record, record (RR), the RR's RDATA format, the ASCII
representation, and an
its ASCII representation. An example of each RR type is also given. Sections 2-
5 describe the KEY, DS, SIG, and NXT records. Section 6 describe the
DNSSEC header bits.

1.1 DNSSEC Document Family Background and Related Documents

This document is part of a family of documents that define the DNS
security extensions. The DNS security extensions (DNSSEC) are a
collection of resource records and DNS protocol modifications that
add source authentication the Domain Name System (DNS). An
introduction to DNSSEC and definition of common terms can be found in
(RFC TBA).
[13]. A description of DNS protocol modifications can be found in (RFC TBA).
[14]. 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

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].

1.3 Editors Notes

1.3.1 Open Technical Issues

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 KEY Resource Record

Public keys used by the

DNSSEC uses public key cryptogrpahy to sign and authenticate DNS infrastructure
resource record sets (RRsets). The public keys are stored in KEY
resource
records. A secure DNS records and are used in the DNSSEC authentication process
described in [14]. In a typical example, a zone will store signs its
authorititave RRsets using a private key and stores the corresponding
public key in a KEY RR and
this KEY RR RR. A resolver can be used then use these signatures to
authenticate other RR sets in RRsets from the zone.

The KEY RR MAY is also be used to store public keys associated with other types of
DNS public keys, operations, such as the keys used by SIG(0) [10] or [14] and 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, In all other uses are obsolete. The cases, the
KEY RR plays an essential a special role in
the secure processing of DNS messages resolution and DNS message
processing. The KEY RR is included in various
responses. 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 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

The RDATA for a KEY RR consists of a 2 octet Flags Fields, a Protocol
Octet, a one octet Algorithm number, Number, and the public key. Public Key.

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags Flags | protocol Protocol | algorithm Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key Public Key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

2.1.1 The Flags Field

Bit 7 of the Flags Field field is the "zone key flag". Bits 0-6 and 8-15
are reserved for future use. Bits 0-6 and 8-15 MUST be set to 0 and
MUST be ignored during processing.

The zone key flag (bit 7) determines whether the KEY holds a DNS zone
key. Zone Key flag. If bit 7 is 1, then
the KEY record holds a DNS zone key. key and the KEY's owner name MUST be
the name of a zone. If bit 7 is 0, then the KEY record holds some
other type of DNSSEC
infrastructure DNS 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

Bits 0-6 and 8-15 are reserved for Choice of Bit 7

The choice of bit 7 as the zone key flag was made in order to provide
backwards compatibility with an earlier version of the KEY record.
This earlier version was defined in [6] future use and [15] eliminated all flags
except the bit 7 zone key flag. MUST be zero.

2.1.2 The Protocol Octet Field

The Protocol Octet value 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

The Algorithm Field field identifies the public key's cryptographic
algorithm and determines the format of the Public Key Field.

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. field. 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 list
of DNSSEC algorithm types can 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
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
never be assigned a specific algorithm. For number 253, the public
key area and the signature begin with a wire encoded domain name
indicating the algorithm Appendix A.1

2.1.4 Notes on KEY RDATA Design

Although the key uses. Only local domain name
compression Protocol Octet field is permitted. The remainder of the public key area always 3, it is
privately defined. For number 254, the public key area retained for the KEY
RR and the signature begin
backwards compatibility with an unsigned length byte followed by a
BER encoded Object Identifier (ISO OID) earlier version of that length. The OID
indicates the private algorithm in KEY record.
The use and the remainder of bit 7 as the area
is whatever Zone Key Flag is required by that algorithm. Entities should only use
domain names and OIDs they control also due to designate their private
algorithms. backwards
compatiblity issues.

2.2 The KEY RR Presentation Format

A KEY RR may appear as a single line. 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 Flag field is represented as an unsigned integer.

The Protocol Octet field is represented as the unsigned integer 3.

The Algorithm Field field is represented as an unsigned integer or as an
algorithm mnemonic specified. The mnemonic is listed specified in the document defining
the algorithm. Appendix A.1.

The Public Key Field field is a Base 64 encoding of the Public Key Field.

2.3 KEY RR Examples

2.3.1 Example 1

The following KEY RR stores a DNS zone key for isi.edu.

isi.edu. 86400 IN KEY 256 3 5 ( AQPT0sh3WjVeRY3WqpBjtf
<snip of base64 encoded text>
xxDw==)

The first four fields specify the owner name, TTL, Class, and RR type
(KEY). 256 indicates the flags Flags field has the zone key bit is set. 3
is the fixed Protocol Octet value. 5 indicates the public key
algorithm. Appendix A.1 identifies algorithm is type 5 as RSA/SHA1 RFC 3110]. The remaining text is base 64 encoding of the
public key and
indicates that the format of the RSA/SHA1 public key field is defined
in [12].

Resolvers might use this public key to authenticate signed RR sets
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 a base 64 encoding of the public key and the format of the public key is defined in [7].

This key.

3. The SIG Resource Record

DNSSEC uses public key can be used cryptogrpahy to sign dynamic and authenticate DNS updates for the
isi.edu zone.
resource record sets (RRsets). The process is for signing the dynamic DNS updates is
described signatures are stored in [11].

3. The SIG Resource Record

The SIG or "signature"
resource record (RR) is the fundamental way
that data is authenticated records and are used in the secure Domain Name System (DNS).
As such it is DNSSEC authentication process
described in [14]. In a typical example, a zone signs its
authorititave RRsets using a private key and stores the heart of corresponding
signatures in SIG RRs. A resolver can then use these signatures to
authenticate RRsets from the security provided.

The zone.

A SIG RR authenticates record contains the signature for an RRset [5] of with a particular type,
name, class, and name and binds it type. The SIG RR is said to "cover" this RRset.
The SIG RR also specifies a time validity interval and for the signature and
uses an algorithm signer's name. The
signer is name, and key tag to identify the public
key (and associated KEY (KEY record) from which the RR
originated. A SIG record that can also be used for to verify the signature.

The signature in SIG RR may also cover a transaction security
[transaction ref/section]. This type of rather than an
RRset [14]. In this case, the "Type Covered" field is set to 0 and
the SIG RR is known refered to as SIG(0) and
its RDATA is in the same format, with some values loosing their
meaning and given default values. The variations are mentioned in
[10]. resource record.

The type number for the SIG RR type is 24.

The SIG RR is class independent, but MUST have the same class as the
RRset it covers.

The TTL for the SIG RR TTL SHOULD be match the same as TTL of the RRset it covers.

3.1 The SIG RDATA

The RDATA portion of a SIG RR is as shown below:

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type covered | algorithm | labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name +
| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/ /
/ signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.1 The Type Covered Field

For RRset SIGs,

The Type Covered field identifies the RRset type covered MUST be the same as by the type of data
in SIG
record.

If Type Covered field is set to 0, the associated record is referred to as a
SIG(0) RR and its signature covers a transaction rather than a
specific RRset. For SIG(0), this field MUST be zero [10] [14] descirbes how to sign transactions using SIG(0)
resource records.

3.1.2 The Algorithm Number Field

The Algorithm Number field in identies the RDATA is cryptographic algorithm used
to create the same field as signature. A list of DNSSEC algorithm types can be
found in
the algorithm field of the KEY record RDATA [section 2.2.3]. Appendix A.1

3.1.3 The Labels Field

The "labels" octet is an unsigned count Labels field specifies the number of how many labels there are in the original SIG
RR owner name. This It is included to handle signatures associated with
wildcard owner names.

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 "*" for in a wildcard. wildcard name. The labels count 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

The "original TTL" Original TTL field is included in specifies the RDATA portion to avoid
authentication problems caused by original TTL of the covered
RRset.

To validate the signature, a resolver requires the original TTL used
when the signature was created. However, caching servers decrementing will
decrement the
real TTL field. The signatures covers this field (as part of the SIG
RDATA) while and [14] describes how the Original TTL field count
is not. In a SIG(0), used to reconstruct the Original TTL original (undecremented) TTL.

If the Type Covered field (and is non-zero, the Original TTL field) MUST be 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

The Signature Inception and Signature Expiration fields specify a
validity period for the signature. The SIG is valid from record MUST NOT be used
for authentication prior to the "signature inception" time until inception date and MUST NOT be used
for authentication after the
"signature expiration" time. Both expiratiation date.

Inception and expiration dates are given as 32-bit unsigned numbers
of seconds since the start of 1 January 1970, 1970 GMT, ignoring leap
seconds. Ring arithmetic is used as for DNS SOA serial numbers [3], which means
that [3] to handle 32-bit wrap around. As
result, these times can never be more than about 68 years in the past or
the future. This means that these future and the times are ambiguous modulo ~136.09 ~136 years. A SIG RR may
can have an expiration time numerically less smaller than the inception
time if the expiration time is near the 32-bit wrap around point and/or and/
or the signature is long lived.

3.1.6 The Key Tag Field

The "Key Tag" is a two-octet quantity that is used to efficiently
select between multiple keys that may be applicable. The Key Tag
value may differ depending on field contains the key algorithm in use, as described tag of the public key (KEY RR)
used to authenticate this signature. The process of calculating a
key tag is given in Appendix (A). B.

3.1.7 The Signer's Name Field

The signer's Signer's Name field identifies the name of the KEY RR used to
authenticate this signature. If the Type Covered field is non-zero,
the Signer's Name MUST contain the name of the zone to which containing the data
covered RRset and signature belong. the SIG. The combination of signer's name, key
tag, and algorithm MUST identify a zone key if name MAY be compressed with
standard DNS name compression when being transmitted over the SIG
network.

If the Type Covered field is to be
considered material. In 0 (i.e. a SIG(0), SIG(0) RR), the signer's name
MUST be the
originating host name of the host originating the DNS message as described
in [10].

3.1.8 The Signature Field

The actual Signature field contains the cryptographic signature. If the
Type Covered field is non-zero, the signature portion of covers the SIG RR binds the other RDATA
fields to
(excluding the Signature field) and the RRset of specified by the "type covered" RRs with that SIG
owner name name, SIG class, and class. SIG Type Covered field.

3.2 The NXT RR Presentation Format (placeholder)

This section will be here in the next revision.

3.3 Calculating the signature

To generate the A Signature

A signature over covers either an RRset, RRset or a data sequence is
constructed 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 follows (where "|" ANY or
AXFR.

3.2.1 Calculating An RRset Signature

A signature covers the SIG RDATA (excluding the Signature Field
itself) and covers the RRset specified by the SIG owner name, SIG
class, and SIG Type Covered field. The RRset is concatenation): in cannonical form
(see Appendix C) and the set RR(1),...RR(n) is signed as follows:

signature = sign(RDATA sign(SIG_RDATA | RR(1) | RR(2)... )

RR(N) where

"|" denotes append

SIG_RDATA is the wire format of the SIG RDATA fields with
the Signer's Name field in cannonical form.
the Signature field excluded.

fqdn is the Fully Qualified Domain Name in canonical
form.

All RR(i) MUST have the same fqdn as the SIG RDATA) | RR.

All RR(i) MUST have the same class as the SIG RR.

All RR(i) MUST have the RR type listed in SIG RR's
Type Covered field.

All RR(i) MUST have the TTL listed in the SIG Original
TTL Field

All names in the RDATA

To generate a signature over a DNS message (SIG(0)), field are in canonical form

The set of all RR(i) is sorted into cannonical order.

3.2.2 Calculating An Transaction Signature
3.3 The SIG RR Presentation Format

A SIG RR may appear as a data sequence single logical line. The presentation
format of the RDATA portion is constructed as follows:

If the DNS message

The Type Covered field is sent via UDP:

signature = sign(RDATA | full query | full response - SIG(0))

If represented by either an unsigned integer
or the DNS message is sent via TCP, mnemonic for the first packet's SIG(0) RR type.

The Algorithm field is
calculated represented as above, with each additional packet (if any) calculated an unsigned integer or as follows:

signature = sign(RDATA | DNS payload - SIG(0) | previous packet)

where "previous packet" an
algorithm mnemonic specified in Appendix A.1.

The Labels field is represented as an unsigned integer.

The Original TTL field is represented as an unsigned integer. It MAY
be omitted if it is equal the previous DNS packet with accompanying
SIG(0), but without any other headers (i.e. TCP/IP, etc.).

In all TTL of the examples,

RDATA SIG RR.

The Signature Inception Time and Expiration Time fields are
represented in the form YYYYMMDDHHmmSS, where:

YYYY is the wire format year

MM is the month number (01-12)

DD is the day of all the RDATA fields 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 itself
(including

The following a SIG RR stores the canonical form of signature for the signer's name) before but not
including the signature, 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(num) RR type
(SIG). The "A" represents the Type Covered field. is the RRset with algorithm
used to create this signature. The first 3 identifies the same Algorithm
used to create the signature. The second 3 is the number of Labels
in the original owner name and class and type
covered as the 30 is the Original TTL for this
SIG RR in canonical form.

Name is and the Fully Qualified Domain Name (FQDN) in canonical form. covered A RRset. The canonical form for a Resource Record (RR) two dates are the expiration and
inception dates. 65531 is the wire format of Key Tag and example.com. is the RR. Names MUST be expanded (no name compression allowed). Name
characters MUST be set to lower case. Wildcards MUST be unexpanded.
Signer's Name. The RR MUST have remaining text is a base 64 encoding of the original TTL.

How
signature.

Note that combination of SIG RR owner name, class, and and Type
Covered indicate this data sequence is processed into 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 is algorithm
dependent. These can be
authenticated using an example.com zone KEY RR whose algorithm dependent formats is 3
and procedures are
described in separate documents.

SIGs SHOULD NOT be generated for any "meta-type" such as ANY, AXFR,
etc. key tag is 65531.

4. The NXT Resource Record

The collection of NXT or "next" resource records (RR) is used to
indicate what names and RRsets [5] exist in a zone.

The NXT RR record lists the next canonical name in the zone and lists what RR types are present for at the current NXT's owner
name of and lists the NXT RR. next canonical name in the zone. The set collection
of NXT RRs or "next" resource records indicate what RRsets exist in a
zone is and provide a chain of all authoritative owner names in that
zone.

Glue 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 covered by a used when
contructing the NXT RR. resource record chain.

The type number for the NXT RR is 30.

The NXT RR is class independent.

The NXT RR TTL SHOULD NOT exceed the zone minimum TTL. TTL in the zone's SOA
RR.

4.1 NXT RDATA Wire Format

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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ next domain name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ type bit map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1 The Next Domain Name Field

The "next domain name" Next Domain Name field contains the next authoritive owner name
in canonical order. Canonical order, where canonical order means sorted by label, highest
level label first. The "next domain name" field of the NXT RR at is defined in Appendix C.1.
For the last owner name in the zone zone, the Next Domain Name field
contains the zone apex name.

Glue

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 covered by listed in
the "next domain
name" field.

The "next domain name" field allows message compression. 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

The "type bit map" Type Bit Map field format contains a single bit per RR type for
RRsets with identifies the same RRset types that exist at the
NXT's owner name as name.

Each bit in the NXT RR. A Type Bit Map field corresponds to an RR type. Bit
one corresponds to RR type 1 (A), bit 2 corresponds to RR type 2
(NS), and so forth. If a bit is set to 1, it indicates that an RRset
of that type exist exists for the NXT's owner name. A zero If a bit is set to
zero, it indicates that no RRset of that type exist exists for the NXT's
owner name.

The first bit represents RR type zero.

Trailing zero octets MUST be omitted. Thus the length of the Type
Bit Map field varies and is dependent on the largest RR type number present
for the NXT's owner name. Trailing zero is octets not
assigned and the corresponding bit specified MUST be zero. If the
interpreted as zero bit is
one, it indicates that an unspecified format is used. This format is
not octets.

Non-authoritative glue address record types MUST NOT be used when there exist an RR
constructing the type number greater than 127. bit map field. The OPT RR [8] type (41) also
MUST NOT be covered by used when constructing the type bit map field since it is
not part of the zone data. The corresponding In other words, the OPT RR type bit (40) (bit
41) MUST be zero.

Trailing zero octets MUST be omitted. Trailing zero octets not
specified MUST be interpreted as zero octets. Glue address record
types

4.1.2.1 Alternate Formats for the Type Bit Map Field

The above Type Bit Map format MUST NOT be covered by the 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 map 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

A NXT RR may appear as a single line. The presentation format of the
RDATA portion is as follows:

The "next domain name" Next Domain Name field is represented as a domain name.

The "type bit map" Type Bit Map field is represented as a sequence of RR type
mnemonics or as an a sequence of unsigned integer. 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

The DS record Resource Record points to a KEY RR and is used in the DNS KEY
authentication process. A DS RR points to a major change KEY RR by storing the
key tag, algorithm number, and a digest of KEY RR. Note that while
the digest should be sufficient to DNS: it 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 can appear appears only on the upper side of a delegation. Other
keys MAY sign
In other words, the child's apex KEY RRset. DS records MUST point to
zone RR for "example.com" is stored in "com" (the
upper side of the delegation). The corresponding KEY records 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 allowed to authenticate DNS data. described in [14].

The type number for the DS record is 43.

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

This record contains these fields: key tag, algorithm, digest type,
and the digest

The RDATA for a DS RR consists of 2 octet Key Tag, a public key KEY record that is allowed and/or used
to sign the child's apex KEY RRset. one octet
Algorithm Number, a one octet Digest Type, and a Digest.

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | algorithm | Digest type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (20 bytes for SHA-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | /
/ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.1 The Key Tag Field

The key tag value is Key Tag field lists the same key tag value in the SIG RRs generated
using of the KEY record this RR pointed to by the
DS record points too. Having record. The KEY RR MUST be a a zone key. In other words, the KEY
RR Flags must have Flags bit 7 set to 1.

The key tag
in the RDATA provides additional reliability in matching than just used by the KEY digest alone. See DS RR is identical to the key tag for details. used by the
SIG RR and Appendix B describes how to compute a key tag.

5.1.2 The Algorithm Field

The algorithm value has Algorithm field lists the same defined values as algorithm number of the KEY and SIG
records. RR pointed
to by the DS record.

The value MUST be an algorithm number assigned in used by the DS RR is identical to the algorithm
number used by the range
1..251 SIG RR and KEY RR. Appendix A.1 lists the
algorithm MUST be allowed to sign DNS data. number types.

5.1.3 The Digest Type Field

The DS RR points to a KEY RR by including a digest type is an identifier for of that KEY RR.
The Digest Type field identifes the digest algorithm used. The
following numbers have been assigned used to construct the
digest and Appendix A.2 lists the assignment of future
numbers requires IETF standards action.

VALUE Algorithm STATUS
0 Reserved -
1 RSA/SHA-1 MANDATORY
2-255 Unassigned - possible digest algorithm types.

5.1.4 The Digest Field

The DS record points to a KEY RR by including a digest is calculated over the canonical name of that KEY
RR. The Digest field hold the delegated
domain name followed by digest.

For a given KEY RR, the whole RDATA of digest is calculated by appending the KEY record (all four
fields). The size of
RR's cannonical fully qualified owner name with the DS KEY RDATA for type 1 (SHA-1) is 24 bytes,
regardless of key size. Other digest algorithms may have a differing and
then applying the digest size, to be described in other documents. algorithm.

digest = hash( digest_algorithm( cannonical FQDN on of KEY RR | KEY_RR_rdata)

"|" denotes append

KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key

The size of the digest can vary depending on the digest algorithm and
KEY RR size. However, the only currently defined digest algorithm is
SHA-1 and it always produces a 24 byte digest regardless of KEY RR
size.

5.2 The DS Record Example 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 DS record consists of three numbers
(key tag, RDATA portion is as follows:

The Key Tag field is represented as an unsigned integer.

The Algorithm field is represented as an unsigned integer or as an
algorithm and digest type) followed by the digest itself mnemonic specified in Appendix A.1.

The Digest Type field is represented as an unsigned integer.

The Digest is presented in hex:

example. hexadecimal.

5.3 DS 12345 3 1 123456789abcdef67890123456789abcdef67890

This is a Record Example

The following example of shows a KEY record RR and its corresponding DS record. RR.

dskey.example. 86400 IN KEY 256 3 1 (
encoded public key
) AQPwHb4UL1U9RHaU8qP+Ts5bVOU
1s7fYbj2b3CCbzNdj4+/ECd18yKiy
UQqKqQFWW5T3iVc8SJOKnueJHt/Jb
/wt) ; key id tag = 28668
dskey.example. 3600 IN DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE

5.3 Resolver Example

To create a chain of trust, a resolver goes from trusted KEY to DS to
KEY.

Assume

The first four fields specify the key for domain "example." name, TTL, Class, and RR type (DS).
28668 is trusted. Zone "example."
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:
secure.example. SOA (soa stuff)
secure.example. NS ns1.secure.example.
secure.example. KEY (tag=12345 alg=3)
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 tag for "example." signs the DS record
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 corresponding "dskey.example." KEY RRset is validated RR
and trusted.

This example has only one DS record for the child, but parents MUST
allow multiple DS records to facilitate key rollover. It is strongly
recommended that the DS RRset be kept small: two or three DS records
should be sufficient in all cases.

The resolver determines the security status of "unsecure.example." 1 algorithm used by
examining the parent zone's NXT record for this name. The absence of
the DS bit indicates an unsecure delegation.

6. DNSSEC message bits

There are 3 new bits allocated for use with DNSSEC. "dskey.example." KEY RR. The DO bit second 1
is
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 algorithm used to
indicate if non-authenticated data is accepted, and if data is
authenticated.

6.1 The AD and CD Header Bits

Two bits are allocated in construct the header section. The CD (checking
disabled) bit and the AD (authentic data) bit.

The Header contains the following fields:

1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The usage of the CD digest and AD bits are defined in [14]

6.2 The DO Extended Flags Field Bit

The DO (DNSSEC OK) bit is allocated from the EDNS0 [8] extended flags
field. In the context of the OPT RR, the DO bit final string is
the most
significant bit in the 3rd octet of the TTL field.

The TTL field of the OPT RR is defined as follows:

1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|DO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The usage of the DO bit is defined digest in [14]

7. hex.

6. IANA Considerations

This document clarifies the use of existing types and introduces no new IANA considerations.

The definitions of

This document only clarifies the flag bits in use of existing DNS resource
records. However for completeness, the KEY RR IANA considerations from
these previous documents are set summarized below. No IANA changes are
made by working
group consensus and there is no this document.

RFC 2535 updated the IANA registry for their definition.
Changes DNS Resource Record Types and
assigned types 24,25, and 30 to the meaning of the bits in the flags section of the KEY
RDATA must be done through working group consensus. 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
algorithm Octet values.
Algorithm Numbers. Values to 1-5, 1-4, and 255 252-255 were assigned and
values 6-254 were made available for assignment by IANA. This
document re-assigns DNS KEY Resource Record Protocol Octet values 1,
2, 4, RFC
2535. Value 5 was assigned by RFC 3110.

[DS RFC] created an IANA registry for DNSSEC DS Digest Types and 255
assigned value 0 to ``reserved''. DNS Key Resource Record reserved and value 1 to RSA/SHA-1.

RFC 2535 created an IANA Registry to KEY Protocol Octet Value 3 remains unchanged as ``DNSSEC''.

New protocol Values, but
[KeyRestrict RFC] set all assigned values are no longer available for assignment by IANA other than 3 to reserved
and closed this document closes the IANA registry. The registry for DNS remains closed and all
KEY Resource
Record records are required to have Protocol Octet Values. Assignment value of any future 3.

The Flag bits in the KEY Resource
Record Protocol Octet values requires a standards action. New
numbers for algorithm values will continue to be RR are not assigned by IANA. IANA needs to open a new and there is no
IANA registry for these flags. All changes to the DS meaning of the KEY
RR type digest
algorithms. Defined types are: 0 is Reserved, 1 is SHA-1. Adding
new reservations requires IETF Flag bits require a standards action.

7. Security Considerations

This document describes the format of four DNS resource records used
by the DNS
security. security extensions and presents an algorithm for
calculating a key tag for a public key. Other than the items
desribed below, the resource records themselves introduce no security
considerations. The threats facing DNS are described use of these records is specified in a separate seperate
document and security considerations related to the use these
resource records are used discussed in that document.

The DS record points to help counter those threats. a KEY RR using a cryptographic digest, the
key algorithm type and a key tag. The records themselves introduce no new security considerations, 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 protocol use DS fields. The
probability of these records constructing such a matching KEY depends on the type
of digest algorithm in use and the only currently defined digest
algorithm is described SHA1. It is considered very difficult to constuct a
public key that matches the algorithm, key tag, and SHA1 digest given
in a second document.

9. DS record.

The key tag is used to help efficiently select KEY resource records,
but it does not uniquely identify a KEY resource record. It is
possible that two distinct KEY RRs could have the same owner name,
same algorithm type and same key tag. An implementation that used
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.

8. Acknowledgements

This document was created from the input and ideas of several members
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 comments and suggestions received during the re-writing revision of these
security extension specifications.

References

[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.

[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.

[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[5] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.

[6] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.

[7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.

[8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.

[9] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.

[10] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.

[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.

[12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001.

[13] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC Intro",
February
October 2002.

[14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC
Protocol", February October 2002.

[15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record", draft-ietf-dnsext-restrict-key-for-dnssec-01 draft-ietf-dnsext-restrict-key-for-dnssec-02 (work in
progress), January March 2002.

Authors' Addresses

Roy Arends
Nominum, Inc.
2385 Bay Street
Redwood City, CA 94063
USA
Bankastraat 41-E
1094 EB Amsterdam
NL

EMail: roy.arends@nominum.com roy@logmess.com

Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA

EMail: mlarson@verisign.com

Dan Massey
USC Information Sciences Institute
3811 N. Fairfax Drive
Arlington, VA 22203
USA

EMail: masseyd@isi.edu

Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-3460 20899-8920
USA

EMail: scott.rose@nist.gov

Appendix A. Key Tag Calculation DNSSEC Algorithm and Digest Types

The key tag DNS security exstentions are designed to be independent of the
underlying cryptographic algorithms. The KEY, SIG, and DS resource
records all use a DNSSEC Algorithm Number to identify the
crytographic algorithm in use by the resource record. The DS
resource record also specifies a Digest Algorithm Number to identify
the digest algorithm used to construct the DS record. The currently
defined Algorithm and Digest Types are listed below. Additional
Algorithm or Digest Types could be added as advances in cryptography
warrant.

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 just 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 means BER encoded Object Identifier (ISO OID) of more 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 correct SIG and DS resource records have corresponding KEY RR records.
A Key Tag field in the SIG and DS records can be used to use help
efficiently select the corresponding KEY RR when there is more than
one candidate KEY RR candidate available, for example, in verifying available.

However, it is essential to note that the key tag is not a signature. unique
identifier. It is theoretically possible for more than one candidate key two distinct KEY RRs to
have the same tag, in
which case each must be tried until one works or all fail. 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 of how to calculate the Key Tag, is provided for
calculating a Key Tag. This reference implementation applies to all algorithms other than
algorithm types except algorithm 1 (which is NOT RECOMMENDED),
is in ANSI C. (see Appendix B.1). The input is
the public key material in base 64,not 64, not the entire RDATA of the KEY
record that contains the public key. It The code is
coded 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
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

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.