path: root/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt

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


               DNS Security Introduction and Requirements
                   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 August 15, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The Domain Name System Security Extensions (DNSSEC) add data origin
   authentication and data integrity to the Domain Name System.  This
   document introduces these extensions, and describes their
   capabilities and limitations.  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 do and do not provide.
   Last, this document describes the interrelationships between the
   group of documents that collectively describe DNSSEC.

Table of Contents

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























Arends, et al.           Expires August 15, 2003                [Page 2]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


1. Introduction

   This document introduces the Domain Name System Security Extensions
   (DNSSEC).  This document and its two companion documents ([13] and
   [14]) update, clarify, and refine the security extensions originally
   defined in RFC 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 9.  Section 3 and Section 4 describe
   the capabilities and limitations of the security extensions in
   greater detail.  Section 5, Section 6, Section 7, and Section 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, and 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 on these
   documents.

   The DNS security extensions provide origin authentication and
   integrity protection for DNS data, as well as a means of public key
   distribution.  These extensions do not provide protection against
   other types of attack, nor do they provide confidentiality.


























Arends, et al.           Expires August 15, 2003                [Page 3]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


2. Definitions of Important DNSSEC Terms

   authentication chain: In the DNSSEC model, a KEY RR signs a DS RR,
      which hashes one RR in another KEY RRset, which in turn signs
      another DS RR, which hashes one RR in yet another KEY RRset, and
      so forth, finally ending, if all goes well, with a KEY RR which
      signs whatever DNS data the end user was looking for in the first
      place.  This alternating succession of KEY RRsets and DS RRs forms
      a chain of signed data, with each link in the chain vouching for
      the next.  If a signature somewhere in this chain has been
      generated by an authentication key known to a security-aware
      resolver, then the resolver can attempt to verify and authenticate
      the signed chain of KEY and DS RRs from that point down to the
      target data.

   authentication key: A public key which a security-aware resolver
      trusts and 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
      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 which offers recursive service".

   security-aware resolver: An entity acting in the role of a resolver
      (defined in section 2.4 of [1]) which understands the DNS security
      extensions defined in this document set.  In particular, a
      security-aware resolver is an entity which sends DNS queries,
      receives DNS responses, supports the EDNS0 [4] message size
      extension and the DO bit [8], and is capable of using the 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
      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 opposite of a "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 August 15, 2003                [Page 5]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


3. Services Provided by DNS Security

   The Domain Name System (DNS) security extensions provide origin
   authentication and integrity assurance services for DNS data,
   including mechanisms for authenticated denial of existence 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

   DNSSEC provides authentication by associating cryptographically
   generated digital signatures 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: 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 (public
   keys for DNS transaction authentication mechanisms may also appear in
   zones, as described in [7], but DNSSEC itself is concerned with
   object security of DNS data, not channel security of DNS
   transactions).

   A security-aware resolver can learn a zone's public key either by
   having the key 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 RR.  Note that the private keys used
   to sign zone data must be kept secure, and should be stored offline
   when practical to do so.  To discover a public key reliably via DNS
   resolution, the target key itself needs to be signed by either a
   preconfigured authentication key or another key that has been
   authenticated previously.  Security-aware resolvers authenticate zone
   information by forming an authentication chain from a newly learned
   public key back to a previously known authentication public key,
   which in turn either must have been preconfigured into the resolver
   or must have been learned and 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 is a zone signing key, then it will authenticate
   the associated zone; if the preconfigured key is a key signing key,
   it will authenticate a 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
   extensions proceeded from signed KEY record to signed KEY record, as
   necessary, and finally to the queried RRset.  The current
   specification adds a new Delegation Signer (DS) RR type to simplify
   some of the administrative tasks involved in signing delegations
   across organizational boundaries.  The DS RRset resides at a
   delegation point in a parent zone and indicates the key or keys used
   by the delegated child zone to self-sign the KEY RRset at the child
   zone's apex.  The child zone, in turn, uses one or more of the keys
   in this KEY RRset to sign its zone data.  The authentication chain is
   therefore KEY->[DS->KEY]*->RRset, where "*" denotes zero or more DS-
   >KEY subchains.

   This authentication chain is normally constructed from the root of
   the DNS hierarchy down to the leaf zones, and is normally based on
   preconfigured knowledge of the public key for the root.  Local
   policy, however, may also allow a security-aware resolver to trust
   one or more preconfigured keys other than the root key, or may not
   provide preconfigured knowledge of the root key, or may even prevent
   the resolver 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 or even override the protocol
   extensions defined in this document set.

3.2 Authenticating Name and Type Non-Existence

   The security mechanism 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 type, the NXT record.
   The NXT record allows a security-aware resolver to authenticate a
   negative reply for either name or type non-existence via the same
   mechanisms used to authenticate other DNS replies.  Use of NXT
   records require a canonical representation and ordering for domain
   names in zones.  Chains of NXT records explicitly describe the gaps,
   or "empty space", between domain names in a zone, as well as listing



Arends, et al.           Expires August 15, 2003                [Page 7]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


   the types of RRsets present at existing names.  Each NXT record is
   signed and authenticated using the mechanisms described in Section
   3.1.
















































Arends, et al.           Expires August 15, 2003                [Page 8]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


4. Services Not Provided by DNS Security

   DNS was originally designed with the assumptions that the DNS will
   return the same answer to any given query regardless of who may have
   issued the query, and that all data in the DNS is thus visible.
   Accordingly, DNSSEC is not designed to provide confidentiality,
   access control lists, or other means of differentiating between
   inquirers.

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

   The DNS security extensions provide data and origin authentication
   for DNS data.  The mechanisms outlined above extend no protection 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.
































Arends, et al.           Expires August 15, 2003                [Page 9]

Internet-Draft    DNSSEC Introduction and Requirements     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 described above.  This
   process might require additional queries to intermediate DNS zones to
   obtain necessary KEY, DS and SIG records.  A security-aware resolver
   should be configured with at least one authentication key as the
   starting point from which it will attempt to establish authentication
   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
   may not be able to operate in a secure mode.  For example, if a
   security-aware resolver's packets are routed through a network
   address translation device that includes a DNS proxy which is not
   security-aware the security-aware resolver may find it difficult or
   impossible to obtain or validate signed DNS data.

   If a security-aware resolver must rely on an unsigned zone or a name
   server that is not security aware, the resolver may not be able to
   validate DNS responses, and will need a local policy on whether to
   accept unverified responses.

   A security-aware resolver should take a signature's validation period
   into consideration when determining the TTL of data in its cache, to
   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
   resolver which is part of a security-aware recursive name server will
   need to 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 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 originate from stub resolvers.  Stub resolvers, by
   definition, are minimal DNS resolvers which use recursive query mode
   to offload most of the work of DNS resolution to a recursive name
   server.  Given the widespread use of stub resolvers, the DNSSEC
   architecture has to take stub resolvers into account, but the
   security features needed in a stub resolver differ in some respects
   from those needed in a full security-aware resolver.

   Even an unaugmented stub resolver may get some benefit from DNSSEC if
   the recursive name servers it uses are security-aware, but for the
   stub resolver to place any real reliance on DNSSEC services, the stub
   resolver must trust both the recursive name servers in question and
   the communication channels between itself and those name servers.
   The first of these issues is a 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 it uses, since it does not perform DNSSEC
   validity checks on its own.  The second issue requires some kind of
   channel security mechanism; proper use of DNS transaction
   authentication mechanisms such as SIG(0) or TSIG would suffice, as
   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 settled}}

   There is one more step which a security-aware stub resolver can take
   if, for whatever reason, it is not able to establish a useful trust
   relationship with the recursive name servers which it uses: it can
   perform its own signature validation, by setting the Checking
   Disabled (CD) bit in its query messages.  Upon taking this step, the
   resolver is no longer really a stub resolver at all anymore (in the
   terminology used in this document set, anyway), and is now a
   security-aware resolver with somewhat limited functionality.














Arends, et al.           Expires August 15, 2003               [Page 11]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


7. Zone Considerations

   There are several differences between signed and unsigned zones.  A
   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.  The SIG records that
   accompany zone data have defined inception and expiration times,
   which establish a validity period for the signatures and the zone
   data the signatures cover.

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

   The inception and expiration fields in the SIG RR [13], on the other
   hand, specify the time period during which the signature can be used
   to validate the RRset that it covers.  The signatures associated with
   signed zone data are only valid for the time period specified by
   these fields in the SIG RRs in question.  TTL values cannot extend
   the validity period of signed RRsets in a resolver's cache, but the
   resolver may use the time remaining before expiration of the
   signature validity period of a signed RRset as an upper bound for the
   TTL of the signed RRset and its associated SIG RR in the resolver's
   cache.

7.2 New Temporal Dependency Issues for Zones

   Information in a signed zone has a temporal dependency which did not
   exist in the original DNS protocol.  A signed zone requires regular
   maintenance to ensure that each RRset in the zone has a current valid
   SIG RR.  The signature validity period of a SIG RR is a interval
   during which the signature for one particular signed RRset can be
   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 to indicate that a zone
   change has occurred and re-signing the SOA RRset itself.  Thus, re-
   signing any RRset in a zone may also trigger DNS NOTIFY messages and
   zone transfers operations.






Arends, et al.           Expires August 15, 2003               [Page 12]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


8. Name Server Considerations

   A security-aware name server should include the appropriate DNSSEC
   records (SIG, KEY, DS and NXT) in all responses 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
   size limitations.  For this reason a security-aware name server must
   support the EDNS mechanism size extension, since otherwise inclusion
   of DNSSEC RRs could easily cause UDP message truncation and fallback
   to TCP.

   If possible, the private half of each DNSSEC key pair should be kept
   offline, but this will not be possible for a zone for which DNS
   dynamic update has been enabled.  In the dynamic update case, the
   primary master server for the zone will have to re-sign the zone when
   updated, so the private half of the zone signing key will have to be
   kept online.  This is an example of a situation where the ability to
   separate the zone's KEY RRset into zone signing key(s) and 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 August 15, 2003               [Page 13]

Internet-Draft    DNSSEC Introduction and Requirements     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].

9.1 DNS Security Document Roadmap

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


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

                   Figure 1: DNSSEC Document Roadmap

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


9.2 Categories of DNS Security Documents

   The "DNSSEC protocol document set" refers to the three documents
   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 August 15, 2003               [Page 14]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


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

   The "Digital Signature Algorithm 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 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 DNSSEC specification as defined in this set of
   documents, this group is noted to show its relationship to DNSSEC.

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






























Arends, et al.           Expires August 15, 2003               [Page 15]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


10. IANA Considerations

   This document introduces no new IANA considerations.
















































Arends, et al.           Expires August 15, 2003               [Page 16]

Internet-Draft    DNSSEC Introduction and Requirements     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.  This document discusses the capabilities and
   limitations of these extensions.  The extensions provide data origin
   authentication and data integrity using digital signatures over
   resource record sets.

   In order for a security-aware resolver to validate a DNS response,
   all of the intermediate zones must be signed, and all of 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, from a zone not served by a
   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 such
   that a security-aware resolver cannot obtain and validate the
   authentication keys it needs, then the security-aware resolver cannot
   validate the affected DNS data.

   This document briefly discusses other methods of adding security to a
   DNS query, such as using a channel secured by IPsec or using a DNS
   transaction authentication mechanism, but transaction security is not
   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 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 to defend against the latter threat.  The 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 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 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 Introduction and Requirements     February 2003


   dynamic update, by sending a stream of update messages that force the
   security-aware name server to 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.  NXT RRs assert which names do
   not exist in a zone by linking from existing name to existing name
   along a canonical ordering of all the names within a zone.  Thus, an
   attacker can query these NXT RRs in sequence to obtain all the names
   in a zone.  While not an attack on the DNS itself, this could allow
   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 August 15, 2003               [Page 18]

Internet-Draft    DNSSEC Introduction and Requirements     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
     Donald Eastlake
     Miek Gieben
     Olafur Gudmundsson
     Olaf Kolkman
     Ed Lewis
     Ted Lindgreen
     Bill Manning
     Brian Wellington



































Arends, et al.           Expires August 15, 2003               [Page 19]

Internet-Draft    DNSSEC Introduction and Requirements     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.

   [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.



Arends, et al.           Expires August 15, 2003               [Page 20]

Internet-Draft    DNSSEC Introduction and Requirements     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.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


   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 August 15, 2003               [Page 22]

Internet-Draft    DNSSEC Introduction and Requirements     February 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

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

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

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

Acknowledgement

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



















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