Secure Domain Name System Dynamic Update
obsoleted by
- rfc-3007 — Secure Domain Name System (DNS) Dynamic Update
updates
- rfc-1035 — Domain names - implementation and specification
Extracted elements (20)
Mode A minimizes server computation (signature verification is cheaper than signing) and allows fine-grained update control via signatory field bits, but dynamically added RRs are not covered by the AXFR SIG or NXT RRs, creating gaps in zone transfer security and authenticated denial-of-existence for dynamic types.
Mode B requires the zone key to be on-line, which imposes substantially higher server CPU load (signing is more expensive than verification) and reduces static data security because the primary server's compromise could allow false data to be authenticated to secondaries. However, it provides permanent, fully-integrated protection for dynamic data including zone transfers and NXT coverage.
Two operational modes for secure dynamic zones are defined. Mode A keeps the zone key offline for maximum static data security; dynamic RRs are signed by their authorizing update keys and stored in a separate online dynamic master file. Mode B keeps the zone key online, requiring more server computation but providing stronger security for dynamically added data (covered by AXFR SIG and NXT RRs).
Wildcard update keys retain authority for any name matching them even when specific names within their scope exist (key punch-through). Without this rule, creating a specific name would hide the wildcard KEY RR, making subsequent updates to that name impossible without first creating and signing a per-name KEY RR copy — a process that cannot be zone-signed by the original authorizing key.
All update requests to a secure zone must include signatures by one or more keys that together authorize that update. The keys must be available to and authenticated by the receiving server as specially flagged KEY Resource Records.
For every owner name affected by an update, the updater must append a request SIG RR signed with a private key that is valid for that name and the zone's class. An update affecting multiple owner names covered by different dynamic update keys requires multiple request SIG RRs.
Mode A dynamic secure zones require the update requester to provide SIG RRs that will authenticate the post-update state of all RR sets changed by the update that are non-empty after the update. The request must also delete any previous data SIG RRs invalidated by the request.
Mode B updates MUST be supported as long as there is a non-expired zone key that indicates Mode B. When zone policy is in transition and multiple dynamic update KEY RRs exist with different non-zero signatory fields, strong and unique name restrictions must be enforced as long as a non-expired Mode A zone key with those bits set exists.
The class of any update-authorizing KEY RR must be the same as the class of any RRs being added or deleted.
The four-bit signatory field of any update-authorizing KEY RR must be non-zero. In addition, such KEY RRs must be entity or user keys and must not have the authentication-use-prohibited bit set.
The owner name of any update-authorizing KEY RR must either (1) be the same as the owner name of any RRs being added or deleted, or (2) be a wildcard name whose extended scope (with punch-through) includes the name of any RRs being added or deleted within the same zone.
The primary master server MUST NOT advertise a zone key that will attract requests for a mode or features that it cannot support.
The zone KEY RR signatory field MUST be zero if dynamic update is not supported for the zone, and MUST be non-zero if dynamic update is supported.
A dynamic secure zone is identified by containing one or more KEY RRs with a non-zero signatory field that can authorize dynamic updates, and whose zone KEY RR signatory field indicates that updates are implemented. The zone KEY RR signatory field MUST be zero if dynamic update is not supported, and MUST be non-zero if it is.
A request signature is a SIG RR with a type-covered field of zero, placed in the Additional Information section of an update request. Each request SIG signs the entire request including the DNS header (but excluding other request SIGs), with ARCOUNT set to the value it would have without the request SIGs.
In Mode B dynamic secure zones, all zone data is authenticated by zone key SIG RRs; update data signatures need not be included with the update. A resolver determines the zone's mode by examining the signatory field bits of the zone KEY RR.
The four-bit signatory field of a non-zone update KEY RR encodes: bit 0 (zone control — authorizes NS, glue A, and zone KEY RR changes), bit 1 (strong update — may add/delete RRs authenticated by different update keys), bit 2 (unique name update — may only update a single owner name if wildcard), and bit 3 (general — must be one if all other bits are zero).
The four-bit signatory field of a zone KEY RR encodes: bit 0 (mode — 0 = Mode A, 1 = Mode B), bit 1 (strong update feature enabled), bit 2 (unique name update feature enabled), and bit 3 (general — must be one if dynamic update is supported and other bits are zero).
Any zone permitting dynamic updates is inherently less secure than a static secure zone maintained offline. Secure dynamic update requires on-line re-signing of the zone SOA RR, meaning compromise of the primary server host could lead to arbitrary SOA serial number changes.
Isolating dynamic RRs to separate zones from those holding mostly static RRs limits the damage that can result from a breach of a dynamic zone's security, since static zones can remain fully offline.