RR
Click on the red underlined text to get to the source
... 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 ...
... RR
provides a digital signature on the set of all RRs with the same
owner name and class as the SIG ...
... SIG. The SIG RR cryptographically binds the covered RR set to
the signer, time signed, signature ...
... authenticated by SIG
RRs. KEY RRs for zones are stored in their superzone and subzone
servers, if any, so that the secure DNS ...
... SIG
RRs. KEY RRs for zones are stored in their superzone and subzone
servers, if any, so that the secure DNS tree ...
... secure zone is any secure DNS zone containing one or more
KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
...
... dynamic updates, i.e., entity or user KEY
RRs with the signatory field non-zero, and whose zone KEY RR ...
... RRs with the signatory field non-zero, and whose zone KEY RR
signatory field indicates that updates are implemented. There are two
basic modes of dynamic secure zone ...
...
As a consequence, any dynamicly added or changed RRs are signed in
the secure zone by their authorizing dynamic update ...
... dynamic update key and they are
backed up, along with this SIG RR, in a separate online dynamic
master file. In this type of zone, server computation is minimized
since the server need only check signatures ...
... SIG and
NXT RRs which covers the zone under the zone key will not cover
dynamically added data. Thus, for type A dynamic secure zones ...
... transfer security is not automatically provided for dynamically added
RRs, where they could be omitted, and authentication is not provided
for the server denial of the existence of a dynamically added type.
...
... authentication is not provided
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 in the
KEY RR signatory field. Because dynamic data is only stored in the
online dynamic master file and only authenticated by dynamic keys
...
... SIG and thus always protected during
zone transfers and will be included in NXT RRs so that it can be
falsely denied by a server only to the same extent that static data
can (i.e., if it is within a wild card scope). Because the zone key ...
... is used to sign all the zone data, the information as to who
originated the current state of dynamic RR sets is lost, making
unavailable the effects of some of the update ...
... update control bits in the KEY
RR signatory field. In addition, the incorporation of the updates
into the primary master file and their authentication by the zone key ...
...
The scope of authority of such keys is indicated by their KEY RR
owner name, class, and signatory field flags as described below. In
...
... 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 ...
...
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 ...
... update authorizing KEY RR must (1) be the same
as the owner name of any RRs being added or deleted or (2) a wildcard
...
... 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
...
... 2065(-> 2535(-> 4035prop | 4034prop | 4033prop))) of any update
authorizing KEY RR must be non-zero. The bits have the meanings
...
... NS, glue A, and
zone KEY RR(s). If zero, the key can not authorize any update
that would effect such RRs ...
... 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 ...
... 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 ...
... delete RRs even if there are other RRs with the same owner name
and class that are authenticated ...
... different dynamic update KEY. If zero, the key can only
authorize updates where any existing RRs of the same owner and
class are authenticated ...
...
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
...
... 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
...
... 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
...
... 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 ...
... RRs with a particular name, it
can completely restrict a KEY from flooding a zone with RRs.
Bit ...
...
If there are multiple dynamic update KEY RRs for a zone and zone
policy is in transition, they might have different non-zero signatory
...
... 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
...
... 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 ...
... 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
...
... 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
...
... 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
...
... DNS header, including opcode, counts, etc., as well as the data.
Data signatures, on the other hand, appear only among the RRs to be
added and are only required for mode A operation. These two types of
signatures ...
... 2065(-> 2535(-> 4035prop | 4034prop | 4033prop)), a request signature is a SIG RR occurring
at the end of a request with a type covered field of zero. For an
update ...
... authenticate the after update state of all RR sets
that are changed by the update and are non-empty after the update ...
... These SIG RRs appear in the request as RRs to be added and the
request must delete any previous data SIG ...
... re-signing of the zone SOA resource record (RR) to increase the SOA
serial number. This means that compromise of the primary server host ...
...
Isolation of dynamic RRs to separate zones from those holding most
static RRs can limit the damage that could occur from breach of a
...
... Isolation of dynamic RRs to separate zones from those holding most
static RRs can limit the damage that could occur from breach of a
dynamic zone's security.
...