Secure Domain Name System (DNS) Dynamic Update
RFC 3007
Document | Type |
RFC - Proposed Standard
(November 2000; No errata)
Obsoletes RFC 2137
|
|
---|---|---|---|
Author | Brian Wellington | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3007 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 aShow full document text