Threat Analysis of the Domain Name System (DNS)
RFC 3833

Network Working Group                                          D. Atkins
Request for Comments: 3833                              IHTFP Consulting
Category: Informational                                       R. Austein
                                                                     ISC
                                                             August 2004

            Threat Analysis of the Domain Name System (DNS)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   Although the DNS Security Extensions (DNSSEC) have been under
   development for most of the last decade, the IETF has never written
   down the specific set of threats against which DNSSEC is designed to
   protect.  Among other drawbacks, this cart-before-the-horse situation
   has made it difficult to determine whether DNSSEC meets its design
   goals, since its design goals are not well specified.  This note
   attempts to document some of the known threats to the DNS, and, in
   doing so, attempts to measure to what extent (if any) DNSSEC is a
   useful tool in defending against these threats.

1. Introduction

   The earliest organized work on DNSSEC within the IETF was an open
   design team meeting organized by members of the DNS working group in
   November 1993 at the 28th IETF meeting in Houston.  The broad
   outlines of DNSSEC as we know it today are already clear in Jim
   Galvin's summary of the results of that meeting [Galvin93]:

   - While some participants in the meeting were interested in
     protecting against disclosure of DNS data to unauthorized parties,
     the design team made an explicit decision that "DNS data is
     `public'", and ruled all threats of data disclosure explicitly out
     of scope for DNSSEC.

   - While some participants in the meeting were interested in
     authentication of DNS clients and servers as a basis for access
     control, this work was also ruled out of scope for DNSSEC per se.

Atkins & Austein             Informational                      [Page 1]
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:
   [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
   [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].

   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                      [Page 2]
RFC 3833                  DNS Threat Analysis                August 2004