Struct trust_dns_proto::rr::dnssec::rdata::key::UpdateScope

source · [−]

pub struct UpdateScope {
    pub zone: bool,
    pub strong: bool,
    pub unique: bool,
    pub general: bool,
}

👎Deprecated:

Deprecated by RFC3007

Available on crate feature dnssec only.

Expand description

RFC 2137, Secure Domain Name System Dynamic Update, April 1997

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) 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.

RFC 3007, Secure Dynamic Update, November 2000

   [RFC2535, section 3.1.2] defines the signatory field of a key as the
   final 4 bits of the flags field, but does not define its value.  This
   proposal leaves this field undefined.  Updating [RFC2535], this field
   SHOULD be set to 0 in KEY records, and MUST be ignored.

Fields

zone: bool

👎Deprecated:

Deprecated by RFC3007

this key is authorized to attach, detach, and move zones by creating and deleting NS, glue A, and zone KEY RR(s)

strong: bool

👎Deprecated:

Deprecated by RFC3007

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

unique: bool

👎Deprecated:

Deprecated by RFC3007

this key is authorized to add and update RRs for only a single owner name

general: bool

👎Deprecated:

Deprecated by RFC3007

The general update signatory field bit has no special meaning, (true if the others are false)