in the spirit of the robustness principle (being liberal in what it
accepts), it MUST remove all but one of the duplicate RR(s) for the
purposes of calculating the canonical form of the RRset.
7. IANA Considerations
This document introduces no new IANA considerations, as all of the
protocol parameters used in this document have already been assigned
by previous specifications. However, since the evolution of DNSSEC
has been long and somewhat convoluted, this section attempts to
describe the current state of the IANA registries and other protocol
parameters that are (or once were) related to DNSSEC.
Please refer to [RFC4035] for additional IANA considerations.
DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS
Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47,
and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
[RFC3755] also marked type 30 (NXT) as Obsolete and restricted use
of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
security protocol described in [RFC2931] and to the transaction
KEY Resource Record described in [RFC2930].
DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
for DNSSEC Resource Record Algorithm field numbers and assigned
values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755]
altered this registry to include flags for each entry regarding
its use with the DNS security extensions. Each algorithm entry
could refer to an algorithm that can be used for zone signing,
transaction security (see [RFC2931]), or both. Values 6-251 are
available for assignment by IETF standards action ([RFC3755]).
See Appendix A for a full listing of the DNS Security Algorithm
Numbers entries at the time of this writing and their status for
use in DNSSEC.
[RFC3658] created an IANA registry for DNSSEC DS Digest Types and
assigned value 0 to reserved and value 1 to SHA-1.
KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
Protocol Values, but [RFC3445] reassigned all values other than 3
to reserved and closed this IANA registry. The registry remains
closed, and all KEY and DNSKEY records are required to have a
Protocol Octet value of 3.
Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
this registry only contains assignments for bit 7 (the ZONE bit)
and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
As stated in [RFC3755], bits 0-6 and 8-14 are available for
assignment by IETF Standards Action.
8. Security Considerations
This document describes the format of four DNS resource records used
by the DNS security extensions and presents an algorithm for
calculating a key tag for a public key. Other than the items
described below, the resource records themselves introduce no
security considerations. Please see [RFC4033] and [RFC4035] for
additional security considerations related to the use of these
records.
The DS record points to a DNSKEY RR by using a cryptographic digest,
the key algorithm type, and a key tag. The DS record is intended to
identify an existing DNSKEY RR, but it is theoretically possible for
an attacker to generate a DNSKEY that matches all the DS fields. The
probability of constructing a matching DNSKEY depends on the type of
digest algorithm in use. The only currently defined digest algorithm
is SHA-1, and the working group believes that constructing a public
key that would match the algorithm, key tag, and SHA-1 digest given
in a DS record would be a sufficiently difficult problem that such an
attack is not a serious threat at this time.
The key tag is used to help select DNSKEY resource records
efficiently, but it does not uniquely identify a single DNSKEY
resource record. It is possible for two distinct DNSKEY RRs to have
the same owner name, the same algorithm type, and the same key tag.
An implementation that uses only the key tag to select a DNSKEY RR
might select the wrong public key in some circumstances. Please see
Appendix B for further details.
The table of algorithms in Appendix A and the key tag calculation
algorithms in Appendix B include the RSA/MD5 algorithm for
completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
explained in [RFC3110].
9. Acknowledgements
This document was created from the input and ideas of the members of
the DNS Extensions Working Group and working group mailing list. The
editors would like to express their thanks for the comments and
suggestions received during the revision of these security extension
specifications. Although explicitly listing everyone who has
contributed during the decade in which DNSSEC has been under
development would be impossible, [RFC4033] includes a list of some of
the participants who were kind enough to comment on these documents.
10. References
10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
System (DNS)", RFC 2536, March 1999.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000.
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004.
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
System KEY (DNSKEY) Resource Record (RR) Secure Entry
Point (SEP) Flag", RFC 3757, April 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
10.2. Informative References
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
Name System (DNS)", RFC 2537, March 1999.
[RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
RDATA Format", RFC 3845, August 2004.
Appendix A. DNSSEC Algorithm and Digest Types
The DNS security extensions are designed to be independent of the
underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS
resource records all use a DNSSEC Algorithm Number to identify the
cryptographic algorithm in use by the resource record. The DS
resource record also specifies a Digest Algorithm Number to identify
the digest algorithm used to construct the DS record. The currently
defined Algorithm and Digest Types are listed below. Additional
Algorithm or Digest Types could be added as advances in cryptography
warrant them.
A DNSSEC aware resolver or name server MUST implement all MANDATORY
algorithms.
A.1. DNSSEC Algorithm Types
The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
security algorithm being used. These values are stored in the
"Algorithm number" field in the resource record RDATA.
Some algorithms are usable only for zone signing (DNSSEC), some only
for transaction security mechanisms (SIG(0) and TSIG), and some for
both. Those usable for zone signing may appear in DNSKEY, RRSIG, and
DS RRs. Those usable for transaction security would be present in
SIG(0) and KEY RRs, as described in [RFC2931].
Zone
Value Algorithm [Mnemonic] Signing References Status
----- -------------------- --------- ---------- ---------
0 reserved
1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED
2 Diffie-Hellman [DH] n [RFC2539] -
3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL
4 Elliptic Curve [ECC] TBA -
5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY
252 Indirect [INDIRECT] n -
253 Private [PRIVATEDNS] y see below OPTIONAL
254 Private [PRIVATEOID] y see below OPTIONAL
255 reserved
6 - 251 Available for assignment by IETF Standards Action.
A.1.1. Private Algorithm Types
Algorithm number 253 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with a wire encoded
domain name, which MUST NOT be compressed. The domain name indicates
the private algorithm to use, and the remainder of the public key
area is determined by that algorithm. Entities should only use
domain names they control to designate their private algorithms.
Algorithm number 254 is reserved for private use and will never be
assigned to a specific algorithm. The public key area in the DNSKEY
RR and the signature area in the RRSIG RR begin with an unsigned
length byte followed by a BER encoded Object Identifier (ISO OID) of
that length. The OID indicates the private algorithm in use, and the
remainder of the area is whatever is required by that algorithm.
Entities should only use OIDs they control to designate their private
algorithms.
A.2. DNSSEC Digest Types
A "Digest Type" field in the DS resource record types identifies the
cryptographic digest algorithm used by the resource record. The
following table lists the currently defined digest algorithm types.
VALUE Algorithm STATUS
0 Reserved -
1 SHA-1 MANDATORY
2-255 Unassigned -
Appendix B. Key Tag Calculation
The Key Tag field in the RRSIG and DS resource record types provides
a mechanism for selecting a public key efficiently. In most cases, a
combination of owner name, algorithm, and key tag can efficiently
identify a DNSKEY record. Both the RRSIG and DS resource records
have corresponding DNSKEY records. The Key Tag field in the RRSIG
and DS records can be used to help select the corresponding DNSKEY RR
efficiently when more than one candidate DNSKEY RR is available.
However, it is essential to note that the key tag is not a unique
identifier. It is theoretically possible for two distinct DNSKEY RRs
to have the same owner name, the same algorithm, and the same key
tag. The key tag is used to limit the possible candidate keys, but
it does not uniquely identify a DNSKEY record. Implementations MUST
NOT assume that the key tag uniquely identifies a DNSKEY RR.
The key tag is the same for all DNSKEY algorithm types except
algorithm 1 (please see Appendix B.1 for the definition of the key
tag for algorithm 1). The key tag algorithm is the sum of the wire
format of the DNSKEY RDATA broken into 2 octet groups. First, the
RDATA (in wire format) is treated as a series of 2 octet groups.
These groups are then added together, ignoring any carry bits.
A reference implementation of the key tag algorithm is as an ANSI C
function is given below, with the RDATA portion of the DNSKEY RR is
used as input. It is not necessary to use the following reference
code verbatim, but the numerical value of the Key Tag MUST be
identical to what the reference implementation would generate for the
same input.
Please note that the algorithm for calculating the Key Tag is almost
but not completely identical to the familiar ones-complement checksum
used in many other Internet protocols. Key Tags MUST be calculated
using the algorithm described here rather than the ones complement
checksum.
The following ANSI C reference implementation calculates the value of
a Key Tag. This reference implementation applies to all algorithm
types except algorithm 1 (see Appendix B.1). The input is the wire
format of the RDATA portion of the DNSKEY RR. The code is written
for clarity, not efficiency.
/*
* Assumes that int is at least 16 bits.
* First octet of the key tag is the most significant 8 bits of the
* return value;
* Second octet of the key tag is the least significant 8 bits of the
* return value.
*/
unsigned int
keytag (
unsigned char key[], /* the RDATA part of the DNSKEY RR */
unsigned int keysize /* the RDLENGTH */
)
{
unsigned long ac; /* assumed to be 32 bits or larger */
int i; /* loop index */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i & 1) ? key[i] : key[i] << 8;
ac += (ac >> 16) & 0xFFFF;
return ac & 0xFFFF;
}
B.1. Key Tag for Algorithm 1 (RSA/MD5)
The key tag for algorithm 1 (RSA/MD5) is defined differently from the
key tag for all other algorithms, for historical reasons. For a
DNSKEY RR with algorithm 1, the key tag is defined to be the most
significant 16 bits of the least significant 24 bits in the public
key modulus (in other words, the 4th to last and 3rd to last octets
of the public key modulus).
Please note that Algorithm 1 is NOT RECOMMENDED.
Authors’ Addresses
Roy Arends
Telematica Instituut
Brouwerijstraat 1
7523 XC Enschede
NL
EMail: roy.arends@telin.nl
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com
Dan Massey
Colorado State University
Department of Computer Science
Fort Collins, CO 80523-1873
EMail: massey@cs.colostate.edu
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.