WDIFF

draft-ietf-dnsext-dnssec-intro-03.txt --> draft-ietf-dnsext-dnssec-intro-04.txt

DNS Extensions R. Arends
Internet-Draft Telematica Instituut
Expires: April 24, June 1, 2003 M. Larson
VeriSign
D. Massey
USC/ISI
S. Rose
NIST
October 24,
December 2002

DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-03
draft-ietf-dnsext-dnssec-intro-04

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 24, June 1, 2003.

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 April 24, June 1, 2003 [Page 1]

Internet-Draft DNSSEC Intro. and Requirements October December 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
3.2 Authenticating Name and Type Non-Existence . . . . . . . . . 6
3.2 Key Distribution . . . . . . . . . 6
4. Services Not Provided by DNS Security . . . . . . . . . . . . 7
5. Resolver Considerations . 6
3.3 Transaction Security . . . . . . . . . . . . . . . . . . 8
6. Zone Considerations . . 7
4. Services Not Provided by DNS Security . . . . . . . . . . . 8
5. Resolver Considerations . . . . . . . . 10
6.1 TTL values vs. SIG validity period . . . . . . . . . . 9
6. Zone Considerations . . . . 10
6.2 New Temporal Issues for Zones . . . . . . . . . . . . . . . . 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 . 20

Arends, et al. Expires April 24, June 1, 2003 [Page 2]

Internet-Draft DNSSEC Intro. and Requirements October December 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] [3] 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]. [2]. 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.

These three documents update/obsolete RFC's: 2525, 3008, 3090, 3225,
3226, 3445 and Internet Drafts: "Redefinition of the AD bit",
"Delegation Signer Resource Record", "DNSSEC Opt-In". See [18] for
more details of these documents.

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 April 24, June 1, 2003 [Page 3]

Internet-Draft DNSSEC Intro. and Requirements October December 2002

2. Definitions of Important DNSSEC Terms

authentication 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 in the resolver's initial configuration.
Second, if a new key is referenced by a DS record that is signed
by an already known authentication key, and the signature
verifies, the new key becomes trusted by the resolver.

key signing key: Described in [14] An authentication key that is only
used to sign a DNSSEC authentication key. The zone authentication
key may be changed frequently (according to local policy), while
the key signing key is used as a more static secure entry point
for the zone. Designating a key signing key is an operational
issue only, the key is treated the same way as an authentication path:
key by the DNS.

authentication chain: In DNSSEC, a key signs a DS record, which
points to another key, key (or key signing key), which in turn signs
another DS record, which points to yet another key, etc.
Eventually ending with a key that has generated a SIG over a RR
set. 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 known authentication key can verify all subsequent
signatures. Thus all subsequent data in the chain is verified and
authenticated.

security-aware resolver: A resolver (defined in section 2.4 of [4]) [1])
that understands the DNS security extensions. extensions defined in this
document set. In particular, a security-aware resolver uses known
authentication keys to verify signatures over RRsets and
(optionally) DNS messages.

security-aware server: A name server (also defined in section 2.4 of
[4])
[1]) 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.

signed zone: A zone whose RRsets are signed and which contains
properly constructed KEY, SIG, NXT and (optionally) DS records.

unsigned zone: The proper term for the opposite of a secure zone.

Arends, et al. Expires April 24, June 1, 2003 [Page 4]

Internet-Draft DNSSEC Intro. and Requirements October December 2002

3. Services Provided by DNS Security

The Domain Name System (DNS) protocol security extensions provide
three distinct services: Data
data origin authentication and data
integrity, key distribution, and transaction security, integrity assurance. In
addition, a means of providing an authenticated denial of existence
is provided, as described below.

These services protect against the threats to the Domain Name System
described in [5]. [11].

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 hosts/services can also have key pairs in DNSSEC; see the
reference to SIG(0) in Section 3.3 below). [7] ). 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
record. Note that the private keys used to sign zone data must be
kept secure and best practices call for them to be stored offline.) offline.
To reliably discover a public key by DNS resolution, the key itself
needs to be signed by either a statically configured authentication
key or another key that has been previously authenticated. Zone
information is authenticated by forming a chain from a newly learned
public key back to a previously known authentication public key
(which is either statically configured or previously learned and
verified). Therefore, the resolver must be configured with at least
one public key (either a zone signing key or key signing key) that
authenticates one zone
as a starting point. To establish this (or zone key, in the case of a key signing
key) as a starting point. To establish this authentication chain,
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 authentication chain specified in the original DNS security
extensions proceeded from signed KEY record to signed KEY record, as

Arends, et al. Expires April 24, June 1, 2003 [Page 5]

Internet-Draft DNSSEC Intro. and Requirements October December 2002

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 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 authentication chain is therefore DS->KEY-
>[DS->KEY->...]->RRset.

This authentication chain is normally constructed "top down" (i.e.
from the root "." to the leaf zones). However, this is base DNSSEC
protocol only. Local policy on authentication of RR sets may
override this policy. Ultimately, authentication is a matter of
local, resolver policy which may extend, or even override the
protocol extensions defined in this document set.

Adding data origin authentication and data integrity requires minor
changes to the on-the-wire DNS protocol. Several Four new resource record
types are required, including the aforementioned required: SIG, KEY KEY, DS and DS. NXT. EDNS0 support [6] [4] for
larger message sizes [7] [9] is required, as is support for the OK bit
[8].

3.1.1 EDNS0 support is required for the larger DNS message sizes that
result when DNSSEC RRs are added. Support for the OK bit (part of
EDNS0) is required for a security aware resolver to indicate that it
is security-aware and wishes for DNSSEC RR types to be added to the
response.

3.2 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

Arends, et al. Expires June 1, 2003 [Page 6]

Internet-Draft DNSSEC Intro. and Requirements December 2002

4. Services Not Provided by DNS Security

The KEY resource record is defined to associate public keys with DNS
names. This record permits the design philosophy calls for all DNS data to be used as a public key
distribution mechanism in support of DNSSEC. Security-aware
resolvers can query and
uniform answers to all inquirers. Accordingly, confidentiality for a zone's public key when establishing a
authentication chain.

The syntax
queries or responses is not provided, nor are any sort of the KEY resource record (and the access
control lists or other additional
resource records required for DNSSEC) is described in [9]. It
includes identifiers for the algorithm the key means to differentiate inquirers.

There is used for no protection against denial of service attacks. Security-
aware resolvers and
information on the entity security-aware servers are vulnerable to another
class of DoS based on cryptographic operations. See the key is associated with. Security
Considerations section below.

The original DNSSEC specification allowed other protocols extensions provide data and
applications origin authentication of DNS
data. No protection is extended to use the KEY record operations such as a general-purpose mechanism to
store public keys. For reasons documented zone transfers
and dynamic update [16]. Message authentication schemes described in [10],
[5] and [7] address security operations that pertain to these
transactions.

Signed zone data and/or 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 of transaction authentication will
not protect against errors in DNS zone information or servers
incorrectly interpreting and/or setting DNS message header fields.
The security extensions cannot insure the DNS. A secure correctness of DNS tree could then
information.

Ultimately, final authentication is a matter of local policy. A
local policy might extend or override the protocol extensions defined
in this document set.

Arends, et al. Expires April 24, June 1, 2003 [Page 6] 7]

Internet-Draft DNSSEC Intro. and Requirements October December 2002

5. Resolver Considerations

A security-aware resolver needs to be used as a lightweight key distribution mechanism that could
support other protocols. However, this should not lead able to the
conclusion that the DNS is then safe perform necessary
cryptographic functions to use as a trusted protocol or verify digital signatures using at least
the mandatory-to-implement algorithms. Security-aware resolvers must
also be capable of forming a Public Key Infrastructure. DNSSEC lacks many features found in authentication chain from a
PKI such as newly
learned zone back to a Certificate Revocation List (CRL).

3.3 Transaction Security

The data origin authentication and data integrity service described
above authenticates retrieved RRsets and the non-existence key (as defined above). This
process might require additional queries of RRsets,
but provides no protection for complete intermediate DNS messages, e.g., when they
occur in zone transfers zones
for necessary KEY, DS 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 records. It is assumed that a signature can
security-aware resolver will be used configured with at least one
authentication key to verify the integrity establish an authentication chain.

The stub resolver found in many hosts may be augmented to provide a
different set of security features instead of the
DNS message. (The signature record full security
awareness found in the additional section of a
query may produce an error security-aware resolver. The use of transaction
authentication (i.e. SIG(0) or simply be ignored by older TSIG) could help secure the final
message passing between a security-aware DNS
implementations server and a stub
resolver. This a matter of local security policy. Note that don't support
transaction security.) Unlike the
mechanism described in Section 3.1, transaction security is specific
to authentication changes the individual hosts exchanging DNS messages. The cryptographic protocol. Using SIG(0) or
TSIG keys used with transaction security are associated with individual
hosts and not means that 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 clients now can have identity and are no
longer anonymous. Possession of the TKEY record in a key agreement used for transaction depends on the algorithm used, and each key agreement
protocol is described in
authentication could allow a separate document specific security aware server to each
algorithm.

Arends, et al. Expires April 24, 2003 [Page 7]

Internet-Draft DNSSEC Intro. identify a
resolver and Requirements October 2002

4. Services Not Provided by DNS Security

The DNS design philosophy calls for all DNS data segregate resolvers it accepts queries from.

A security aware stub resolver ought to be public and
uniform answers configured to all inquirers. Accordingly, confidentiality for
queries or responses is not provided, nor are any sort make use of access
control lists or other means
a security aware full resolver (e.g. part of a security-aware
caching server) and to differentiate inquirers.

Denial communicate with it using some form of service is not protected against.

Signed zone data and/or the use
integrity protection for queries and responses. Examples of
integrity protection are transaction signatures will not
protect against errors authentication schemes as
defined in the context of DNS zone information or servers incorrectly
interpreting and/or setting DNS message header fields.

Arends, et al. Expires April 24, 2003 [Page 8]

Internet-Draft DNSSEC Intro. and Requirements October 2002

5. Resolver Considerations

A security-aware IPsec to protect all traffic
from the stub resolver's host to the host of a security aware full
resolver.

If a security aware full resolver needs is configured to forward queries to
another full resolver, the latter is recommended to be security aware
also. If not, the security aware resolver might not be able to perform necessary
cryptographic functions to verify digital signatures using at least
obtain the mandatory-to-implement algorithms. Also, security-aware
resolvers must data needed to make a security determination. A security
aware resolver ought to be capable of forming contacting the authoritative
servers directly, but do so with the consideration of performance
impacts.

If a authentication chain security aware resolver is separated from authoritative servers
by a
newly learned zone back to a trusted authentication key. This might
require additional queries to intermediate DNS zones for necessary
KEY, DS and SIG records. It caching resolver that is not security aware, it is assumed possible that a security-aware
the security aware resolver will only be configured with at least one authentication key able to
aid this process.

The stub resolver found operate in many hosts may be augmented to provide an
insecure mode. For example, if a
different set of security features instead of the full security
awareness found in aware resolver's packets
are routed through a complete resolver. The use of transaction
security could help secure the final message passing between device (such as a Network Address Translator)
that acts as a
recursive DNS server proxy and a stub resolver. This a matter of local is not security policy.

A security-aware resolver needs aware, it might not be
possible to communicate with only security-
aware servers. deliver secured responses. This is because the base DNS

Arends, et al. Expires June 1, 2003 [Page 8]

Internet-Draft DNSSEC Intro. and Requirements December 2002

protocol does not provide means to remotely manage intermediate DNS
caches, hence, it is possible that some data may be 'stuck' or
dropped in the cache and prevent construction of the authentication
chain by the client resolver.

If an unsecure server or an unsigned/unsecure unsigned zone is
part of results in a break in the DNS resolution path,
authentication chain, the resolver cannot ensure security. If a
security-aware resolver must rely on an unsecure server (or unsigned zone),
zone) that cannot supply the necessary security RRs, the resolver
cannot verify DNS responses and should rely on local policy when following
accepting responses.

Arends, et al. Expires April 24, June 1, 2003 [Page 9]

Internet-Draft DNSSEC Intro. and Requirements October December 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 Zone data is only valid
and NXT considered secure for a definable time period. The SIG records
are not present
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.

6.1 TTL values vs. SIG validity period

It is important to note the distinction between an RRset's TTL value
and the signature validity period specified in the zone, SIG RR covering an authoritative server needs
RRset. DNSSEC does not change the definition of the TTL value, which
is intended to maintain database coherency in caches: stale RRsets
are purged from caches after the period of time defined in the TTL
field.

The inception and expiration fields in the SIG RR [12], on the other
hand, specify the time period when the signature can be used to
generate them before serving the zone.
validate its covering RRset. Zone data is only (cryptographically)
valid and
considered secure (pending verification of the signature) for a definable
specific time period. The SIG records that
accompany zone data have defined inception period and expiration times.
These times these fields establish the time period that
a given signature covers the RRset. The TTL value should not be used
to artificially extend the validity period of signed RR sets in a
cache, but the signature validity period may decrease the TTL of
signed RRsets in a cache.

6.2 New Temporal Issues for Zones

With the signatures addition of the security extensions, zone information now
has a temporal factor that did not previously exist in the DNS
protocol. The signature validity period is a time period for which
an RRset can be considered valid, and applies only to the specific
RRset, not to the zone data as a whole. A signed zone requires regular
maintenance to ensure each RRset in the signatures cover. zone has a temporally valid
SIG RR. This might also require a "zone load" which will be defined
as an increase in a SOA serial number, indicating a zone change has
occurred and may cause zone transfers to take place (IXFR or AXFR).

Arends, et al. Expires April 24, June 1, 2003 [Page 10]

Internet-Draft DNSSEC Intro. and Requirements October December 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]: [2]:

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 (i.e. recursive) security-aware server must should 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 an authoritative security-aware server
fall under the category of operational security and are not
addressed by the DNS security extensions. Such issues fall under
the need for transaction security (see [5] and [7] ).

Arends, et al. Expires April 24, June 1, 2003 [Page 11]

Internet-Draft DNSSEC Intro. and Requirements October December 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]. [18].

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 April 24, June 1, 2003 [Page 12]

Internet-Draft DNSSEC Intro. and Requirements October December 2002

2. Resource Records for DNS Security Extensions [9] [12]

3. Protocol Modifications for the DNS Security Extensions (not yet
published) [12] [13]

The "Dig. Sig. Algorithm Impl." document set refers to the group of
documents that describe how a specific digital signature algorithm is algorithms
should be 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 group of documents
that deal with DNS message authentication, including secret key
establishment and verification. While not strictly part of the DNS
Security specification as defined in this set of documents, it should
be included here to note its relationship to the DNS message transaction security, including secret key
establishment and verification. Security
extensions.

The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security
related purposes. The DNSSEC extensions does not provide any direct
security for these new uses, by may be used to support them.
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]. [17].

Arends, et al. Expires April 24, June 1, 2003 [Page 13]

Internet-Draft DNSSEC Intro. and Requirements October December 2002

9. IANA Considerations

This document introduces no new IANA considerations.

Arends, et al. Expires April 24, June 1, 2003 [Page 14]

Internet-Draft DNSSEC Intro. and Requirements October December 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. record sets.

In order for a secure resolver to validate a DNS response, all the
intermediate zones and servers must be capable of DNS security
processing.
processing as defined in this document set. A security-aware
resolver cannot verify responses sent
by originating from an unsigned zone or
a zone served by a non-security-aware server. If there is a break in
the authentication chain (i.e., no authentication key can be
obtained), then a security aware resolver cannot verify those DNS
responses. Other methods of adding security to a DNS query such as
using a secure channel (e.g. IPSec tunnel, etc.) or using
transaction authentication over DNS messages are not discussed in
these documents. Local security policy may extend or override the
protocol modifications described in this document set.

The DNS security extensions do not protect against denial of service
(DoS) attacks or provide confidentiality. The DNSSEC extensions does
open a new class of cryptographic based class of DoS attacks against
a security-aware resolver or security-aware server. These attacks
attempt to occupy a system's resources with cryptographic operations.

There is now also the ability to enumerate all the names in a zone by
following the NXT chain. The NXT RR indicates which names do not
exist in a zone by linking a name to the next canonical name in a
zone. A resolver can query these NXT RRs to obtain all the hostnames
in a zone. While this might not be considered an attack to the
public DNS, this could allow a mapping of network hosts by
enumerating the contents of a zone.

Arends, et al. Expires April 24, June 1, 2003 [Page 15]

Internet-Draft DNSSEC Intro. and Requirements October December 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 April 24, June 1, 2003 [Page 16]

Internet-Draft DNSSEC Intro. and Requirements October December 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 concepts and
specification", facilities", STD
13, RFC 1035, 1034, November 1987.

[4]

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

[5] Atkins, D. and R. Austein, "Threat Analysis Of The Domain 1035, November 1987.

[3] Eastlake, D., "Domain Name
System", draft-ietf-dnsext-dns-threats-01 (work in progress),
February 2002.

[6] System Security Extensions", RFC
2535, March 1999.

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

[7]

[5] Vixie, P., Gudmundsson, O., "DNSSEC Eastlake, D. and IPv6 A6 aware server/resolver
message size requirements", B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC 3226, December 2001.
2845, May 2000.

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

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

[8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
December 2001.

[9] Arends, R., Larson, M., Massey, D. Gudmundsson, O., "DNSSEC and S. Rose, "Resource
Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-
records-00 (work in progress), March 2002. IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.

[10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record", draft-ietf-dnsext-restrict-key-for-dnssec-02
Record (RR)", RFC 3445, December 2002.

[11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
System", draft-ietf-dnsext-dns-threats-02 (work in progress), March
February 2002.

[11] Vixie, P., Gudmundsson, O., Eastlake,

[12] Arends, R., Larson, M., Massey, D. and B. Wellington,
"Secret Key Transaction Authentication S. Rose, "Resource
Records for DNS (TSIG)", RFC
2845, May 2000.

[12] Security Extensions", draft-ietf-dnsext-dnssec-
records-02 (work in progress), November 2002.

[13] 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 Extensions", draft-ietf-
dnsext-dnssec-protocol-00 (work in progress), to be published in October 2002.

[13] Eastlake, D., "Secret

[14] Kolkman, O. and J. Schlyter, "KEY RR Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000. Signing Key (KSK)
Flag", draft-ietf-dnsext-keyrr-key-signing-flag-05 (work in
progress), December 2002.

Arends, et al. Expires April 24, June 1, 2003 [Page 17]

Internet-Draft DNSSEC Intro. and Requirements October December 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] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.

[17] Schlyter, J., "Storing application public keys in the DNS",
draft-schlyter-appkey-02 (work in progress), February 2002.

[18] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext-
dnssec-roadmap-05
dnssec-roadmap-06 (work in progress), November 2001.

Authors' Addresses

Roy Arends
Bankastraat 41-E
1094 EB Amsterdam
Telematica Instituut
Drienerlolaan 5
7522 NB Enschede
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

Arends, et al. Expires June 1, 2003 [Page 18]

Internet-Draft DNSSEC Intro. and Requirements December 2002

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 24, June 1, 2003 [Page 18] 19]

Internet-Draft DNSSEC Intro. and Requirements October December 2002

Full Copyright Statement

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

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

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

Acknowledgement

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

Arends, et al. Expires April 24, June 1, 2003 [Page 19] 20]

----