Secure Domain Name System (DNS) Dynamic Update
RFC 3007

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                      B. Wellington
Request for Comments: 3007                                       Nominum
Updates: 2535, 2136                                        November 2000
Obsoletes: 2137
Category: Standards Track

             Secure Domain Name System (DNS) Dynamic Update

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document proposes a method for performing secure Domain Name
   System (DNS) dynamic updates.  The method described here is intended
   to be flexible and useful while requiring as few changes to the
   protocol as possible.  The authentication of the dynamic update
   message is separate from later DNSSEC validation of the data.  Secure
   communication based on authenticated requests and transactions is
   used to provide authorization.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1 - Introduction

   This document defines a means to secure dynamic updates of the Domain
   Name System (DNS), allowing only authorized sources to make changes
   to a zone's contents.  The existing unsecured dynamic update
   operations form the basis for this work.

   Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
   [RFC2136] is helpful and is assumed by this document.  In addition,
   knowledge of DNS security extensions [RFC2535], SIG(0) transaction
   security [RFC2535, RFC2931], and TSIG transaction security [RFC2845]
   is recommended.

Wellington                  Standards Track                     [Page 1]
RFC 3007                 Secure Dynamic Update             November 2000

   This document updates portions of RFC 2535, in particular section
   3.1.2, and RFC 2136.  This document obsoletes RFC 2137, an alternate
   proposal for secure dynamic update, due to implementation experience.

1.1 - Overview of DNS Dynamic Update

   DNS dynamic update defines a new DNS opcode and a new interpretation
   of the DNS message if that opcode is used.  An update can specify
   insertions or deletions of data, along with prerequisites necessary
   for the updates to occur.  All tests and changes for a DNS update
   request are restricted to a single zone, and are performed at the
   primary server for the zone.  The primary server for a dynamic zone
   must increment the zone SOA serial number when an update occurs or
   before the next retrieval of the SOA.

1.2 - Overview of DNS Transaction Security

   Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
   [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
   requests and responses sent between them.  A TSIG MAC (message
   authentication code) is derived from a shared secret, and a SIG(0) is
   generated from a private key whose public counterpart is stored in
   DNS.  In both cases, a record containing the message signature/MAC is
   included as the final resource record in a DNS message.  Keyed
   hashes, used in TSIG, are inexpensive to calculate and verify.
   Public key encryption, as used in SIG(0), is more scalable as the
   public keys are stored in DNS.

1.3 - Comparison of data authentication and message authentication

   Message based authentication, using TSIG or SIG(0), provides
   protection for the entire message with a single signing and single
   verification which, in the case of TSIG, is a relatively inexpensive
   MAC creation and check.  For update requests, this signature can
   establish, based on policy or key negotiation, the authority to make
   the request.

   DNSSEC SIG records can be used to protect the integrity of individual
   RRs or RRsets in a DNS message with the authority of the zone owner.
   However, this cannot sufficiently protect the dynamic update request.

   Using SIG records to secure RRsets in an update request is
   incompatible with the design of update, as described below, and would
   in any case require multiple expensive public key signatures and
   verifications.

Wellington                  Standards Track                     [Page 2]
RFC 3007                 Secure Dynamic Update             November 2000

   SIG records do not cover the message header, which includes record
   counts.  Therefore, it is possible to maliciously insert or remove
   RRsets in an update request without causing a verification failure.

   If SIG records were used to protect the prerequisite section, it
   would be impossible to determine whether the SIGs themselves were a