3. Keys
Dynamic update requests depend on update keys as described in section 3.1 below. In addition, the zone secure dynamic update mode and availability of some options is indicated in the zone key. Finally, a special rule is used in searching for KEYs to validate updates as described in section 3.3.
3.1. Update Keys
All update requests to a secure zone must include signatures by one or more key(s) that together can authorize that update. In order for the Domain Name System (DNS) server receiving the request to confirm this, the key or keys must be available to and authenticated by that server as a specially flagged KEY Resource Record.
The scope of authority of such keys is indicated by their KEY RR owner name, class, and signatory field flags as described below. In addition, such KEY RRs must be entity or user keys and not have the authentication use prohibited bit on. All parts of the actual update must be within the scope of at least one of the keys used for a request SIG on the update request as described in section 4.
3.1.1. Update Key Name Scope
The owner name of any update authorizing KEY RR must (1) be the same as the owner name of any RRs being added or deleted or (2) a wildcard name including within its extended scope (see section 3.3) the name of any RRs being added or deleted and those RRs must be in the same zone.
3.1.2. Update Key Class Scope
The class of any update authorizing KEY RR must be the same as the class of any RR's being added or deleted.
3.1.3. Update Key Signatory Field
The four bit "signatory field" (see RFC 2065(-> 2535(-> 4035prop | 4034prop | 4033prop))) of any update authorizing KEY RR must be non-zero. The bits have the meanings described below for non-zone keys (see section 3.2 for zone type keys).
UPDATE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| zone | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, zone control - If nonzero, this key is authorized to attach,
detach, and move zones by creating and deleting NS, glue A, and
zone KEY RR(s). If zero, the key can not authorize any update
that would effect such RRs. This bit is meaningful for both
type A and type B dynamic secure zones.
NOTE: do not confuse the "zone" signatory field bit with the
"zone" key type bit.
Bit 1, strong update - If nonzero, this key is authorized to add and
delete RRs even if there are other RRs with the same owner name
and class that are authenticated by a SIG signed with a
different dynamic update KEY. If zero, the key can only
authorize updates where any existing RRs of the same owner and
class are authenticated by a SIG using the same key. This bit
is meaningful only for type A dynamic zones and is ignored in
type B dynamic zones.
Keeping this bit zero on multiple KEY RRs with the same or
nested wild card owner names permits multiple entities to exist
that can create and delete names but can not effect RRs with
different owner names from any they created. In effect, this
creates two levels of dynamic update key, strong and weak, where
weak keys are limited in interfering with each other but a
strong key can interfere with any weak keys or other strong
keys.
Bit 2, unique name update - If nonzero, this key is authorized to add
and update RRs for only a single owner name. If there already
exist RRs with one or more names signed by this key, they may be
updated but no new name created until the number of existing
names is reduced to zero. This bit is meaningful only for mode
A dynamic zones and is ignored in mode B dynamic zones. This bit
is meaningful only if the owner name is a wildcard. (Any
dynamic update KEY with a non-wildcard name is, in effect, a
unique name update key.)
This bit can be used to restrict a KEY from flooding a zone with
new names. In conjunction with a local administratively imposed
limit on the number of dynamic RRs with a particular name, it
can completely restrict a KEY from flooding a zone with RRs.
Bit 3, general update - The general update signatory field bit has no
special meaning. If the other three bits are all zero, it must
be one so that the field is non-zero to designate that the key
is an update key. The meaning of all values of the signatory
field with the general bit and one or more other signatory field
bits on is reserved.
All the signatory bit update authorizations described above only apply if the update is within the name and class scope as per sections 3.1.1 and 3.1.2.
3.2. Zone Keys and Update Modes
Zone type keys are automatically authorized to sign anything in their zone, of course, regardless of the value of their signatory field. For zone keys, the signatory field bits have different means than they they do for update keys, as shown below. The signatory field MUST be zero if dynamic update is not supported for a zone and MUST be non-zero if it is.
ZONE KEY RR SIGNATORY FIELD BITS
0 1 2 3
+-----------+-----------+-----------+-----------+
| mode | strong | unique | general |
+-----------+-----------+-----------+-----------+
Bit 0, mode - This bit indicates the update mode for this zone. Zero
indicates mode A while a one indicates mode B.
Bit 1, strong update - If nonzero, this indicates that the "strong"
key feature described in section 3.1.3 above is implemented and
enabled for this secure zone. If zero, the feature is not
available. Has no effect if the zone is a mode B secure update
zone.
Bit 2, unique name update - If nonzero, this indicates that the
"unique name" feature described in section 3.1.3 above is
implemented and enabled for this secure zone. If zero, this
feature is not available. Has no effect if the zone is a mode B
secure update zone.
Bit 3, general - This bit has no special meeting. If dynamic update
for a zone is supported and the other bits in the zone key
signatory field are zero, it must be a one. The meaning of zone
keys where the signatory field has the general bit and one or
more other bits on is reserved.
If there are multiple dynamic update KEY RRs for a zone and zone policy is in transition, they might have different non-zero signatory fields. In that case, strong and unique name restrictions must be enforced as long as there is a non-expired zone key being advertised that indicates mode A with the strong or unique name bit on respectively. Mode B updates MUST be supported as long as there is a non-expired zone key that indicates mode B. Mode A updates may be treated as mode B updates at server option if non-expired zone keys indicate that both are supported.
A server that will be executing update operations on a zone, that is, the primary master server, MUST not advertize a zone key that will attract requests for a mode or features that it can not support.
3.3. Wildcard Key Punch Through
Just as a zone key is valid throughout the entire zone, update keys with wildcard names are valid throughout their extended scope, within the zone. That is, they remain valid for any name that would match them, even existing specific names within their apparent scope.
If this were not so, then whenever a name within a wildcard scope was created by dynamic update, it would be necessary to first create a copy of the KEY RR with this name, because otherwise the existence of the more specific name would hide the authorizing KEY RR and would make later updates impossible. An updater could create such a KEY RR but could not zone sign it with their authorizing signer. They would have to sign it with the same key using the wildcard name as signer. Thus in creating, for example, one hundred type A RRs authorized by a *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100 KEYs, and 200 SIGs would have to be created as opposed to merely 100 As and 100 SIGs with key punch through.