Secure Domain Name System (DNS) Dynamic Update
Extracted elements (27)
Authentication of an update request is fully separated from authentication of the DNS data. Once data is present in DNS, only DNSSEC zone keys and their signatures are used; host/user key signatures are never used for data validation.
Message-based authentication (TSIG/SIG(0)) is used instead of per-RRset SIG records for update requests because SIG records do not cover the message header (including record counts), making it possible to maliciously insert or remove RRsets without causing verification failure.
Policy is fully implemented in the primary zone server's configuration rather than encoded in KEY RR bits to remove fixed-bit limitations, avoid exposing policy in DNS data, and prevent policy changes from causing interoperability failures or requiring protocol changes.
This document obsoletes RFC 2137 (an alternate secure dynamic update proposal) due to implementation experience, rather than any fundamental protocol deficiency.
Using SIG records to protect the prerequisite section of an update message is impractical because it would be impossible to determine whether the SIGs were a prerequisite or simply used for validation.
Changes to NXT records by secure dynamic update are explicitly forbidden (an update to RFC 2136); SOA updates are allowed since SOA parameter maintenance is outside the scope of the DNS protocol.
This document updates RFC 2535 (section 3.1.2) by leaving the signatory field undefined and requiring it be set to 0 and ignored, and updates RFC 2136 by explicitly forbidding NXT record modification via dynamic update.
By default, a principal MUST NOT be permitted to make any changes to zone data; any permissions MUST be explicitly enabled through configuration.
DNSSEC SIG records (other than SIG(0)) MAY be included in an update message but MUST NOT be used to authenticate the update request.
If a TSIG shared secret was established via an unauthenticated TKEY process, no information is known about the principal and the associated TSIG shared secret MUST NOT be used for secure dynamic update.
If an update fails because it is signed with an unauthorized key, the server MUST indicate failure by returning a message with RCODE REFUSED.
If any changes are made, the server MUST, if necessary, generate a new SOA record and new NXT records and sign these with the appropriate zone keys.
If the updated zone is secured, the RRset affected by an update operation MUST, at the completion of the update, be signed in accordance with the zone's signing policy, requiring zone keys whose private components MUST be online.
Implementations SHOULD allow per-name access control and SHOULD allow per-type access control restricting updates by RR type.
NXT records MUST NOT be created, modified, or deleted by dynamic update, as their update may cause instability in the protocol. This is an update to RFC 2136.
SIG(0) signatures SHOULD NOT be generated by zone keys, since transactions are initiated by a host or user, not a zone.
SOA and NS records SHOULD NOT be modified by normal users, since these types create or modify delegation points.
The DNSSEC validation process performed by a resolver MUST NOT process any non-zone keys unless local policy dictates otherwise (referencing RFC 3008).
The signatory field (final 4 bits of the flags field) of KEY records SHOULD be set to 0, and MUST be ignored. This updates RFC 2535 section 3.1.2.
TSIG or SIG(0) records MUST be included in all secure dynamic update messages, allowing the server to verifiably determine the originator of a message.
When performing secure dynamic update, all zone data modified in a signed zone MUST be signed by a relevant zone key, completely disassociating authentication of the update request from authentication of the data itself.
Host and user keys MAY be used to generate SIG(0) records to authenticate updates and MAY be used in the TKEY process to generate TSIG shared secrets, but no SIG records generated by non-zone keys will be used in DNSSEC validation unless local policy dictates.
The principal is the identity derived from the message signing key. For SIG(0), the principal is the owner of the KEY RR that generated the SIG(0). For a statically configured TSIG, the principal is derived from the shared secret name. For a dynamically configured TSIG, the principal is the one that authenticated the TKEY process.
TSIG (RFC 2845) uses a MAC derived from a shared secret for message authentication; it is inexpensive to calculate and verify. SIG(0) (RFC 2931) uses a private/public key pair, with the public key stored in DNS, and is more scalable.
User types are defined as all RR types except SOA, NS, SIG, and NXT. These four types are excluded because modifying them can affect DNS operation, delegation points, or protocol stability.
Allowing updates of KEY records may lead to undesirable results, since a principal may be permitted to insert a public key without holding the corresponding private key and could thereby masquerade as the key owner.
Performing secure dynamic updates requires a zone key and possibly other cryptographic secret material to be held on an online, network-connected host (typically a name server). Compromise of this host exposes DNS data to masquerade attacks on both zones served by and delegated from that machine.