-
DNSEXT Working Group Olafur Gudmundsson
INTERNET-DRAFT October 2002
- <draft-ietf-dnsext-delegation-signer-10.txt>
+ <draft-ietf-dnsext-delegation-signer-11.txt>
Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
- This draft expires on April 16, 2003.
+ This draft expires on April 30, 2003.
Copyright Notice
Gudmundsson Expires April 2003 [Page 1]
-
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
in the child requires frequent two-way communication between the two
parties. First the child transmits the KEY RRset to the parent and
then the parent sends the signature(s) to the child. Storing the KEY
- RRset at the parent simplifies the communication.
+ RRset at the parent was thought to simplify the communication.
DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
an unsecure child zone to indicate that the child is unsecure. A NULL
Gudmundsson Expires April 2003 [Page 2]
-
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
5. The parent may not meet the child's expectations in turnaround
time for resigning the KEY RRset.
- Given these and other reasons, there is good reason to explore
- alternatives to using only KEY records to create a chain of trust.
-
- Some of these problems can be reduced or eliminated by operational
- rules or protocol changes. To reduce the number of keys at the zone
- apex, a rule to require applications to store their KEY records at
- the SRV name for that application is one possibility. Another is to
- restrict the KEY record to only DNSSEC keys and create a new record
- type for all non-DNSSEC keys. A third possible solution is to
- prohibit the storage of non-DNSSEC keys at the zone apex. There are
- other possible solutions, but they are outside the scope of this
- document.
+ Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
1.2 Reserved Words
The chain of trust is now established by verifying the parent KEY
RRset, the DS RRset from the parent and the KEY RRset at the child.
-
-
-
-Gudmundsson Expires April 2003 [Page 3]
-
-INTERNET-DRAFT Delegation Signer Record October 2002
-
-
This is cryptographically equivalent to using just KEY records.
Communication between the parent and child is greatly reduced, since
applications and protocols with minimal impact on the parent. Thus if
the child wants to have frequent key rollover for its DNS zone keys,
the parent does not need to be aware of it: the child can use one key
+
+
+
+Gudmundsson Expires April 2003 [Page 3]
+\f
+INTERNET-DRAFT Delegation Signer Record October 2002
+
+
to sign only its apex KEY RRset and other keys to sign the other
RRsets in the zone.
one required by RFC 2535. There is no impact on the number of
signatures verified for other types of RRsets.
+ Even though DS identifies two roles for KEY's, Key Signing Key (KSK)
+ and Zone Sigining Key (ZSK), there is no requirement that zone use
+ two different keys for these roles. It is expected that many small
+ zones will only use one key, while larger organizations will be more
+ likely to use multiple keys.
+
2.2 Protocol Change
All DNS servers and resolvers that support DS MUST support the OK bit
This increases the size of referral messages and may cause some or
all glue to be omitted. If the DS or NXT RRsets with signatures do
+ not fit in the DNS message, the TC bit MUST be set. Additional
+ section processing is not changed.
+ A DS RRset accompanying a NS RRset indicates that the child zone is
+ secure. If a NS RRset exists without a DS RRset, the child zone is
-Gudmundsson Expires April 2003 [Page 4]
+Gudmundsson Expires April 2003 [Page 4]
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
- not fit in the DNS message, the TC bit MUST be set. Additional
- section processing is not changed.
-
- A DS RRset accompanying an NS RRset indicates that the child zone is
- secure. If an NS RRset exists without a DS RRset, the child zone is
unsecure (from the parents point of view). DS RRsets MUST NOT appear
at non-delegation points or at a zone's apex.
Section 2.2.1 defines special considerations related to authoritative
- servers responding to DS queries. Section 2.2.2 replaces RFC2535
- sections 2.3.4 and 3.4, section 2.2.3 replaces RFC3008 section 2.7,
- and section 2.2.4 updates RFC3090.
+ servers responding to DS queries and replaces RFC2535 sections 2.3.4
+ and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section
+ 2.2.3 updates RFC3090.
-2.2.2 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
+2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
DNS security views each zone as a unit of data completely under the
control of the zone owner with each entry (RRset) signed by a special
in the answer section.
+2.2.1.1 Special processing for DS queries
+ When a server is authoritative for the parent zone at a delegation
+ point and receives a query for the DS record at that name, it will
+ return the DS from the parent zone. This is true whether or not it
+ is also authoritative for the child zone.
Gudmundsson Expires April 2003 [Page 5]
-
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
-2.2.2.1 Special processing for DS queries
-
- When a server is authoritative for the parent zone at a delegation
- point and receives a query for the DS record at that name, it will
- return the DS from the parent zone. This is true whether or not it
- is also authoritative for the child zone.
-
When the server is authoritative for the child zone at a delegation
point but not the parent zone, there is no natural response, since
the child zone is not authoritative for the DS record at the zone's
MUST not be set in the response.
-2.2.3 Signer's Name (replaces RFC3008 section 2.7)
+2.2.2 Signer's Name (replaces RFC3008 section 2.7)
The signer's name field of a SIG RR MUST contain the name of the zone
to which the data and signature belong. The combination of signer's
identify a key if this SIG(0) is to be processed.
-2.2.4 Changes to RFC3090
+2.2.3 Changes to RFC3090
A number of sections of RFC3090 need to be updated to reflect the DS
record.
-
-
-
-
-Gudmundsson Expires April 2003 [Page 6]
-
-INTERNET-DRAFT Delegation Signer Record October 2002
-
-
-2.2.4.1 RFC3090: Updates to section 1: Introduction
+2.2.3.1 RFC3090: Updates to section 1: Introduction
Most of the text is still relevant but the words ``NULL key'' are to
be replaced with ``missing DS RRset''. In section 1.3 the last three
obsolete.
-2.2.4.2 RFC3090 section 2.1: Globally Secured
+
+
+Gudmundsson Expires April 2003 [Page 6]
+\f
+INTERNET-DRAFT Delegation Signer Record October 2002
+
+
+2.2.3.2 RFC3090 section 2.1: Globally Secured
Rule 2.1.b is replaced by the following rule:
to this is the root zone, for which there is no parent zone.
-2.2.4.3 RFC3090 section 3: Experimental Status.
+2.2.3.3 RFC3090 section 3: Experimental Status.
The only difference between experimental status and globally secured
is the missing DS RRset in the parent zone. All locally secured zones
-Gudmundsson Expires April 2003 [Page 7]
+
+
+
+
+
+
+
+
+Gudmundsson Expires April 2003 [Page 7]
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
digest type, and the digest of a public key KEY record that is
allowed and/or used to sign the child's apex KEY RRset. Other keys
MAY 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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | SHA-1 digest |
+ | digest (length depends on type) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | (20 bytes) |
+ | (SHA-1 digest is 20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-Gudmundsson Expires April 2003 [Page 8]
+Gudmundsson Expires April 2003 [Page 8]
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
Gudmundsson Expires April 2003 [Page 9]
-
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
Gudmundsson Expires April 2003 [Page 10]
-
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
Gudmundsson Expires April 2003 [Page 11]
-
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
Gudmundsson Expires April 2003 [Page 12]
-
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
Gudmundsson Expires April 2003 [Page 13]
-
+\f
INTERNET-DRAFT Delegation Signer Record October 2002
Author Address
Olafur Gudmundsson
- 3826 Legation Street, NW
+ PO Box 6306
Washington, DC, 20015
USA
<ogud@ogud.com>
Gudmundsson Expires April 2003 [Page 14]
-
+++ /dev/null
-
-
-DNS Extensions R. Arends
-Internet-Draft Nominum
-Expires: August 2, 2002 M. Larson
- VeriSign
- D. Massey
- USC/ISI
- S. Rose
- NIST
- February 2002
-
-
- Resource Records for DNS Security Extensions
- draft-ietf-dnsext-dnssec-records-01
-
-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.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-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
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 1]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
- provide source authentication for the DNS. 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 . . . . . . . . . . . . . . . . . . 4
- 2. The Key Resource Record . . . . . . . . . . . . . . . . . 5
- 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 5
- 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5
- 2.1.1.1 Explanation for Choice of Bit 7 . . . . . . . . . . . . . 6
- 2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 6
- 2.1.2.1 Explanation for a Fixed Value Protocol Octet Field . . . . 6
- 2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 6
- 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7
- 2.3 KEY RR Examples . . . . . . . . . . . . . . . . . . . . . 7
- 2.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7
- 2.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 8
- 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
- 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 10
- 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11
- 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11
- 3.2 The NXT RR Presentation Format (placeholder) . . . . . . . 11
- 3.3 Calculating the signature . . . . . . . . . . . . . . . . 11
- 4. The NXT Resource Record . . . . . . . . . . . . . . . . . 13
- 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 13
- 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 13
- 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 13
- 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 14
- 5. The DS Resource Record . . . . . . . . . . . . . . . . . . 15
- 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15
- 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 15
- 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 15
- 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 16
- 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 16
- 5.2 DS Record Example . . . . . . . . . . . . . . . . . . . . 16
- 5.3 Resolver Example . . . . . . . . . . . . . . . . . . . . . 16
- 6. DNSSEC message bits . . . . . . . . . . . . . . . . . . . 18
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 2]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
- 6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 18
- 6.2 The DO Extended Flags Field Bit . . . . . . . . . . . . . 18
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 20
- 8. Security Considerations . . . . . . . . . . . . . . . . . 21
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 22
- References . . . . . . . . . . . . . . . . . . . . . . . . 23
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . 24
- A. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 25
- Full Copyright Statement . . . . . . . . . . . . . . . . . 26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 3]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-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:
- KEY, DS, SIG, and NXT resource records. This document defines the
- purpose of each resource record, the RDATA format, the ASCII
- representation, and an example of each RR type is given. Sections 2-
- 5 describe the KEY, DS, SIG, and NXT records. Section 6 describe the
- DNSSEC header bits.
-
-1.1 DNSSEC Document Family
-
- 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). A description of DNS protocol modifications can be found
- in (RFC TBA). This document defines the DNSSEC resource records.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 4]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-2. The Key Resource Record
-
- Public keys used by the DNS infrastructure are stored in KEY resource
- 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,
- all other uses are obsolete. The KEY RR plays an essential role in
- the secure processing of DNS messages and is included in various
- responses. 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.
-
-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, 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
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | flags | protocol | algorithm |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
- / public key /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-
-2.1.1 The Flags Field
-
- Bit 7 of the Flags Field is the "zone key flag". 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. 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
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 5]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
- 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
- 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
-
- The Protocol Octet value 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 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. 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.
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 6]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
- 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 the key uses. Only local domain name
- 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
-
- A KEY RR may appear as a single line. 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 is represented as an unsigned integer or as
- mnemonic specified. The mnemonic is listed in the document defining
- the algorithm.
-
- The Public Key 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==)
-
- 256 indicates the flags field has the zone key bit is set. 3 is the
- fixed Protocol Octet value. 5 indicates the public key algorithm is
- RSA/SHA1 RFC 3110]. The remaining text is base 64 encoding of the
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 7]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
- public key and the format of the public key 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 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].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 8]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-3. The SIG Resource Record
-
- The SIG or "signature" resource record (RR) is the fundamental way
- that data is authenticated in the secure Domain Name System (DNS).
- As such it is the heart of the security provided.
-
- The SIG RR authenticates an RRset [5] of a particular type, class,
- and name and binds it to a time interval and the signer's name. The
- signer is the key (and associated KEY record) from which the RR
- originated. A SIG record can also be used for transaction security
- [transaction ref/section]. This type of SIG is known 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].
-
- 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 SHOULD be the same as 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 /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 9]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-3.1.1 The Type Covered Field
-
- For RRset SIGs, the type covered MUST be the same as the type of data
- in the associated RRset. For SIG(0), this field MUST be zero [10]
-
-3.1.2 The Algorithm Number Field
-
- The Algorithm Number field in the RDATA is the same field as found in
- the algorithm field of the KEY record RDATA [section 2.2.3].
-
-3.1.3 The Labels Field
-
- The "labels" octet is an unsigned count of how many labels there are
- in the original SIG RR owner name. This does not count null labels
- for root and any initial "*" for a wildcard. The labels count MUST
- be less than or equal to the number of labels in the SIG owner name.
-
-3.1.4 Original TTL Field
-
- The "original TTL" field is included in the RDATA portion to avoid
- authentication problems caused by caching servers decrementing the
- 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
- the SIG record itself.
-
-3.1.5 Signature Expiration and Inception Fields
-
- The SIG is valid from the "signature inception" time until the
- "signature expiration" time. Both are unsigned numbers of seconds
- since the start of 1 January 1970, GMT, ignoring leap seconds. Ring
- arithmetic is used as for DNS SOA serial numbers [3], which means
- 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 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
-
- 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 the key algorithm in use, as described
- in Appendix (A).
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 10]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-3.1.7 The Signer's Name Field
-
- The signer's name field MUST contain the name of the zone to which
- the data and signature belong. The combination of signer's name, key
- tag, and algorithm MUST identify a zone key if the SIG is to be
- considered material. In a SIG(0), the signer's name MUST be the
- originating host of the DNS message [10].
-
-3.1.8 The Signature Field
-
- The actual signature portion of the SIG RR binds the other RDATA
- fields to the RRset of the "type covered" RRs with that owner name
- and class.
-
-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 signature over an RRset, a data sequence is
- constructed as follows (where "|" is concatenation):
-
- signature = sign(RDATA | RR(1) | RR(2)... )
-
- RR(N) = name | class | type | original TTL(stored in SIG RDATA) |
- RDATA
-
- To generate a signature over a DNS message (SIG(0)), a data sequence
- is constructed as follows:
-
- If the DNS message is sent via UDP:
-
- signature = sign(RDATA | full query | full response - SIG(0))
-
- If the DNS message is sent via TCP, the first packet's SIG(0) is
- calculated as above, with each additional packet (if any) calculated
- as follows:
-
- signature = sign(RDATA | DNS payload - SIG(0) | previous packet)
-
- where "previous packet" is the previous DNS packet with accompanying
- SIG(0), but without any other headers (i.e. TCP/IP, etc.).
-
- In all the examples,
-
- RDATA is the wire format of all the RDATA fields in the SIG RR itself
- (including the canonical form of the signer's name) before but not
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 11]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
- including the signature, and
-
- RR(num) is the RRset with the same owner name and class and type
- covered as the SIG RR in canonical form.
-
- Name is the Fully Qualified Domain Name (FQDN) in canonical form.
-
- The canonical form for a Resource Record (RR) is the wire format of
- the RR. Names MUST be expanded (no name compression allowed). Name
- 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
- dependent. These algorithm dependent formats and procedures are
- described in separate documents.
-
- SIGs SHOULD NOT be generated for any "meta-type" such as ANY, AXFR,
- etc.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 12]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-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 lists the next canonical name in the zone and lists what
- RR types are present for the current name of the NXT RR.
-
- The set of NXT RRs in a zone is a chain of all authoritative names in
- that zone.
-
- Glue address records MUST NOT be covered by a NXT RR.
-
- 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.
-
-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" field contains the next owner name in
- canonical order. Canonical order means sorted by label, highest
- level label first. The "next domain name" field of the NXT RR at the
- last name in the zone contains the zone apex name.
-
- Glue address record names MUST NOT be covered by the "next domain
- name" field.
-
- The "next domain name" field allows message compression.
-
-4.1.2 The Type Bit Map Field
-
- The "type bit map" field format contains a single bit per RR type for
- RRsets with the same owner name as the NXT RR. A one bit indicates
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 13]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
- 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
- assigned and the corresponding bit MUST be zero. If the zero bit is
- one, it indicates that an unspecified format is used. This format is
- not used when there exist an RR type number greater than 127.
-
- The OPT RR [8] type MUST NOT be covered by the type bit map field
- since it is not part of the zone data. The corresponding OPT RR type
- bit (40) MUST be zero.
-
- Trailing zero octets MUST be omitted. Trailing zero octets not
- specified MUST be interpreted as zero octets. Glue address record
- types MUST NOT be covered by the type bit map field.
-
-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" field is represented as a domain name.
-
- The "type bit map" field is represented as a sequence of RR type
- mnemonics or as an unsigned integer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 14]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-5. The DS Resource Record
-
- The DS record is a major change to DNS: it is the first resource
- record that can appear only on the upper side of a delegation. Other
- keys MAY sign the child's apex KEY RRset. DS records MUST point to
- zone KEY records that are allowed to authenticate DNS data.
-
- The type number for the DS record is 43.
-
- The DS record is class independent.
-
-5.1 DS RDATA Wire Format
-
- This record contains these fields: key tag, algorithm, digest type,
- and the digest of a public key KEY record that is allowed and/or used
- 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
- 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 the same key tag value in the SIG RRs generated
- using the KEY record this DS record points too. Having the key tag
- in the RDATA provides additional reliability in matching than just
- the KEY digest alone. See the key tag for details.
-
-5.1.2 The Algorithm Field
-
- The algorithm value has the same defined values as the KEY and SIG
- records. The value MUST be an algorithm number assigned in the range
- 1..251 and the algorithm MUST be allowed to sign DNS data.
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 15]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-5.1.3 The Digest Type Field
-
- The digest type is an identifier for the digest algorithm used. The
- following numbers have been assigned and the assignment of future
- numbers requires IETF standards action.
-
- VALUE Algorithm STATUS
- 0 Reserved -
- 1 RSA/SHA-1 MANDATORY
- 2-255 Unassigned -
-
-
-
-5.1.4 The Digest Field
-
- The digest is calculated over the canonical name of the delegated
- domain name followed by the whole RDATA of the KEY record (all four
- 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 (
- encoded public key
- ) ; key id = 28668
- 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 key for domain "example." is trusted. Zone "example."
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 16]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
- 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 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 KEY RRset is validated
- 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." by
- examining the parent zone's NXT record for this name. The absence of
- the DS bit indicates an unsecure delegation.
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 17]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-6. DNSSEC message bits
-
- There are 3 new bits allocated for use with DNSSEC. The DO bit 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 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 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 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 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 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 18]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
- The usage of the DO bit is defined in [14]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 19]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-7. IANA Considerations
-
- This document clarifies the use of existing types and introduces no
- new IANA considerations.
-
- The definitions of the flag bits in the KEY RR are set by working
- group consensus and there is no IANA registry for their definition.
- Changes to the meaning of the bits in the flags section of the KEY
- RDATA must be done through working group consensus.
-
- RFC 2535 created an IANA registry for DNSSEC Resource Record
- algorithm Octet values. Values to 1-5, and 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, 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
- 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
- algorithms. Defined types are: 0 is Reserved, 1 is SHA-1. Adding
- new reservations requires IETF standards action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 20]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-8. Security Considerations
-
- This document describes the format of resource records used by DNS
- security. The threats facing DNS are described in a separate
- document and these records are used to help counter those threats.
- The records themselves introduce no new security considerations, but
- the protocol use of these records is described in a second document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 21]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-9. 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 of these
- security extension specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 22]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-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 2002.
-
- [14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC
- Protocol", February 2002.
-
- [15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record", draft-ietf-dnsext-restrict-key-for-dnssec-01 (work in
- progress), January 2002.
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 23]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-Authors' Addresses
-
- Roy Arends
- Nominum, Inc.
- 2385 Bay Street
- Redwood City, CA 94063
- USA
-
- EMail: roy.arends@nominum.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
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 24]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-Appendix A. Key Tag Calculation
-
- The key tag field in the SIG RR is just a means of more efficiently
- selecting the correct KEY RR to use when there is more than one KEY
- RR candidate available, for example, in verifying a signature. It is
- possible for more than one candidate key to have the same tag, in
- which case each must be tried until one works or all fail. The
- following reference implementation of how to calculate the Key Tag,
- for all algorithms other than algorithm 1 (which is NOT RECOMMENDED),
- is in ANSI C. The input is the key material in base 64,not the
- entire RDATA of the KEY record that contains the public key. It is
- coded 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 < keysize; ++i )
- ac += (i&1) ? key[i] : key[i]<<8;
- ac += (ac>>16) & 0xFFFF;
- return ac & 0xFFFF;
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 25]
-\f
-Internet-Draft DNSSEC Resource Records February 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 2, 2002 [Page 26]
-\f
--- /dev/null
+
+
+Network Working Group R. Arends
+Internet-Draft
+Expires: April 29, 2003 M. Larson
+ VeriSign
+ D. Massey
+ USC/ISI
+ S. Rose
+ NIST
+ October 29, 2002
+
+
+ Resource Records for the DNS Security Extensions
+ 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 April 29, 2003.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document is part of a family of documents that describe the DNS
+ Security Extensions (DNSSEC). The DNS Security Extensions are a
+ collection of resource records and protocol modifications that
+ provide source authentication for the DNS. This document defines the
+ KEY, DS, SIG, and NXT resource records. The purpose and format of
+ each resource record is descibed in detail and an example of each
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 1]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ resource record is given.
+
+ This document obsoletes RFC 2535 and incorporates changes from all
+ updates to RFC 2535.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Background and Related Documents . . . . . . . . . . . . . 4
+ 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . 4
+ 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . 4
+ 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . 5
+ 2. The KEY Resource Record . . . . . . . . . . . . . . . . . 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.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 11
+ 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 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 SIG RR Presentation Format . . . . . . . . . . . . . . 13
+ 3.4 Example of a SIG RR . . . . . . . . . . . . . . . . . . . 13
+ 4. The NXT Resource Record . . . . . . . . . . . . . . . . . 15
+ 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 15
+ 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 15
+ 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 16
+ 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . 17
+ 5. The DS Resource Record . . . . . . . . . . . . . . . . . . 18
+ 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18
+ 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 18
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 2]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 19
+ 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 19
+ 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 19
+ 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . 19
+ 5.3 DS Record Example . . . . . . . . . . . . . . . . . . . . 20
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 21
+ 7. Security Considerations . . . . . . . . . . . . . . . . . 22
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 3]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+1. Introduction
+
+ The DNS Security Extensions (DNSSEC) introduce four resource records:
+ the KEY, SIG, NXT, and DS resource records. This document defines
+ the purpose of each resource record (RR), the RR's RDATA format, and
+ its ASCII representation. An example of each RR type is also given.
+
+1.1 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
+ [13]. A description of DNS protocol modifications can be found in
+ [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.
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 4]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ 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".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 5]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+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 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, 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
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | Protocol | Algorithm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | /
+ / Public Key /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+
+2.1.1 The Flags Field
+
+ Bit 7 of the Flags field is the Zone Key flag. If bit 7 is 1, then
+ the KEY record holds a DNS zone 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
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 6]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ other type of DNS public key, such as a public key used by SIG(0) or
+ TKEY.
+
+ Bits 0-6 and 8-15 are reserved for future use and MUST be zero.
+
+2.1.2 The Protocol Octet Field
+
+ The Protocol Octet field MUST be 3.
+
+2.1.3 The Algorithm and Public Key Fields
+
+ The Algorithm field identifies the public key's cryptographic
+ algorithm and determines the format of the Public Key field. A list
+ of DNSSEC algorithm types can be found in Appendix A.1
+
+2.1.4 Notes on KEY RDATA Design
+
+ Although the Protocol Octet field is always 3, it is retained for
+ backwards compatibility with an earlier version of the KEY record.
+ The use of bit 7 as the Zone Key Flag is also due to backwards
+ compatiblity issues.
+
+2.2 The KEY RR Presentation Format
+
+ A KEY RR may appear as a single line or multiple lines separated with
+ newline characters if those lines are contained with parantheses.
+ The presentation format of the RDATA portion is as follows:
+
+ The Flag field is represented as an unsigned integer.
+
+ The Protocol Octet field is represented as the unsigned integer 3.
+
+ The Algorithm field is represented as an unsigned integer or as an
+ algorithm mnemonic specified in Appendix A.1.
+
+ The Public Key field is a Base 64 encoding of the Public Key Field.
+
+2.3 KEY RR Example
+
+ 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 field has the zone key bit is set. 3
+ is the fixed Protocol Octet value. 5 indicates the public key
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 7]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ algorithm. Appendix A.1 identifies algorithm type 5 as RSA/SHA1 and
+ indicates that the format of the RSA/SHA1 public key field is defined
+ in [12]. The remaining text is a base 64 encoding of the public key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 8]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+3. The SIG Resource Record
+
+ DNSSEC uses public key cryptogrpahy to sign and authenticate DNS
+ resource record sets (RRsets). The signatures are stored in SIG
+ 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.
+
+ A SIG record contains the signature for an RRset with a particular
+ name, class, and type. The SIG RR is said to "cover" this RRset.
+ The SIG RR also specifies a validity interval for the signature and
+ uses an algorithm signer's name, and key tag to identify the public
+ key (KEY record) that can be used to verify the signature.
+
+ The signature in SIG RR may also cover a transaction rather than an
+ 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 SIG RR is class independent, but MUST have the same class as the
+ RRset it covers.
+
+ The SIG RR TTL SHOULD match the TTL of the RRset it covers.
+
+3.1 The SIG RDATA
+
+ 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
+ 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 /
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 9]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+3.1.1 The Type Covered Field
+
+ The Type Covered field identifies the RRset type covered by the SIG
+ 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
+
+ The Algorithm Number field identies the cryptographic algorithm used
+ to create the signature. A list of DNSSEC algorithm types can be
+ found in Appendix A.1
+
+3.1.3 The Labels Field
+
+ The Labels field specifies the number of labels in the original SIG
+ RR owner name. 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 "*" 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
+
+ The Original TTL field specifies the 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 will
+ decrement the TTL and [14] describes how the Original TTL field count
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 10]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ 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
+
+ The Signature Inception and Signature Expiration fields specify a
+ validity period for the signature. The SIG record MUST NOT be used
+ for authentication prior to the inception date and MUST NOT be used
+ for authentication after the expiratiation date.
+
+ Inception and expiration dates are given as 32-bit unsigned numbers
+ of seconds since the start of 1 January 1970 GMT, ignoring leap
+ 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
+
+ The Key Tag field contains the key tag of the public key (KEY RR)
+ used to authenticate this signature. The process of calculating a
+ key tag is given in Appendix B.
+
+3.1.7 The Signer's Name Field
+
+ The 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 containing the
+ covered RRset and the SIG. The signer's name MAY be compressed with
+ 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
+
+ The Signature field contains the cryptographic signature. If the
+ Type Covered field is non-zero, the signature covers the SIG RDATA
+ (excluding the Signature field) and the RRset specified by the SIG
+ owner name, SIG class, and SIG Type Covered field.
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 11]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+3.2 Calculating A Signature
+
+ A signature covers either an RRset or a transaction. RRset
+ signatures and transaction signatures are distinguished by the Type
+ Covered field. RRset signatures have a non-zero Type Covered field.
+ SIG RRs SHOULD NOT be generated for any "meta-type" such as ANY or
+ AXFR.
+
+3.2.1 Calculating An RRset Signature
+
+ 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 in cannonical form
+ (see Appendix C) and the set RR(1),...RR(n) is signed as follows:
+
+ signature = sign(SIG_RDATA | RR(1) | RR(2)... ) 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.
+
+ RR(i) = fqdn | class | type | TTL | RDATA length | RDATA
+
+ fqdn is the Fully Qualified Domain Name in canonical
+ form.
+
+ All RR(i) MUST have the same fqdn as the SIG 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 field are in canonical form
+
+ The set of all RR(i) is sorted into cannonical order.
+
+
+3.2.2 Calculating An Transaction Signature
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 12]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+3.3 The SIG RR Presentation Format
+
+ A SIG RR may appear as a single logical line. The presentation
+ format of the RDATA portion is as follows:
+
+ The Type Covered field is represented by either an unsigned integer
+ or the mnemonic for the RR type.
+
+ The Algorithm field is represented as an unsigned integer or as 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 TTL of the SIG RR.
+
+ The Signature Inception Time and Expiration Time fields are
+ represented in the form YYYYMMDDHHmmSS, where:
+
+ YYYY is the year
+
+ 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
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 13]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ (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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 14]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+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 NXT RR is class independent.
+
+ The NXT RR TTL SHOULD NOT exceed the minimum TTL in the zone's SOA
+ RR.
+
+4.1 NXT RDATA Wire Format
+
+ 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 field contains the next authoritive owner name
+ in canonical order, where canonical order is defined in Appendix C.1.
+ For the last owner name in the zone, the Next Domain Name field
+ contains the zone apex name.
+
+ 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.
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 15]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+4.1.2 The Type Bit Map Field
+
+ The Type Bit Map field identifies the RRset types that exist at the
+ NXT's owner name.
+
+ Each bit in the 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 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.
+
+ Trailing zero octets MUST be omitted. Thus the length of the Type
+ Bit Map field varies and is dependent on the largest RR type present
+ for the NXT's owner name. Trailing zero octets not specified MUST be
+ interpreted as zero octets.
+
+ Non-authoritative glue address record types MUST NOT be used when
+ constructing the type bit map field. The OPT RR [8] type (41) also
+ 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
+
+ A NXT RR may appear as a single line. The presentation format of the
+ RDATA portion is as follows:
+
+ The Next Domain Name field is represented as a domain name.
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 16]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ The Type Bit Map field is represented as a sequence of RR type
+ 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]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 17]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+5. The DS Resource Record
+
+ The DS Resource Record points to a KEY RR and is used in the DNS KEY
+ authentication process. A DS RR points to a KEY RR by storing the
+ key tag, algorithm number, and a digest of KEY RR. Note that while
+ the digest should be sufficient to identify key, storing the key tag
+ 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 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
+
+ The RDATA for a DS RR consists of 2 octet Key Tag, a 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 /
+ / /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+5.1.1 The Key Tag Field
+
+ The Key Tag field lists the key tag of the KEY RR pointed to by the
+ DS record. The KEY RR MUST be a a zone key. In other words, the KEY
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 18]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ RR Flags must have Flags bit 7 set to 1.
+
+ 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
+
+ The Algorithm field lists the algorithm number of the KEY RR pointed
+ to by the DS record.
+
+ 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.
+
+5.1.3 The Digest Type Field
+
+ The DS RR points to a KEY RR by including a digest of that KEY RR.
+ The Digest Type field identifes the algorithm used to construct the
+ digest and Appendix A.2 lists the possible digest algorithm types.
+
+5.1.4 The Digest Field
+
+ The DS record points to a KEY RR by including a digest of that KEY
+ RR. The Digest field hold the digest.
+
+ For a given KEY RR, the digest is calculated by appending the KEY
+ RR's cannonical fully qualified owner name with the KEY RDATA and
+ then applying the digest algorithm.
+
+ digest = digest_algorithm( cannonical FQDN 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 RR Presentation Format
+
+ A DS RR may appear as a single line or multiple lines separated with
+ newline characters if those lines are contained within parantheses.
+ The presentation format of the RDATA portion is as follows:
+
+ The Key Tag field is represented as an unsigned integer.
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 19]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ The Algorithm field is represented as an unsigned integer or as an
+ algorithm mnemonic specified in Appendix A.1.
+
+ The Digest Type field is represented as an unsigned integer.
+
+ The Digest is presented in hexadecimal.
+
+5.3 DS Record Example
+
+ The following example shows a KEY RR and its corresponding DS RR.
+
+ dskey.example. 86400 IN KEY 256 3 1 ( AQPwHb4UL1U9RHaU8qP+Ts5bVOU
+ 1s7fYbj2b3CCbzNdj4+/ECd18yKiy
+ UQqKqQFWW5T3iVc8SJOKnueJHt/Jb
+ /wt) ; key tag = 28668
+ dskey.example. 3600 IN DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 20]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+6. IANA Considerations
+
+ This document introduces no new IANA considerations.
+
+ 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.
+
+ RFC 2535 updated the IANA registry for DNS Resource Record Types and
+ assigned types 24,25, and 30 to the SIG, KEY, and NXT (respectively).
+ [DS RFC] assigned DNS Resource Record Type 43 to DS.
+
+ RFC 2535 created an IANA registry for DNSSEC Resource Record
+ Algorithm Numbers. Values to 1-4, and 252-255 were assigned by RFC
+ 2535. Value 5 was assigned by RFC 3110.
+
+ [DS RFC] created an IANA registry for DNSSEC DS Digest Types and
+ assigned value 0 to reserved and value 1 to RSA/SHA-1.
+
+ RFC 2535 created an IANA Registry to KEY Protocol Octet Values, but
+ [KeyRestrict RFC] set all assigned values other than 3 to reserved
+ and closed this IANA registry. The registry remains closed and all
+ KEY records are required to have Protocol Octet value of 3.
+
+ The Flag bits in the KEY RR are not assigned by IANA and there is no
+ IANA registry for these flags. All changes to the meaning of the KEY
+ RR Flag bits require a standards action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 21]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+7. Security Considerations
+
+ This document describes the format of four DNS resource records used
+ by the DNS security extensions and presents an algorithm for
+ calculating a key tag for a public key. Other than the items
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 22]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+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 revision of these
+ security extension specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 23]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+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",
+ October 2002.
+
+ [14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC
+ Protocol", October 2002.
+
+ [15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
+ Record", draft-ietf-dnsext-restrict-key-for-dnssec-02 (work in
+ progress), March 2002.
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 24]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+Authors' Addresses
+
+ Roy Arends
+ Bankastraat 41-E
+ 1094 EB Amsterdam
+ NL
+
+ EMail: 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-8920
+ USA
+
+ EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 25]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+Appendix A. DNSSEC Algorithm and Digest Types
+
+ The 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 permitted. The domain
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 26]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+ 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 -
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 27]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+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
+ 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 < keysize; ++i )
+ ac += (i&1) ? key[i] : key[i]<<8;
+ ac += (ac>>16) & 0xFFFF;
+ return ac & 0xFFFF;
+ }
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 28]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 29]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+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.
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 30]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 31]
+
+Internet-Draft DNSSEC Resource Records October 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires April 29, 2003 [Page 32]
+
+
+
September 2002
- KEY RR Key Signing (KS) Flag
- draft-ietf-dnsext-keyrr-key-signing-flag-01
+ KEY RR Key-Signing Key (KSK) Flag
+ draft-ietf-dnsext-keyrr-key-signing-flag-02
Status of this Memo
Abstract
- With the DS record [1] the concept of key signing and zone signing
- keys has been introduced. Key signing keys are the keys that sign
- the keyset only. In general, key signing keys are the keys that are
+ With the DS record [1] the concept of key-signing and zone-signing
+ keys has been introduced. Key-signing keys are the keys that sign
+ the keyset only. In general, key-signing keys are the keys that are
pointed to by DS records and are the first keys to be used when
- following a chain of trust into the zone. The key signing keys only
- sign the KEY RRset at the apex of a zone, zone signing keys sign all
- data in a zone. We propose a flag to distinguish the key signing key
- from other keys in the KEY RR set during DNSSEC operations.
+ following a chain of trust into the zone. The key-signing keys only
+ sign the KEY RRset at the apex of a zone, zone- signing keys sign all
+ other data in a zone. We propose a flag to distinguish the key-
+ signing key from other keys in the KEY RR set during DNSSEC
+ operations.
-
-Kolkman & Schlyter Expires March 2, 2003 [Page 1]
+Kolkman & Schlyter Expires March 2, 2003 [Page 1]
\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag September 2002
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The Key Signing Flag . . . . . . . . . . . . . . . . . . . . . 3
- 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 3
+ 2. The Key-Signing Key (KSK) Flag . . . . . . . . . . . . . . . . 3
+ 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 4
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
- 6. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 4
- 6.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 5
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
- References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Internationalization Considerations . . . . . . . . . . . . . 5
+ 8. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 5
+ 8.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 5
+ 8.2 draft version 01 -> 02 . . . . . . . . . . . . . . . . . . . . 5
+ 8.3 draft version 02 -> 03 . . . . . . . . . . . . . . . . . . . . 5
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
+ Normative References . . . . . . . . . . . . . . . . . . . . . 6
+ Informative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
-
-
-
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
-
-
-Kolkman & Schlyter Expires March 2, 2003 [Page 2]
+Kolkman & Schlyter Expires March 2, 2003 [Page 2]
\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag September 2002
1. Introduction
- "All keys are equal but some keys are more equal than others" [2]
+ "All keys are equal but some keys are more equal than others" [5]
- With the DS record [1] the concept of key signing and zone signing
- keys has been introduced. In general these are the keys that are
- pointed to by DS records and are the first keys to be used when
- following the chain of trust into a zone ( secure entry points of the
- zone). These key signing keys may also be configured in resolver
- systems that use zones as a trusted root[4] for a secure island.
+ With the DS record [1] the concept of key-signing and zone-signing
+ keys has been introduced into DNSSEC[2]. In general these are the
+ keys that are pointed to by DS records and are the first keys to be
+ used when following the chain of trust into a zone ( secure entry
+ points of the zone). These key-signing keys may also be configured
+ in resolver systems that use zones as a trusted root[3] for a secure
+ island.
Early deployment tests have shown that during the key-exchange
- between the parent and the child it is useful to indicate which keys
+ between the parent and the child it is useful to highlight which keys
are to be used as the secure entry point to a zone. We introduce the
- Key Signing Key flag to indicate this special 'administrative' status
+ Key-Signing Key flag to indicate this special 'administrative' status
of the key. The availability of the flag allows the key exchange to
be automated where, without the flag, some additional out-of-band
communication is needed.
-2. The Key Signing Flag
+2. The Key-Signing Key (KSK) Flag
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |K| protocol | algorithm |
| |S| | |
+ | |K| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
- The bit 15th bit (TBD) in the flags field is assigned to be the key
- signing flag. If set the key is intended to be used as key signing
- key. If the bit is not set, no special meaning should be assigned.
- The 15th bit is currently reserved [3].
+ The KSK bit (TBD) in the flags field is assigned to be the key-
+ signing flag. If set the key is intended to be used as key-signing
+ key. No special meaning should be assigned to the bit not being set.
+ The draft proposes using the current 15'th bit [4] as the KSK bit.
+ This way operators can tell the difference between key and zone-
+ signing keys from the decimal representation of the flag field; it is
+ odd or even respectively.
-3. DNSSEC Protocol Changes
- The use of the KS flag does not change the DNS resolution and
- resolution protocol. The KS flag is only used to provide a hint
- about the different administrative properties and MUST NOT be used
- during the resolving process.
-Kolkman & Schlyter Expires March 2, 2003 [Page 3]
+Kolkman & Schlyter Expires March 2, 2003 [Page 3]
\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag September 2002
+
+3. DNSSEC Protocol Changes
+
+ The use of the KSK flag does not change the DNS resolution and
+ resolution protocol. The KSK flag is only used to provide a hint
+ about the different administrative properties and MUST NOT be used
+ during the resolving process.
4. Operational Guidelines
- By setting the KS flag on a particular key, zone administrators
- indicate that that key should be used as the secure entry point for
+ By setting the KSK flag on a particular key, zone administrators
+ indicate that that key SHOULD be used as the secure entry point for
their zone. Therefore zone administrators SHOULD set the bit only
for zone keys that are used to sign the KEY RRset and are intended to
act as the first link in the chain of trust for their zone.
Parent zone administrators and resolver administrators that want to
- configure a keysigning key as their 'trusted key' MAY choose to
+ configure a key-signing key as their 'trusted key' MAY choose to
ignore the flag.
- Using the flag a key rollover can be automated. The parent can use
+ Using the flag a key roll over can be automated. The parent can use
an existing trust relation to verify keysets in which a new key with
- the KS flag appears.
+ the KSK flag appears.
If the bit is modified during the lifetime of the key then this would
have impact on the keytag and on the hash data in the DS RRs
No trust in a key should be inferred from this flag - trust must be
inferred from an existing chain of trust or an out-of-band exchange.
- Since this flag MAY be used for automating key exchanges, we think
+ Since this flag might be used for automating key exchanges, we think
the following consideration is in place.
- Automated mechanisms for rollover of the DS RR may be vulnerable to a
- class of replay attacks. This may happen after a key exchange where
- a keyset, containing two keys with the KS flag set, is sent to the
- parent. The parent verifies the keyset with the existing trust
+ Automated mechanisms for roll over of the DS RR might be vulnerable
+ to a class of replay attacks. This might happen after a key exchange
+ where a keyset, containing two keys with the KSK flag set, is sent to
+ the parent. The parent verifies the keyset with the existing trust
relation and creates the new DS RR from the key that the current DS
- is not pointing to. This key exchange may be replayed, if the parent
- does not maintain state of which DS RRs where used previously so that
- the new DS RR is replaced by the old DS RR again. These kinds of
- attacks can be prevented by maintaining a registry of keys that have
- been used to generate DS RRs from previously.
+ is not pointing to. This key exchange might be replayed. Parents
+ are encouraged to implement a replay defence. A simple defence can
+ be based on a registry of keys that have been used to generate DS RRs
+
-6. Document Changes
+Kolkman & Schlyter Expires March 2, 2003 [Page 4]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag September 2002
+ during the most recent roll over.
+6. IANA Considerations
+ draft-ietf-dnsext-restrict-key-for-dnssec [4] eliminates all flags
+ field except for the zone key flag in the KEY RR. We propose to use
+ the 15'th bit as the KSK bit; the decimal representation of the
+ flagfield will then be odd for key-signing keys and even for zone-
+ signing keys.
-Kolkman & Schlyter Expires March 2, 2003 [Page 4]
-\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+7. Internationalization Considerations
+ There are no internationalization considerations
-6.1 draft version 00 -> 01
+8. Document Changes
+
+8.1 draft version 00 -> 01
Clean up of references and correction of typos;
Added explicit warning for replay attacks to the security section;
- Removed the text that hinted on a distinction between a keysigning
- key configured in resolvers and in parent zones.
+ Removed the text that hinted on a distinction between a key-
+ signing key configured in resolvers and in parent zones.
-7. Acknowledgments
+8.2 draft version 01 -> 02
- The ideas documented in this draft are inspired by communications we
- had with numerous people and ideas published by other folk, Olafur
- Gudmundsson, Daniel Karrenberg, Dan Massey and Sam Weiler have been
- helping with providing ideas and feedback.
+ Added IANA and Internationalization section.
- This document saw the light during a workshop on DNSSEC operations
- hosted by USC/ISI.
+ Split references into informational and normative.
-References
+ Spelling and style corrections.
- [1] Gudmundsson, "Delegation Signer Resource Record", work in
- progress draft-ietf-dnsext-delegation-signer-08.txt, June 2002.
- [2] Orwell, "Animal Farm; a Fairy Story"", 1945, <http://
- www.ddc.net/ygg/etext/animal.htm#10>.
+8.3 draft version 02 -> 03
- [3] Massey and Rose, "Limiting the Scope of the KEY Resource
- Record", work in progress draft-ietf-dnsext-restrict-key-for-
- dnssec-03, June 28 2002.
+ Changed the name from KS to KSK, this to prevent confusion with
+ NS, DS and other acronyms in DNS.
- [4] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
+ In the security section: Rewrote the section so that it does not
+ suggest to use a particular type of registry and that it is clear
+ that a key registry is only one of the defences possible.
+ Spelling and style corrections
+Kolkman & Schlyter Expires March 2, 2003 [Page 5]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag September 2002
+
+9. Acknowledgments
+ The ideas documented in this draft are inspired by communications we
+ had with numerous people and ideas published by other folk, Olafur
+ Gudmundsson, Daniel Karrenberg, Ed Lewis, Dan Massey and Sam Weiler
+ have been helping with providing ideas and feedback.
+ This document saw the light during a workshop on DNSSEC operations
+ hosted by USC/ISI.
+Normative References
+ [1] Gudmundsson, O., "Delegation Signer Resource Record", draft-
+ ietf-dnsext-delegation-signer-10 (work in progress), October
+ 2002.
+ [2] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+ [3] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+Informative References
+ [4] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
+ Record out", draft-ietf-dnsext-restrict-key-for-dnssec-04 (work
+ in progress), September 2002.
-Kolkman & Schlyter Expires March 2, 2003 [Page 5]
-\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+ [5] Orwell, "Animal Farm; a Fairy Story"", 1945, <http://
+ www.ddc.net/ygg/etext/animal.htm#10>.
Authors' Addresses
URI: http://www.ripe.net/
+
+
+
+
+
+
+Kolkman & Schlyter Expires March 2, 2003 [Page 6]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag September 2002
+
+
Jakob Schlyter
Carlstedt Research & Technology
Stora Badhusgatan 18-20
-Kolkman & Schlyter Expires March 2, 2003 [Page 6]
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Schlyter Expires March 2, 2003 [Page 7]
\f
-Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag September 2002
Full Copyright Statement
-Kolkman & Schlyter Expires March 2, 2003 [Page 7]
+Kolkman & Schlyter Expires March 2, 2003 [Page 8]
\f
Internet Engineering Task Force S. Thomson, Cisco
INTERNET-DRAFT C. Huitema, Microsoft
-September 11, 2002 V. Ksinant, 6WIND
-Expires March 11, 2003 M. Souissi, AFNIC
+October 29, 2002 V. Ksinant, 6WIND
+Expires April 29, 2003 M. Souissi, AFNIC
DNS Extensions to support IP version 6
- <draft-ietf-dnsext-rfc1886bis-00.txt>
+ <draft-ietf-dnsext-rfc1886bis-01.txt>
Status of this Memo
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
- This Internet Draft expires March 11, 2003.
+ This Internet Draft expires April 29, 2003.
This document defines the changes that need to be made to the Domain
Name System to support hosts running IP version 6 (IPv6). The
- changes include a new resource record type to store an IPv6 address,
- a new domain to support lookups based on an IPv6 address, and updated
+ changes include a resource record type to store an IPv6 address,
+ a domain to support lookups based on an IPv6 address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.
- This document updates RFC 1886 [5]. Changes mainly consist in
- replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152 [6].
+ This Document combines RFC1886 and changes to RFC 1886 made by
+ RFC 3152, obsoleting both. Changes mainly consist in replacing
+ the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
+
-draft-ietf-dnsext-rfc1886bis-00.txt [Page 1]
+draft-ietf-dnsext-rfc1886bis-01.txt [Page 1]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
Table of Contents
2.5. IP6.ARPA domain..................................... 3
3. Modifications to existing query types.................... 4
4. Security Considerations.................................. 4
+ 5. IANA Considerations...................................... 4
APPENDIX A: Changes from RFC-1886............................ 4
Acknowledgments.............................................. 5
References................................................... 5
addresses[3] since applications assume that address queries return
32-bit IPv4 addresses only.
- To support the storage of IPv6 addresses we define the following
- extensions:
+ To support the storage of IPv6 addresses in DNS, this document
+ defines the following extensions:
- o A new resource record type is defined to map a domain name to an
+ o A resource record type is defined to map a domain name to an
IPv6 address.
- o A new domain is defined to support lookups based on address.
+ o A domain is defined to support lookups based on address.
o Existing queries that perform additional section processing to
locate IPv4 addresses are redefined to perform additional
are discussed in [4].
-2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
+2. RESOURCE RECORD DEFINITION AND DOMAIN
- A new record type is defined to store a host's IPv6 address. A host
+ A record type is defined to store a host's IPv6 address. A host
that has more than one IPv6 address must have more than one such
record.
-draft-ietf-dnsext-rfc1886bis-00.txt [Page 2]
+draft-ietf-dnsext-rfc1886bis-01.txt [Page 2]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
2.1 AAAA record type
- The AAAA resource record type is a new record specific to the
- Internet class that stores a single IPv6 address.
+ The AAAA resource record type is a record specific to the Internet
+ class that stores a single IPv6 address.
- The value of the type is 28 (decimal).
+ The IANA assigned value of the type is 28 (decimal).
2.2 AAAA data format
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
ARPA.
-draft-ietf-dnsext-rfc1886bis-00.txt [Page 3]
+draft-ietf-dnsext-rfc1886bis-01.txt [Page 3]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
3. MODIFICATIONS TO EXISTING QUERY TYPES
All existing query types that perform type A additional section
- processing, i.e. name server (NS), mail exchange (MX) and mailbox
- (MB) query types, must be redefined to perform both type A and type
- AAAA additional section processing. These new definitions mean that a
- name server must add any relevant IPv4 addresses and any relevant
- IPv6 addresses available locally to the additional section of a
- response when processing any one of the above queries.
+ processing, i.e. name server (NS) and mail exchange (MX) query
+ types, must be redefined to perform both type A and type AAAA
+ additional section processing. These definitions mean that a name
+ server must add any relevant IPv4 addresses and any relevant IPv6
+ addresses available locally to the additional section of a response
+ when processing any one of the above queries.
4. SECURITY CONSIDERATIONS
So, this specification is not believed to cause any new security
problems, nor to solve any existing ones.
+5. IANA CONSIDERATIONS
+ There are no IANA assignments to be performed.
+
APPENDIX A: Changes from RFC 1886
The following changes were made from RFC 1886 "DNS Extensions to
- Updated document abstract
- Added table of contents
- Added full copyright statement
+ - Added IANA considerations section
-
-
-
-draft-ietf-dnsext-rfc1886bis-00.txt [Page 4]
+draft-ietf-dnsext-rfc1886bis-01.txt [Page 4]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
Acknowledgements
Many thanks to Alain Durand and Olafur Gudmundsson for their support.
-REFERENCES
+Normative References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[3] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, Nokia, Cisco, July 1998.
This RFC is being updated. The current draft is
- "draft-ietf-ipngwg-addr-arch-v3-09.txt", Hinden, R., and
- S. Deering, August 26, 2002
+ "draft-ietf-ipngwg-addr-arch-v3-11.txt", Hinden, R., and
+ S. Deering, October 25, 2002
[4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems
-draft-ietf-dnsext-rfc1886bis-00.txt [Page 5]
+draft-ietf-dnsext-rfc1886bis-01.txt [Page 5]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
Authors' Addresses
-draft-ietf-dnsext-rfc1886bis-00.txt [Page 6]
+draft-ietf-dnsext-rfc1886bis-01.txt [Page 6]
\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 September 2002
+INTERNET-DRAFT DNS Extensions to support IP version 6 October 2002
Full Copyright Statement
information to the IETF Executive Director.
-draft-ietf-dnsext-rfc1886bis-00.txt [Page 7]
+draft-ietf-dnsext-rfc1886bis-01.txt [Page 7]
projects / thirdparty / bind9.git / commitdiff
