WDIFF

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

DNS Extensions R. Arends
Internet-Draft Telematica Instituut
Expires: June 1, August 15, 2003 R. Austein
ISC
M. Larson
VeriSign
D. Massey
USC/ISI
S. Rose
NIST
December 2002
February 14, 2003

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

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

Abstract

The Domain Name System Security Extensions (DNSSEC) provide add data origin
authentication and data integrity. integrity to the Domain Name System. This
document introduces these extensions extensions, and describes their
capabilities and limitations.
The This document also discusses the

Arends, et al. Expires August 15, 2003 [Page 1]

Internet-Draft DNSSEC Introduction and Requirements February 2003

services that the DNS security extensions provide do and do not provide
are discussed. Lastly, provide.
Last, this document describes the interrelationships between the
group of documents that collectively describe the DNS
security extensions and their interrelationships is discussed.

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

Internet-Draft DNSSEC Intro. and Requirements December 2002 DNSSEC.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
3. Services Provided by DNS Security . . . . . . . . . . . . . . 5 6
3.1 Data Origin Authentication and Data Integrity . . . . . . . . 5 6
3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 6 7
4. Services Not Provided by DNS Security . . . . . . . . . . . . 7 9
5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 8 10
6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 11
7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1 12
7.1 TTL values vs. SIG validity period . . . . . . . . . . . . . . 10
6.2 12
7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . . . . . . 10
7. 12
8. Name Server Considerations . . . . . . . . . . . . . . . . . . . . 11
8. 13
9. DNS Security Document Family . . . . . . . . . . . . . . . . . 12
8.1 14
9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 12
8.2 14
9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 12
9. 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 19
Normative References . . . . . . . . . . . . . . . . . . . . . 17 20
Informative References . . . . . . . . . . . . . . . . . . . . 18 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 23

Arends, et al. Expires June 1, August 15, 2003 [Page 2]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002 February 2003

1. Introduction

This document introduces the Domain Name System Security Extensions
(DNSSEC). This document and a collection of related documents update
RFC 2535 [3] and its related two companion documents to further clarify ([13] and
[14]) update, clarify, and refine the security extensions originally
defined in RFC 2535. 2535 [3]. These security extensions consist of a set
of new resource record types and modifications to the existing DNS
protocol [2]. The new records and protocol modifications are not
fully described in this document, but are described in a family of
documents outlined in Section 8. The 9. Section 3 and Section 4 describe
the capabilities and limitations of the security extensions are described in
greater
detail in detail. Section 3 5, Section 6, Section 7, and Section 4, respectively.

These three documents update/obsolete RFC's: 2525, 8
discuss the effect that these security extensions will have on
resolvers, stub resolvers, zones and name servers.

This document and its two companions update and obsolete RFCs 2535,
3008, 3090, 3225, 3226, 3445 and Internet Drafts: 3445, as well as several works in
progress: "Redefinition of the AD bit", "Delegation Signer Resource
Record", and "DNSSEC Opt-In". See [18] for more details of on 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 for DNS data, as well as a means of public key
distribution. The security These extensions do not provide protection against
other types of attack, nor do they provide confidentiality.

Arends, et al. Expires June 1, August 15, 2003 [Page 3]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002 February 2003

2. Definitions of Important DNSSEC Terms

authentication key: A public key, for chain: In the DNSSEC model, 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
key by the DNS.

authentication chain: In DNSSEC, a key KEY RR signs a DS record, RR,
which
points to hashes one RR in another key (or key signing key), KEY RRset, which in turn signs
another DS record, RR, which points to hashes one RR in yet another key, etc.
Eventually ending KEY RRset, and
so forth, finally ending, if all goes well, with a key that has generated a SIG over a KEY RR
set. which
signs whatever DNS data the end user was looking for in the first
place. This alternating succession of KEY RRsets and DS records RRs forms
a chain of signed data, with each link in the chain vouching for
the next. A resolver starting at If a piece of data signature somewhere in the this chain signed has been
generated by a known an authentication key known to a security-aware
resolver, then the resolver can attempt to verify all subsequent
signatures. Thus all subsequent data in and authenticate
the signed chain is verified and
authenticated.

security-aware resolver: A resolver (defined in section 2.4 of [1]) KEY and DS RRs from that understands point down to the DNS security extensions defined in this
document set. In particular,
target data.

authentication key: A public key which a security-aware resolver uses known
authentication keys to verify signatures over RRsets
trusts and
(optionally) can therefore use to verify data. A security-aware
resolver can discover trusted authentication keys in three ways.
First, the resolver is generally preconfigured to know about at
least one key which it should trust. Second, the resolver may be
able to discover both a new key and an associated DS RR which
contains a valid hash of the new key and which has been signed by
a key which the resolver trusts. Third, the resolver may be able
to determine that a new key has been signed by another key which
the resolver trusts. Note that the resolver must always be guided
by local policy when deciding whether to trust a new key, even if
the local policy is simply to trust any new key for which the
resolver is able verify the signature.

key signing key: An authentication key which is used to sign one or
more other authentication keys. Typically, a key signing key will
sign a zone signing key, which in turn will sign other zone data.
Local policy may require the zone signing key to be changed
frequently, while the key signing key may have a longer validity
period in order to provide a more stable secure entry point into
the zone. Designating an authentication key as a key signing key
is purely an operational issue: DNSSEC itself does not distinguish
between key signing keys and other DNSSEC authentication keys.
Key signing keys are discussed in more detail in [12].

security-aware name server: An entity acting in the role of a name
server (defined in section 2.4 of [1]) which understands the DNS messages.
security extensions defined in this document set. In particular,
a security-aware name server is an entity which receives DNS
queries, sends DNS responses, supports the EDNS0 [4] message size
extension and the DO bit [8], and supports the RR types and
message header bits defined in this document set.

Arends, et al. Expires August 15, 2003 [Page 4]

Internet-Draft DNSSEC Introduction and Requirements February 2003

security-aware recursive name server: An entity which acts in both
the security-aware name server and security-aware resolver roles.
A more cumbersome equivalent phrase would be "a security-aware
name server (also defined which offers recursive service".

security-aware resolver: An entity acting in the role of a resolver
(defined in section 2.4 of [1]) that which understands the DNS security extensions.
extensions defined in this document set. In particular,
it supports the KEY, SIG, DS and NXT record types, a larger
security-aware resolver is an entity which sends DNS queries,
receives DNS responses, supports the EDNS0 [4] message size via EDNS0,
extension and other protocol changes such as support
for the OK bit. Also called a "secure server".

unsecure server: The proper term for DO bit [8], and is capable of using the opposite RR types
and message header bits defined in this document set to provide
DNSSEC services.

security-aware stub resolver: An entity acting in the role of a
resolver (defined in section 2.4 of [1]) which has at least a
minimal understanding the DNS security extensions defined in this
document set, but which trusts one or more security-aware
server.
recursive name servers to perform most of the tasks discussed in
this document set on its behalf. In particular, a security-aware
stub resolver is an entity which sends DNS queries, receives DNS
responses, and is capable of establishing an appropriately secured
channel to a security-aware recursive name server which will
provide these services on behalf of the security-aware stub
resolver. Note that the distinction between security-aware
resolvers and security-aware stub resolvers is different from the
distinction between iterative-mode and recursive-mode resolvers in
the base DNS specification: a particular security-aware resolver
may operate exclusively in recursive mode, but still performs its
own DNSSEC signature validity checks, while a security-aware stub
resolver does not, by definition.

security-oblivious: The opposite of "security-aware".

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 "signed zone".

zone signing key: An authentication key which is used to sign a zone.
See key signing key, above. Typically a zone signing key will be
part of the same KEY RRset as the key signing key which signs it,
but is used for a slightly different purpose and may differ from
the key signing key in other ways, such as validity lifetime.

Arends, et al. Expires June 1, August 15, 2003 [Page 4] 5]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002 February 2003

3. Services Provided by DNS Security

The Domain Name System (DNS) protocol security extensions provide
data origin
authentication and data integrity assurance. In
addition, a means of providing an assurance services for DNS data,
including mechanisms for authenticated denial of existence
is provided, as of DNS
data. These mechanisms are described below.

These mechanisms require minor changes to the DNS protocol. DNSSEC
adds four new resource record types (SIG, KEY, DS and NXT) and two
new message header bits (CD and AD). In order to support the larger
DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
requires EDNS0 support [4]. Finally, DNSSEC requires support for the
DO bit [8], so that a security-aware resolver can indicate in its
queries that it wishes to receive DNSSEC RRs in response messages.

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

3.1 Data Origin Authentication and Data Integrity

Authentication is provided

DNSSEC provides authentication by associating 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., possible: for example, there may be keys
for each of several 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 name servers
(although hosts/services can (public
keys for DNS transaction authentication mechanisms may also have key pairs in DNSSEC; see the
reference to SIG(0) appear in [7] ). Security-aware servers attempt to send
the signature(s) needed to authenticate an RRset
zones, as described in the DNS reply
message along with the RRset itself, provided there [7], but DNSSEC itself is space
available in the message. concerned with
object security of DNS data, not channel security of DNS
transactions).

A security-aware resolver could can learn a zone's public key either by
having the key
statically configured preconfigured into the resolver or by normal DNS
resolution. To allow the latter, public keys are stored in a new
type of resource record, the KEY
record. RR. Note that the private keys used
to sign zone data must be kept secure secure, and best practices call for them to should be stored offline. offline
when practical to do so. To reliably discover a public key by reliably via DNS
resolution, the target key itself needs to be signed by either a statically configured
preconfigured authentication key or another key that has been previously authenticated. Zone
information is
authenticated previously. Security-aware resolvers authenticate zone
information by forming a an authentication chain from a newly learned
public key back to a previously known authentication public key
(which is key,
which in turn either statically configured must have been preconfigured into the resolver
or previously must have been learned and
verified). verified previously. Therefore, the

Arends, et al. Expires August 15, 2003 [Page 6]

Internet-Draft DNSSEC Introduction and Requirements February 2003

resolver must be configured with at least one public key: if the
preconfigured key (either is a zone signing key or key signing key) that
authenticates one zone (or zone key, in then it will authenticate
the associated zone; if the case of preconfigured key is a key signing
key) as key,
it will authenticate a starting point. zone signing key. To help security-aware
resolvers establish this authentication chain, security-aware name
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

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

Internet-Draft DNSSEC Intro. and Requirements December 2002
extensions proceeded from signed KEY record to signed KEY record, as
necessary, and finally to the queried RRset. A The current
specification adds a new record, Delegation Signer (DS) RR type to simplify
some of the
delegation signer (DS), has been added for additional flexibility. administrative tasks involved in signing delegations
across organizational boundaries. The DS RRset resides at a
delegation point in a parent zone and
specifies indicates the key or keys used
by the specified delegated child zone to self-sign the KEY RRset at its the child
zone's apex. The child, child zone, in turn, uses one or more of these the keys
in this KEY RRset to sign its zone data. The authentication chain is
therefore DS->KEY-
>[DS->KEY->...]->RRset. KEY->[DS->KEY]*->RRset, where "*" denotes zero or more DS-
>KEY subchains.

This authentication chain is normally constructed "top down" (i.e. from the root "." of
the DNS hierarchy down to the leaf zones). However, this zones, and is base DNSSEC
protocol only. Local policy normally based on authentication
preconfigured knowledge of RR sets the public key for the root. Local
policy, however, may
override this policy. Ultimately, authentication is also allow a matter security-aware resolver to trust
one or more preconfigured keys other than the root key, or may not
provide preconfigured knowledge of
local, the root key, or may even prevent
the resolver policy from trusting particular keys for arbitrary reasons even
if those keys are properly signed with verifiable signatures. DNSSEC
provides mechanisms by which a security-aware resolver can determine
whether an RRset's signature is "valid" within the meaning of DNSSEC,
but authentication and trust, in the final analysis, are matters of
local policy, which may extend, 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. Four new resource record
types are required: SIG, KEY, DS and NXT. EDNS0 support [4] for
larger message sizes [9] is required, as is support for the OK bit
[8]. 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 described 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, record type, the non-
existence (NXT) NXT record.
The NXT record allows a security-aware resolver to authenticate a
negative reply
(either for either name or type non-existence) to be authenticated or type non-existence via the same
way as
mechanisms used to authenticate other DNS replies. Use of NXT
records require a canonical representation and order ordering for domain
names in zones. Chains of NXT records
exist to cover explicitly describe the gaps,
or "empty space", between domain names in a zone, as well as non-existent record listing

Arends, et al. Expires August 15, 2003 [Page 7]

Internet-Draft DNSSEC Introduction and Requirements February 2003

the types for of RRsets present at existing names. Each NXT record is
signed and authenticated in using the same way as any other
RRset. mechanisms described in Section
3.1.

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

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002 February 2003

4. Services Not Provided by DNS Security

The

DNS design philosophy calls for all was originally designed with the assumptions that the DNS data will
return the same answer to be public any given query regardless of who may have
issued the query, and
uniform answers to that all inquirers. data in the DNS is thus visible.
Accordingly, confidentiality for
queries or responses DNSSEC is not provided, nor are any sort of designed to provide confidentiality,
access control lists lists, or other means to differentiate of differentiating between
inquirers.

There is

DNSSEC provides no protection against denial of service attacks. Security-
aware
Security-aware resolvers and security-aware name servers are
vulnerable to another an additional class of DoS denial of service attacks based
on cryptographic operations. See the Security
Considerations section below. Please see Section 11 for details.

The DNSSEC DNS security extensions provide data and origin authentication of
for DNS data. No The mechanisms outlined above extend no protection is extended to
operations such as zone transfers and dynamic update [16]. Message
authentication schemes described in [5] and [7] address security
operations that pertain to these transactions.

Signed zone data and/or the use 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 correctness of DNS
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 June 1, August 15, 2003 [Page 7] 9]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002 February 2003

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. Security-aware resolvers must
also be capable of forming a authentication chain from a newly
learned zone back to a authentication key (as defined above). key, as described above. This
process might require additional queries of to intermediate DNS zones
for to
obtain necessary KEY, DS and SIG records. It is assumed that a A security-aware resolver will
should be configured with at least one authentication key as the
starting point from which it will attempt to establish an authentication chain.

The stub
chains.

If a security-aware resolver is separated from the relevant
authoritative name servers by a recursive name server or by any sort
of device which acts as a proxy for DNS, and if the recursive name
server or proxy is not security-aware, the security-aware resolver found in many hosts
may not be augmented able to provide a
different set of security features instead of the full security
awareness found operate in a security-aware resolver. The use of transaction
authentication (i.e. SIG(0) or TSIG) could help secure the final
message passing between mode. For example, if a
security-aware DNS server and a stub
resolver. This resolver's packets are routed through a matter of local security policy. Note network
address translation device that
transaction authentication changes the includes a DNS protocol. Using SIG(0) proxy which is not
security-aware the security-aware resolver may find it difficult or
TSIG keys means that
impossible to obtain or validate signed DNS clients now can have identity and are no
longer anonymous. Possession of data.

If a key used for transaction
authentication could allow security-aware resolver must rely on an unsigned zone or a security aware name
server to identify a that is not security aware, the resolver may not be able to
validate DNS responses, and segregate resolvers it accepts queries from. will need a local policy on whether to
accept unverified responses.

A security aware stub security-aware resolver ought to be configured should take a signature's validation period
into consideration when determining the TTL of data in its cache, to make use
avoid caching signed data beyond the validity period of the
signature, but should also allow for the possibility that the
security-aware resolver's own clock is wrong. Thus, a security aware full security-aware
resolver (e.g. which is part of a security-aware
caching server) and recursive name server will
need to communicate with it using some form pay careful attention to the DNSSEC "checking disabled" (CD)
bit [13] in order to avoid blocking valid signatures from getting
through to other security-aware resolvers which are clients of
integrity protection for this
recursive name server and which are capable of performing their own
DNSSEC validity checks.

Arends, et al. Expires August 15, 2003 [Page 10]

Internet-Draft DNSSEC Introduction and Requirements February 2003

6. Stub Resolver Considerations

Although not strictly required to do so by the protocol, most DNS
queries and responses. Examples of
integrity protection originate from stub resolvers. Stub resolvers, by
definition, are transaction authentication schemes as
defined in minimal DNS resolvers which use recursive query mode
to offload most of the context work of DNS and/or IPsec resolution to protect all traffic
from a recursive name
server. Given the widespread use of stub resolver's host resolvers, the DNSSEC
architecture has to take stub resolvers into account, but the host of a
security aware full
resolver.

If features needed in a security aware full stub resolver is configured to forward queries to
another differ in some respects
from those needed in a full resolver, security-aware resolver.

Even an unaugmented stub resolver may get some benefit from DNSSEC if
the latter is recommended to be security aware
also. If not, recursive name servers it uses are security-aware, but for the security aware
stub resolver might not be able to
obtain place any real reliance on DNSSEC services, the data needed to make a security determination. A security
aware stub
resolver ought to be capable of contacting must trust both the authoritative recursive name servers directly, but do so with in question and
the consideration communication channels between itself and those name servers.
The first of performance
impacts.

If a security aware resolver these issues is separated from authoritative servers
by a caching local policy issue: in essence, a stub
resolver has no real choice but to place itself at the mercy of the
recursive name servers that is not security aware, it is possible that
the security aware resolver will only be able to operate in an
insecure mode. For example, if a uses, since it does not perform DNSSEC
validity checks on its own. The second issue requires some kind of
channel security aware resolver's packets
are routed through a device (such mechanism; proper use of DNS transaction
authentication mechanisms such as a Network Address Translator)
that acts SIG(0) or TSIG would suffice, as a DNS proxy
would appropriate use of IPsec, and particular implementations may
have other choices available, such as operating system specific
interprocess communication mechanisms. Confidentiality is not needed
for this channel, but data integrity and message authentication are.

{{AD bit currently ratholed, update this when its fate is not security aware, settled}}

There is one more step which a security-aware stub resolver can take
if, for whatever reason, it might not be
possible to 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 able 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 establish a useful trust
relationship with the authentication
chain recursive name servers which it uses: it can
perform its own signature validation, by setting the client resolver.

If an unsecure server or an unsigned zone results in a break Checking
Disabled (CD) bit in the
authentication chain, its query messages. Upon taking this step, the
resolver cannot ensure security. If is no longer really a
security-aware stub resolver must rely on an unsecure server (or unsigned
zone) that cannot supply the necessary security RRs, at all anymore (in the resolver
cannot verify DNS responses
terminology used in this document set, anyway), and should rely on local policy when
accepting responses. is now a
security-aware resolver with somewhat limited functionality.

Arends, et al. Expires June 1, August 15, 2003 [Page 9] 11]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002

6. February 2003

7. Zone Considerations

A secure zone will have

There are several differences from an between signed and unsigned zone. zones. A
secure
signed 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. 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 times,
which establish a validity period for the signatures and the zone
data the signatures cover.

6.1

7.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 by the SIG RR covering an
that RRset. DNSSEC does not change the definition or function of the
TTL value, which is intended to maintain database coherency in caches: stale
caches. A caching resolver purges RRsets
are purged from caches after its cache no later
than the period end of the time defined in period specified by the TTL
field. fields of those
RRsets, regardless of whether or not the resolver is security-aware.

The inception and expiration fields in the SIG RR [12], [13], on the other
hand, specify the time period when during which the signature can be used
to validate its covering RRset. Zone the RRset that it covers. The signatures associated with
signed zone data is are only (cryptographically) valid and secure (pending verification of the signature) for a
specific the time period and specified by
these fields establish the time period that
a given signature covers in the RRset. The SIG RRs in question. TTL value should not be used
to artificially values cannot extend
the validity period of signed RR sets RRsets in a resolver's cache, but the
resolver may use the time remaining before expiration of the
signature validity period may decrease of a signed RRset as an upper bound for the
TTL of the signed RRsets RRset and its associated SIG RR in a the resolver's
cache.

6.2

7.2 New Temporal Dependency Issues for Zones

With the addition of the security extensions,

Information in a signed zone information now has a temporal factor that dependency which did not previously
exist in the original 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 as a whole. A signed zone requires regular
maintenance to ensure that each RRset in the zone has a temporally current valid
SIG RR. This might also require The signature validity period of a SIG RR is a "zone load" interval
during which will the signature for one particular signed RRset can be defined
as an increase
considered valid, and the signatures of different RRsets in a zone
may expire at different times. Re-signing one or more RRsets in a
zone will change one or more SIG RRs, which in turn will require
incrementing the zone's SOA serial number, indicating number to indicate that a zone
change has occurred and re-signing the SOA RRset itself. Thus, re-
signing any RRset in a zone may cause also trigger DNS NOTIFY messages and
zone transfers to take place (IXFR or AXFR). operations.

Arends, et al. Expires June 1, August 15, 2003 [Page 10] 12]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002

7. February 2003

8. Name 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 [2]:

A security-aware name server should make all attempts to include
necessary security-related the appropriate DNSSEC
records (SIG, KEY, DS and NXT) in all responses as DNS to queries from
resolvers which have signaled their willingness to receive such
records via use of the DO bit in the EDNS header, subject to message space permits.

A caching (i.e. recursive)
size limitations. For this reason a security-aware name server should also take
a signature's validation period into consideration when
determining must
support the time EDNS mechanism size extension, since otherwise inclusion
of DNSSEC RRs could easily cause UDP message truncation and fallback
to live (TTL) TCP.

If possible, the private half of cached data: signed data each DNSSEC key pair should be kept
offline, but this will not be cached beyond the signature validity period.

All means of restricting query, possible for a zone transfer, for which DNS
dynamic update and
administrative access to an authoritative security-aware has been enabled. In the dynamic update case, the
primary master server
fall under for the category zone will have to re-sign the zone when
updated, so the private half of operational security and are not
addressed by the DNS security extensions. Such issues fall under zone signing key will have to be
kept online. This is an example of a situation where the need for transaction security (see [5] ability to
separate the zone's KEY RRset into zone signing key(s) and [7] ). key
signing key(s) may be useful, since the key singing key(s) in such a
case can still be kept offline.

DNSSEC, by itself, is not enough to protect the integrity of an
entire zone during zone transfer operations, since even a signed zone
contains some unsigned data, so zone maintenance operations will
require some additional mechanisms (most likely some form of channel
security, such as TSIG, SIG(0), or IPsec).

Arends, et al. Expires June 1, August 15, 2003 [Page 11] 13]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002

8. February 2003

9. 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 [18].

8.1

9.1 DNS Security Document Roadmap

---------------------------------------------------------------------

+--------------------------------+
| |

+----------------------------------+
| Base DNS Protocol Docs Documents |
| [RFC1035, RFC2181, etc.] |
| et sequentia] |
+--------------------------------+
+----------------------------------+
|
|
+-----------+ +-------------+ +----------+
| DNSSEC | | New |
| Protocol |--------->| Security |
| Documents | | Uses |
+-----------+ +-------------+ +----------+
|
|
+---------------- - - - - - - -+
| .
| .
+------------+ +---------------+
| Dig. Sig. |
+------------------+ .
| Digital | +------------------+
| Algorithm Signature | | Transaction |
| Impl. Algorithm | | Impl. Authentication |
| Implementations | | Implementations |
+------------+ +---------------+
+------------------+ +------------------+

Figure 1: DNSSEC Document Roadmap

---------------------------------------------------------------------

8.2

9.2 Categories of DNS Security Documents

The "DNSSEC protocol document set" refers to the three documents that
which form the core of the DNS security extensions:

1. DNS Security Introduction and Requirements (this document)

2. Resource Records for DNS Security Extensions [13]

Arends, et al. Expires June 1, August 15, 2003 [Page 12] 14]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002

2. Resource Records for DNS Security Extensions [12] February 2003

3. Protocol Modifications for the DNS Security Extensions [13] [14]

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

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 but 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.) and so forth) [17].

Arends, et al. Expires June 1, August 15, 2003 [Page 13] 15]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002

9. February 2003

10. IANA Considerations

This document introduces no new IANA considerations.

Arends, et al. Expires June 1, August 15, 2003 [Page 14] 16]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002

10. February 2003

11. 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 This document discusses the capabilities and
limitations of these
extensions are discussed. extensions. The extensions provide data origin
authentication and data integrity using digital signatures over
resource record sets.

In order for a secure security-aware resolver to validate a DNS response,
all of the intermediate zones and servers must be capable signed, and all of DNS security
processing the
intermediate name servers must be security-aware, as defined in this
document set. A security-aware resolver cannot verify responses
originating from an unsigned zone or zone, from a zone not served by a non-security-aware server.
security-aware name server, or for any DNS data which the resolver is
only able to obtain through a recursive name server which is not
security-aware. If there is a break in the authentication chain (i.e., no such
that a security-aware resolver cannot obtain and validate the
authentication key can be
obtained), keys it needs, then a security aware the security-aware resolver cannot verify those
validate the affected DNS
responses. Other data.

This document briefly discusses other methods of adding security to a
DNS query query, such as using a secure channel (e.g. IPSec tunnel, etc.) secured by IPsec or using a DNS
transaction authentication over DNS messages are mechanism, but transaction security is not discussed in
part of DNSSEC per se.

A security-aware stub resolver, by definition, does not perform
DNSSEC signature validation on its own, and thus is vulnerable both
to attacks on (and by) the security-aware recursive name servers
which perform these documents. Local checks on its behalf and also to attacks on its
communication with those security-aware recursive name servers.
Security-aware stub resolvers should use some form of channel
security policy may extend or override to defend against the
protocol modifications described in this document set. latter threat. The DNS security extensions do only known defense
against the former threat would be for the security-aware stub
resolver to perform its own signature validation, at which point,
again by definition, it would no longer be a security-aware stub
resolver.

DNSSEC does not protect against denial of service
(DoS) attacks. DNSSEC
makes DNS vulnerable to a new class of denial of service attacks
based on cryptographic operations against security-aware resolvers
and security-aware name servers, since an attacker can attempt to use
DNSSEC mechanisms to consume a victim's resources. This class of
attacks takes at least two forms. An attacker may be able to consume
resources in a security-aware resolver's signature validation code by
tampering with SIG RRs in response messages or provide confidentiality. The by constructing
needlessly complex signature chains. An attacker may also be able to
consume resources in a security-aware name server which supports DNS

Arends, et al. Expires August 15, 2003 [Page 17]

Internet-Draft DNSSEC extensions does
open Introduction and Requirements February 2003

dynamic update, by sending a new class of cryptographic based class stream of DoS attacks against
a security-aware resolver or update messages that force the
security-aware server. These attacks
attempt name server to occupy a system's resources with cryptographic operations.

There is now also re-sign some RRsets in the zone more
frequently than would otherwise be necessary.

DNSSEC add the ability for a hostile party to enumerate all the names
in a zone by following the NXT chain. The NXT RR indicates RRs assert which names do
not exist in a zone by linking a from existing name to the next canonical existing name in
along a canonical ordering of all the names within a zone. A resolver Thus, an
attacker can query these NXT RRs in sequence to obtain all the hostnames names
in a zone. While this might not be considered an attack to on the
public DNS, DNS itself, this could allow a mapping of
an attacker to map network hosts or other resources by enumerating
the contents of a zone.

DNSSEC does not provide confidentiality, due to a deliberate design
choice.

DNSSEC does not protect against tampering with unsigned zone data.
Non-authoritative data at zone cuts (glue and NS RRs in the parent
zone) are not signed. Thus, while DNSSEC can provide data origin
authentication and data integrity for RRsets, it cannot do so for
zones, and other mechanisms must be used to protect zone transfer
operations.

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

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002

11. February 2003

12. 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 June 1, August 15, 2003 [Page 16] 19]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002 February 2003

Normative 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] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.

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

[5] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
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] Gudmundsson, O., "DNSSEC and 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 (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),
February 2002.

[12] Kolkman, O. and J. Schlyter, "KEY RR Key Signing Key (KSK)
Flag", draft-ietf-dnsext-keyrr-key-signing-flag-05 (work in
progress), December 2002.

[13] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-
records-02 (work in progress), November 2002.

[13]

[14] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
Modifications for the DNS Security Extensions", draft-ietf-
dnsext-dnssec-protocol-00 (work in progress), October 2002.

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

Arends, et al. Expires June 1, August 15, 2003 [Page 17] 20]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002 February 2003

Informative References

[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-06 (work in progress), November 2001.

Authors' Addresses

Roy Arends
Telematica Instituut
Drienerlolaan 5
7522 NB Enschede
NL

EMail: roy@logmess.com roy.arends@telin.nl

Rob Austein
Internet Software Consortium
40 Gavin Circle
Reading, MA 01867
USA

EMail: sra@isc.org

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

EMail: mlarson@verisign.com

Arends, et al. Expires August 15, 2003 [Page 21]

Internet-Draft DNSSEC Introduction and Requirements February 2003

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 June 1, August 15, 2003 [Page 19] 22]

Internet-Draft DNSSEC Intro. Introduction and Requirements December 2002 February 2003

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 June 1, August 15, 2003 [Page 20] 23]

----