Network Working Group R. Arends
Internet-Draft Nominum
Expires: January 21, 2003 M. Larson
VeriSign
D. Massey
USC/ISI
S. Rose
NIST
July 23, 2002
DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-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 January 21, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The Domain Name System Security Extensions (DNSSEC) provide data
origin authentication and data integrity. This document introduces
these extensions and describes their capabilities and limitations.
The services that the security extensions provide and do not provide
are discussed. Lastly, the group of documents that describe the DNS
security extensions and their interrelationships is discussed.
Arends, et al. Expires January 21, 2003 [Page 1]
Internet-Draft DNSSEC Intro. and Requirements July 2002
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 [1].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 4
3. Services Provided by DNS Security . . . . . . . . . . . . . 5
3.1 Data Origin Authentication and Data Integrity . . . . . . . 5
3.1.1 Authenticating Name and Type Non-Existence . . . . . . . . . 6
3.2 Key Distribution . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Transaction Security . . . . . . . . . . . . . . . . . . . . 7
4. Services Not Provided by DNS Security . . . . . . . . . . . 8
5. Resolver Considerations . . . . . . . . . . . . . . . . . . 9
6. Zone Considerations . . . . . . . . . . . . . . . . . . . . 10
7. Server Considerations . . . . . . . . . . . . . . . . . . . 11
8. DNS Security Document Family . . . . . . . . . . . . . . . . 12
8.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . 12
8.2 Categories of DNS Security Documents . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
Arends, et al. Expires January 21, 2003 [Page 2]
Internet-Draft DNSSEC Intro. and Requirements July 2002
1. Introduction
This document introduces the Domain Name System Security Extensions
(DNSSEC). This document and a collection of related documents update
RFC 2535 [2] and its related documents to further clarify and refine
the security extensions defined in RFC 2535. These security
extensions consist of a set of new resource record types and
modifications to the existing DNS protocol [3]. The new records and
protocol modifications are not fully described in this document, but
in a family of documents outlined in Section 8. The capabilities and
limitations of the security extensions are described in greater
detail in Section 3 and Section 4, respectively. Lastly, the effect
that these security extensions will have on resolvers, zones and
servers is discussed in Section 5, Section 6 and Section 7,
respectively.
The DNS security extensions provide data origin authentication and
data integrity protection as well as a means of public key
distribution. The security extensions do not provide protection
against other types of attack, nor do they provide confidentiality.
Arends, et al. Expires January 21, 2003 [Page 3]
Internet-Draft DNSSEC Intro. and Requirements July 2002
2. Definitions of Important DNSSEC Terms
trusted key: A public key, for a zone or a host, that a resolver
trusts and that can therefore be used to verify data. A key can
become trusted in two ways. First, it can be statically
configured and declared as trusted in the resolver's
configuration. Second, if a new key is referenced by a DS record
that is signed by an already trusted key, and the signature
verifies, the new key becomes trusted.
chain of trust: In DNSSEC, a key signs a DS record, which points to
another key, which in turn signs another DS record, which points
to yet another key, etc. This alternating succession of KEY and
DS records forms a chain of signed data, with each link in the
chain vouching for the next. A resolver starting at a piece of
data in the chain signed by a trusted key can verify all
subsequent signatures. Thus all subsequent data in the chain is
trusted.
security-aware resolver: A resolver (defined in section 2.4 of [4])
that understands the DNS security extensions. In particular, a
security-aware resolver uses trusted keys to verify signatures
over RRsets and (optionally) DNS messages.
security-aware server: A name server (also defined in section 2.4 of
[4]) that understands the DNS security extensions. In particular,
it supports the KEY, SIG, DS and NXT record types, a larger DNS
message size via EDNS0, and other protocol changes such as support
for the OK bit. Also called a "secure server".
unsecure server: The proper term for the opposite of a security-aware
server.
unsigned zone: The proper term for the opposite of a secure zone.
secure zone: A zone whose RRsets are signed and which contains
properly constructed KEY, SIG, NXT and (optionally) DS records.
Arends, et al. Expires January 21, 2003 [Page 4]
Internet-Draft DNSSEC Intro. and Requirements July 2002
3. Services Provided by DNS Security
The Domain Name System (DNS) protocol security extensions provide
three distinct services: Data origin authentication and data
integrity, key distribution, and transaction security, as described
below.
These services protect against the threats to the Domain Name System
described in [5].
3.1 Data Origin Authentication and Data Integrity
Authentication is provided by cryptographically generated digital
signatures associated with DNS RRsets. These digital signatures are
stored in a new resource record, the SIG record. Typically, there
will be a single private key that signs a zone's data, but multiple
keys are possible; e.g., for different digital signature algorithms.
If a security-aware resolver reliably learns a zone's public key, it
can authenticate that zone's signed data. An important DNSSEC
concept is that the key that signs a zone's data is associated with
the zone itself and not with the zone's authoritative servers
(although hosts can also have key pairs in DNSSEC; see the reference
to SIG(0) in Section 3.3 below). Security-aware servers attempt to
send the signature(s) needed to authenticate an RRset in the DNS
reply message along with the RRset itself, provided there is space
available in the message.
A resolver could learn a zone's public key by having the key
statically configured or by normal DNS resolution. To allow the
latter, public keys are stored in a new resource record, the KEY
record (see Section 3.2 below). (Note that the private keys used to
sign zone data must be kept secure and best practices call for them
to be stored offline.) To reliably discover a public key by DNS
resolution, the key itself needs to be signed by another key that the
resolver trusts. Zone information is authenticated by forming a
chain of trust from a newly learned public key back to a trusted
public key (which is either statically configured or previously
learned and verified). Therefore, the resolver must be configured
with at least one public key that authenticates one zone as a
starting point. To establish this chain of trust, security-aware
servers attempt to send the signature(s) needed to authenticate a
zone's public key in the DNS reply message along with the public key
itself, provided there is space available in the message.
The chain of trust specified in the original DNS security extensions
proceeded from signed KEY record to signed KEY record, as necessary,
and finally to the queried RRset. A new record, the delegation
signer (DS), has been added for additional flexibility. The DS RRset
Arends, et al. Expires January 21, 2003 [Page 5]
Internet-Draft DNSSEC Intro. and Requirements July 2002
resides at a delegation point in a parent zone and specifies the keys
used by the specified child zone to self-sign the KEY RRset at its
apex. The child, in turn, uses one of these keys to sign its zone
data. The chain of trust is therefore DS->KEY->[DS->KEY->...]-
>RRset.
Adding data origin authentication and data integrity requires minor
changes to the on-the-wire DNS protocol. Several new resource record
types are required, including the aforementioned SIG, KEY and DS.
EDNS0 support [6] for larger message sizes [7] is required, as is
support for the OK bit [8].
3.1.1 Authenticating Name and Type Non-Existence
The security mechanism referenced above in Section 3.1 only provides
a way to sign existing RRsets in a zone. The problem of providing
negative responses with the same level of authentication and
integrity requires the use of another new resource record, the non-
existence (NXT) record. The NXT record allows a negative reply
(either for name or type non-existence) to be authenticated the same
way as other DNS replies. NXT records require a canonical
representation and order for domain names in zones. NXT records
exist to cover the gaps, or "empty space", between domain names in a
zone, as well as non-existent record types for existing names. Each
NXT record is signed and authenticated in the same way as any other
RRset.
3.2 Key Distribution
The KEY resource record is defined to associate public keys with DNS
names. This record permits the DNS to be used as a public key
distribution mechanism in support of DNSSEC. Security-aware
resolvers can query for a zone's public key when establishing a chain
of trust.
The syntax of the KEY resource record (and the other additional
resource records required for DNSSEC) is described in [9]. It
includes identifiers for the algorithm the key is used for and
information on the entity the key is associated with.
The original DNSSEC specification allowed other protocols and
applications to use the KEY record as a general-purpose mechanism to
store public keys. For reasons documented in [10], the KEY record is
now restricted for use with DNSSEC only. Work is in progress on
storing public keys [14] and certificates [15] used by other
protocols and applications in the DNS. A secure DNS tree could then
be used as a lightweight trust mechanism. Some administrators and
users may consider a validated DNSSEC signature to be sufficient to
Arends, et al. Expires January 21, 2003 [Page 6]
Internet-Draft DNSSEC Intro. and Requirements July 2002
trust a public key stored in the DNS.
3.3 Transaction Security
The data origin authentication and data integrity service described
above authenticates retrieved RRsets and the non-existence of RRsets,
but provides no protection for complete DNS messages, e.g., when they
occur in zone transfers and dynamic updates.
A DNS message can be authenticated by including a special signature
RR at the end of the message, either a transaction signature (TSIG)
[11] or SIG record with a type covered field of zero (a "SIG(0)", see
[12]). Such a signature can be used to verify the integrity of the
DNS message. (The signature record in the additional section of a
query may produce an error or simply be ignored by older DNS
implementations that don't support transaction security.) Unlike the
mechanism described in Section 3.1, transaction security is specific
to the individual hosts exchanging DNS messages. The cryptographic
keys used with transaction security are associated with individual
hosts and not DNS zones.
In addition to transaction signatures, there is also support for key
agreement protocols to support transaction security using symmetric
encryption keys. This service uses the transaction key (TKEY) [13]
resource record. The use of the TKEY record in a key agreement
transaction depends on the algorithm used, and each key agreement
protocol is described in a separate document specific to each
algorithm.
Arends, et al. Expires January 21, 2003 [Page 7]
Internet-Draft DNSSEC Intro. and Requirements July 2002
4. Services Not Provided by DNS Security
The DNS design philosophy calls for all DNS data to be public and
uniform answers to all inquirers. Accordingly, confidentiality for
queries or responses is not provided, nor are any sort of access
control lists or other means to differentiate inquirers.
Denial of service is not protected against.
Signed zone data and/or the use of transaction signatures will not
protect against errors in DNS zone information or servers incorrectly
interpreting and/or setting DNS message header fields.
Arends, et al. Expires January 21, 2003 [Page 8]
Internet-Draft DNSSEC Intro. and Requirements July 2002
5. Resolver Considerations
A security-aware resolver needs to be able to perform necessary
cryptographic functions to verify digital signatures using at least
the mandatory-to-implement algorithms. Also, security-aware
resolvers must be capable of forming a chain of trust from a newly
learned zone back to a trusted key. This might require additional
queries to intermediate DNS zones for necessary KEY, DS and SIG
records. It is assumed that a security-aware resolver will be
configured with at least one trusted key to aid this process.
The stub resolver found in many hosts may be augmented to provide a
different set of security features instead of the full security
awareness found in a complete resolver. The use of transaction
security could help secure the final message passing between a
recursive DNS server and a stub resolver. This a matter of local
security policy.
A security-aware resolver needs to communicate with only security-
aware servers. If an unsecure server or an unsigned/unsecure zone is
part of the DNS resolution path, the resolver cannot ensure security.
If a security-aware resolver must rely on an unsecure server (or
unsigned zone), the resolver cannot verify DNS responses and should
rely on local policy when trusting responses.
Arends, et al. Expires January 21, 2003 [Page 9]
Internet-Draft DNSSEC Intro. and Requirements July 2002
6. Zone Considerations
A secure zone will have several differences from an unsigned zone. A
secure zone will contain additional security-related records (SIG,
KEY, DS and NXT records). SIG and NXT records may be generated by a
signing process prior to serving the zone. If SIG and NXT records
are not present in the zone, an authoritative server needs to
generate them before serving the zone. Zone data is only valid and
considered secure for a definable time period. The SIG records that
accompany zone data have defined inception and expiration times.
These times establish a validity period for the signatures and the
zone data the signatures cover.
Arends, et al. Expires January 21, 2003 [Page 10]
Internet-Draft DNSSEC Intro. and Requirements July 2002
7. Server Considerations
A security-aware server must be capable of performing the following
operations in addition to the normal operations of a DNS server
described in [3]:
A security-aware server should make all attempts to include
necessary security-related records (SIG, KEY, DS and NXT) in
responses as DNS message space permits.
A security-aware caching server must also take a signature's
validation period into consideration when determining the time to
live (TTL) of cached data: signed data should not be cached beyond
the signature validity period.
A security-aware server should have a means of employing
transaction security, such as transaction signatures (TSIG) or
SIG(0). Transaction security is primarily used when performing
other DNS operations such as zone transfers and dynamic updates
(if they are permitted according to the server's local policy).
All other means of restricting query, zone transfer, dynamic
update and administrative access to a security-aware server fall
under the category of operational security and are not addressed
by the DNS security extensions.
Arends, et al. Expires January 21, 2003 [Page 11]
Internet-Draft DNSSEC Intro. and Requirements July 2002
8. DNS Security Document Family
The DNSSEC set of documents can be partitioned into five main groups
as depicted in Figure 1. All these documents are in turn under the
larger umbrella of the DNS base protocol documents described in [16].
8.1 DNS Security Document Roadmap
---------------------------------------------------------------------
+--------------------------------+
| |
| Base DNS Protocol Docs |
| [RFC1035, RFC2181, etc.] |
| |
+--------------------------------+
|
|
+-----------+ +-------------+
| DNSSEC | | New |
| Protocol |<-------->| Security |
| Documents | | Uses |
+-----------+ +-------------+
|
|
+------------------------------+
| |
| |
+------------+ +---------------+
| Dig. Sig. | | |
| Algorithm | | Transaction |
| Impl. | | Impl. |
| | | |
+------------+ +---------------+
Figure 1: DNSSEC Document Roadmap
---------------------------------------------------------------------
8.2 Categories of DNS Security Documents
The "DNSSEC protocol document set" refers to the three documents that
form the core of the DNS security extensions:
1. DNS Security Introduction and Requirements (this document)
Arends, et al. Expires January 21, 2003 [Page 12]
Internet-Draft DNSSEC Intro. and Requirements July 2002
2. Resource Records for DNS Security Extensions [9]
3. Protocol Modifications for the DNS Security Extensions (not yet
published) [12]
The "Dig. Sig. Algorithm Impl." document set refers to the group of
documents that describe how a specific digital signature algorithm is
implemented to fit the DNSSEC resource record format. Each of these
documents deals with a specific digital signature algorithm.
The "Transaction Impl." document set refers to the group of documents
that deal with DNS message transaction security, including secret key
establishment and verification.
The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security
related purposes. Documents that fall in this category include the
use of DNS in the storage and distribution of certificates [15] and
individual user public keys (PGP, e-mail, etc.) [14].
Arends, et al. Expires January 21, 2003 [Page 13]
Internet-Draft DNSSEC Intro. and Requirements July 2002
9. IANA Considerations
This document introduces no new IANA considerations.
Arends, et al. Expires January 21, 2003 [Page 14]
Internet-Draft DNSSEC Intro. and Requirements July 2002
10. Security Considerations
This document introduces the DNS security extensions and describes
the document set that contains the new security records and DNS
protocol modifications. The capabilities and limitations of these
extensions are discussed. The extensions provide data origin
authentication and data integrity using digital signatures over
resource records and (optionally) DNS messages.
In order for a secure resolver to validate a DNS response, all the
intermediate zones and servers must be capable of DNS security
processing. A security-aware resolver cannot verify responses sent
by an non-security-aware server.
The DNS security extensions do not protect against denial of service
(DoS) attacks or provide confidentiality.
Arends, et al. Expires January 21, 2003 [Page 15]
Internet-Draft DNSSEC Intro. and Requirements July 2002
11. Acknowledgements
This document was created from the input and ideas of several members
of the DNS Extensions Working Group. The authors would like to
acknowledge (in alphabetical order) the following people for their
contributions and comments on this document:
Derek Atkins
Rob Austein
Donald Eastlake
Miek Gieben
Olafur Gudmundsson
Olaf Kolkman
Ed Lewis
Ted Lindgreen
Bill Manning
Brian Wellington
Arends, et al. Expires January 21, 2003 [Page 16]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[3] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[4] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[5] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
System", draft-ietf-dnsext-dns-threats-01 (work in progress),
February 2002.
[6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
[7] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.
[8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
December 2001.
[9] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-
records-00 (work in progress), March 2002.
[10] 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.
[11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[12] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
Modifications for the DNS Security Extensions (Not yet
published)", draft-ietf-dnsext-dnssec-protocol-00 (work in
progress), to be published in 2002.
[13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.
Arends, et al. Expires January 21, 2003 [Page 17]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Informative References
[14] Schlyter, J., "Storing application public keys in the DNS",
draft-schlyter-appkey-02 (work in progress), February 2002.
[15] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999.
[16] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext-
dnssec-roadmap-05 (work in progress), November 2001.
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 January 21, 2003 [Page 18]
Internet-Draft DNSSEC Intro. and Requirements July 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 January 21, 2003 [Page 19]
