2. Definitions of Important DNSSEC Terms

   This section defines a number of terms used in this document set.
   Because this is intended to be useful as a reference while reading
   the rest of the document set, first-time readers may wish to skim
   this section quickly, read the rest of this document, and then come
   back to this section.

   Authentication Chain: An alternating sequence of DNS public key
      (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
      signed data, with each link in the chain vouching for the next.  A
      DNSKEY RR is used to verify the signature covering a DS RR and
      allows the DS RR to be authenticated.  The DS RR contains a hash
      of another DNSKEY RR and this new DNSKEY RR is authenticated by
      matching the hash in the DS RR.  This new DNSKEY RR in turn
      authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
      this set may be used to authenticate another DS RR, and so forth
      until the chain finally ends with a DNSKEY RR whose corresponding
      private key signs the desired DNS data.  For example, the root
      DNSKEY RRset can be used to authenticate the DS RRset for
      "example."  The "example." DS RRset contains a hash that matches
      some "example." DNSKEY, and this DNSKEY's corresponding private
      key signs the "example." DNSKEY RRset.  Private key counterparts
      of the "example." DNSKEY RRset sign data records such as
      "www.example." and DS RRs for delegations such as
      "subzone.example."

   Authentication Key: A public key that a security-aware resolver has
      verified and can therefore use to authenticate data.  A
      security-aware resolver can obtain authentication keys in three
      ways.  First, the resolver is generally configured to know about
      at least one public key; this configured data is usually either
      the public key itself or a hash of the public key as found in the
      DS RR (see "trust anchor").  Second, the resolver may use an
      authenticated public key to verify a DS RR and the DNSKEY RR to
      which the DS RR refers.  Third, the resolver may be able to
      determine that a new public key has been signed by the private key
      corresponding to another public key that the resolver has
      verified.  Note that the resolver must always be guided by local
      policy when deciding whether to authenticate a new public key,
      even if the local policy is simply to authenticate any new public
      key for which the resolver is able verify the signature.

   Authoritative RRset: Within the context of a particular zone, an
      RRset is "authoritative" if and only if the owner name of the
      RRset lies within the subset of the name space that is at or below
      the zone apex and at or above the cuts that separate the zone from
      its children, if any.  All RRsets at the zone apex are
      authoritative, except for certain RRsets at this domain name that,
      if present, belong to this zone's parent.  These RRset could
      include a DS RRset, the NSEC RRset referencing this DS RRset (the
      "parental NSEC"), and RRSIG RRs associated with these RRsets, all
      of which are authoritative in the parent zone.  Similarly, if this
      zone contains any delegation points, only the parental NSEC RRset,
      DS RRsets, and any RRSIG RRs associated with these RRsets are
      authoritative for this zone.

   Delegation Point: Term used to describe the name at the parental side
      of a zone cut.  That is, the delegation point for "foo.example"
      would be the foo.example node in the "example" zone (as opposed to
      the zone apex of the "foo.example" zone).  See also zone apex.

   Island of Security: Term used to describe a signed, delegated zone
      that does not have an authentication chain from its delegating
      parent.  That is, there is no DS RR containing a hash of a DNSKEY
      RR for the island in its delegating parent zone (see [RFC4034]).
      An island of security is served by security-aware name servers and
      may provide authentication chains to any delegated child zones.
      Responses from an island of security or its descendents can only
      be authenticated if its authentication keys can be authenticated
      by some trusted means out of band from the DNS protocol.

   Key Signing Key (KSK): An authentication key that corresponds to a
      private key used to sign one or more other authentication keys for
      a given zone.  Typically, the private key corresponding to a key
      signing key will sign a zone signing key, which in turn has a
      corresponding private key that will sign other zone data.  Local
      policy may require that the zone signing key be changed
      frequently, while the key signing key may have a longer validity
      period in order to provide a more stable secure entry point into
      the zone.  Designating an authentication key as a key signing key
      is purely an operational issue: DNSSEC validation does not
      distinguish between key signing keys and other DNSSEC
      authentication keys, and it is possible to use a single key as
      both a key signing key and a zone signing key.  Key signing keys
      are discussed in more detail in [RFC3757].  Also see zone signing
      key.

   Non-Validating Security-Aware Stub Resolver: A security-aware stub
      resolver that trusts one or more security-aware recursive name
      servers to perform most of the tasks discussed in this document
      set on its behalf.  In particular, a non-validating security-aware
      stub resolver is an entity that sends DNS queries, receives DNS
      responses, and is capable of establishing an appropriately secured
      channel to a security-aware recursive name server that will
      provide these services on behalf of the security-aware stub
      resolver.  See also security-aware stub resolver, validating
      security-aware stub resolver.

   Non-Validating Stub Resolver: A less tedious term for a
      non-validating security-aware stub resolver.

   Security-Aware Name Server: An entity acting in the role of a name
      server (defined in section 2.4 of [RFC1034]) that understands the
      DNS security extensions defined in this document set.  In
      particular, a security-aware name server is an entity that
      receives DNS queries, sends DNS responses, supports the EDNS0
      ([RFC2671]) message size extension and the DO bit ([RFC3225]), and
      supports the RR types and message header bits defined in this
      document set.

   Security-Aware Recursive Name Server: An entity that acts in both the
      security-aware name server and security-aware resolver roles.  A
      more cumbersome but equivalent phrase would be "a security-aware
      name server that offers recursive service".

   Security-Aware Resolver: An entity acting in the role of a resolver
      (defined in section 2.4 of [RFC1034]) that understands the DNS
      security extensions defined in this document set.  In particular,
      a security-aware resolver is an entity that sends DNS queries,
      receives DNS responses, supports the EDNS0 ([RFC2671]) message
      size extension and the DO bit ([RFC3225]), and is capable of using
      the RR types and message header bits defined in this document set
      to provide DNSSEC services.

   Security-Aware Stub Resolver: An entity acting in the role of a stub
      resolver (defined in section 5.3.1 of [RFC1034]) that has enough
      of an understanding the DNS security extensions defined in this
      document set to provide additional services not available from a
      security-oblivious stub resolver.  Security-aware stub resolvers
      may be either "validating" or "non-validating", depending on
      whether the stub resolver attempts to verify DNSSEC signatures on
      its own or trusts a friendly security-aware name server to do so.
      See also validating stub resolver, non-validating stub resolver.

   Security-Oblivious <anything>: An <anything> that is not
      "security-aware".

   Signed Zone: A zone whose RRsets are signed and that contains
      properly constructed DNSKEY, Resource Record Signature (RRSIG),
      Next Secure (NSEC), and (optionally) DS records.

   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
      validating security-aware resolver uses this public key or hash as
      a starting point for building the authentication chain to a signed
      DNS response.  In general, a validating resolver will have to
      obtain the initial values of its trust anchors via some secure or
      trusted means outside the DNS protocol.  Presence of a trust
      anchor also implies that the resolver should expect the zone to
      which the trust anchor points to be signed.

   Unsigned Zone: A zone that is not signed.

   Validating Security-Aware Stub Resolver: A security-aware resolver
      that sends queries in recursive mode but that performs signature
      validation on its own rather than just blindly trusting an
      upstream security-aware recursive name server.  See also
      security-aware stub resolver, non-validating security-aware stub
      resolver.

   Validating Stub Resolver: A less tedious term for a validating
      security-aware stub resolver.

   Zone Apex: Term used to describe the name at the child's side of a
      zone cut.  See also delegation point.

   Zone Signing Key (ZSK): An authentication key that corresponds to a
      private key used to sign a zone.  Typically, a zone signing key
      will be part of the same DNSKEY RRset as the key signing key whose
      corresponding private key signs this DNSKEY RRset, but the zone
      signing key is used for a slightly different purpose and may
      differ from the key signing key in other ways, such as validity
      lifetime.  Designating an authentication key as a zone signing key
      is purely an operational issue; DNSSEC validation does not
      distinguish between zone signing keys and other DNSSEC
      authentication keys, and it is possible to use a single key as
      both a key signing key and a zone signing key.  See also key
      signing key.