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

bind-3.2.

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.