update
Click on the red underlined text to get to the source
...
Dynamic update operations have been defined for the Domain Name
System (DNS) in RFC 2136prop ...
... RFC1035] is assumed.
Familiarity with the DNS security and dynamic update proposals will
be helpful.
...
... Overview of DNS Dynamic Update ...
... request and
response structure if that opcode is used, and new error codes. An
update can specify complex combinations of deletion and insertion
(with or without pre-existence testing) of resource records (RRs ...
... with one or more owner names; however, all testing and changes for
any particular DNS update request are restricted to a single zone.
Updates occur at the primary server for a zone.
...
... The primary server for a secure dynamic zone must increment the zone
SOA serial number when an update occurs or the next time the SOA is
retrieved if one or more updates have occurred since the previous SOA
retrieval and the updates themselves did not update ...
... update occurs or the next time the SOA is
retrieved if one or more updates have occurred since the previous SOA
retrieval and the updates themselves did not update the SOA.
...
... the secure zone is signed either by a zone key or by a dynamic update
key tracing its authority to a zone key ...
...
Request SIGs are the primary means of authenticating update requests.
...
... signatory field indicates that updates are implemented. There are two
basic modes of dynamic secure zone which relate to the update
strategy, mode A and mode B. A summary comparison table is given
...
... RRs are signed in
the secure zone by their authorizing dynamic update key and they are
backed up, along with this SIG RR ...
... master file. In this type of zone, server computation is minimized
since the server need only check signatures on the update data and
request, which have already been signed by the updater, generally a
much faster operation than signing ...
... for the server denial of the existence of a dynamically added type.
Because the dynamicly added RRs retain their update KEY signed SIG,
finer grained control of updates can be implemented via bits ...
... authority for manual transfer to the off line static master file.
NOTE: for this mode the zone SOA must be signed by a dynamic update
key and that private key must be kept on line so that the SOA can be
...
... AXFR SIG may be recalculated for each
update or on demand when a zone transfer is requested and it is out
of date.)
...
... RR sets is lost, making
unavailable the effects of some of the update control bits in the KEY
RR ...
... zone key on-line
also means that dynamic update keys which are signed by the zone key
can be dynamically updated since the zone key ...
... validation
and performance of update requests. It has no effect on retrievals.
One reasonable operational scheme may be to keep a mostly static main
zone operating in Mode A and have one or more dynamic subzones
...
...
Dynamic update requests depend on update keys as described in section
3.1 below. In addition, the zone secure dynamic update ...
...
Dynamic update requests depend on update keys as described in section
3.1 below. In addition, the zone secure dynamic update mode and
...
... 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,
...
... Update Keys ...
... 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 ...
... 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 ...
... 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.
...
... 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 ...
... 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 ...
... zone KEY RR(s). If zero, the key can not authorize any update
that would effect such RRs. This bit ...
... 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
...
... 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
...
... 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 ...
... 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 ...
... dynamic update KEY with a non-wildcard name is, in effect, a
unique name update key.)
This bit ...
... Bit 3, general update - The general update signatory field bit has no
special meaning. If the other three bits ...
... 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
...
... 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.
...
... 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
...
... 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.
...
... 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 ...
... secure zone. If zero, this
feature is not available. Has no effect if the zone is a mode B
secure update zone.
Bit ...
... 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 ...
...
If there are multiple dynamic update KEY RRs for a zone and zone
policy is in transition, they might have different non-zero ...
...
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
...
... Just as a zone key is valid throughout the entire zone, update keys
with wildcard names are valid ...
... wildcard scope was
created by dynamic update, it would be necessary to first create a
copy of the KEY RR ...
... Update Signatures ...
... Update Request Signatures ...
...
An update can effect multiple owner names in a zone. It may be that
these different names are covered by different dynamic update keys.
...
... An update can effect multiple owner names in a zone. It may be that
these different names are covered by different dynamic update keys.
For every owner name effected, the updater must know a private key
...
... RR occurring
at the end of a request with a type covered field of zero. For an
update, request signatures occur in the Additional information
section. Each request SIG ...
... Update Data Signatures ...
... state of all RR sets
that are changed by the update and are non-empty after the update.
These SIG ...
... RRs. In this case, data signatures need not be included
with the update. A resolver can determine which mode an updatable
secure zone is using by examining the signatory field bits ...
... secure zone maintained off line as recommended in RFC 2065(-> 2535(-> 4035prop | 4034prop | 4033prop)). If
nothing else, secure dynamic update requires on line change to and
re-signing of the zone SOA resource record ...