RFC 3833 (rfc3833) - Page 2 of 16

Threat Analysis of the Domain Name System (DNS)

RFC 3833                  DNS Threat Analysis                August 2004


   - Backwards compatibility and co-existence with "insecure DNS" was
     listed as an explicit requirement.

   - The resulting list of desired security services was
     1) data integrity, and
     2) data origin authentication.

   - The design team noted that a digital signature mechanism would
     support the desired services.

   While a number of detail decisions were yet to be made (and in some
   cases remade after implementation experience) over the subsequent
   decade, the basic model and design goals have remained fixed.

   Nowhere, however, does any of the DNSSEC work attempt to specify in
   any detail the sorts of attacks against which DNSSEC is intended to
   protect, or the reasons behind the list of desired security services
   that came out of the Houston meeting.  For that, we have to go back
   to a paper originally written by Steve Bellovin in 1990 but not
   published until 1995, for reasons that Bellovin explained in the
   paper's epilogue [Bellovin95].

   While it may seem a bit strange to publish the threat analysis a
   decade after starting work on the protocol designed to defend against
   it, that is, nevertheless, what this note attempts to do.  Better
   late than never.

   This note assumes that the reader is familiar with both the DNS and
   with DNSSEC, and does not attempt to provide a tutorial on either.
   The DNS documents most relevant to the subject of this note are:
   [RFC 1034], [RFC 1035], section 6.1 of [RFC 1123], [RFC 2181], [RFC 2308],
   [RFC 2671], [RFC 2845], [RFC 2930], [RFC 3007], and [RFC 2535].

   For purposes of discussion, this note uses the term "DNSSEC" to refer
   to the core hierarchical public key and signature mechanism specified
   in the DNSSEC documents, and refers to TKEY and TSIG as separate
   mechanisms, even though channel security mechanisms such as TKEY and
   TSIG are also part of the larger problem of "securing DNS" and thus
   are often considered part of the overall set of "DNS security
   extensions".  This is an arbitrary distinction that in part reflects
   the way in which the protocol has evolved (introduction of a
   putatively simpler channel security model for certain operations such
   as zone transfers and dynamic update requests), and perhaps should be
   changed in a future revision of this note.







Atkins & Austein             Informational