RFC 3007 (rfc3007) - Page 2 of 9
Secure Domain Name System (DNS) Dynamic Update
Alternative Format: Original Text Document
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 [RFC 2845] or SIG(0)
[RFC 2535, RFC 2931] 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