9.  Registration Model

   Registry:  The administrative operation of a zone that allows
      registration of names within that zone.  People often use this
      term to refer only to those organizations that perform
      registration in large delegation-centric zones (such as TLDs); but
      formally, whoever decides what data goes into a zone is the
      registry for that zone.  This definition of "registry" is from a
      DNS point of view; for some zones, the policies that determine
      what can go in the zone are decided by zones that are
      superordinate and not the registry operator.

   Registrant:  An individual or organization on whose behalf a name in
      a zone is registered by the registry.  In many zones, the registry
      and the registrant may be the same entity, but in TLDs they often
      are not.

   Registrar:  A service provider that acts as a go-between for
      registrants and registries.  Not all registrations require a
      registrar, though it is common to have registrars involved in
      registrations in TLDs.

   EPP:  The Extensible Provisioning Protocol (EPP), which is commonly
      used for communication of registration information between
      registries and registrars.  EPP is defined in [RFC5730].

   WHOIS:  A protocol specified in [RFC3912], often used for querying
      registry databases.  WHOIS data is frequently used to associate
      registration data (such as zone management contacts) with domain
      names.  The term "WHOIS data" is often used as a synonym for the
      registry database, even though that database may be served by
      different protocols, particularly RDAP.  The WHOIS protocol is
      also used with IP address registry data.

   RDAP:  The Registration Data Access Protocol, defined in [RFC7480],
      [RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485].  The
      RDAP protocol and data format are meant as a replacement for
      WHOIS.

   DNS operator:  An entity responsible for running DNS servers.  For a
      zone's authoritative servers, the registrant may act as their own
      DNS operator, their registrar may do it on their behalf, or they
      may use a third-party operator.  For some zones, the registry
      function is performed by the DNS operator plus other entities who
      decide about the allowed contents of the zone.

   Public suffix:  "A domain that is controlled by a public registry."
      (Quoted from [RFC6265], Section 5.3) A common definition for this
      term is a domain under which subdomains can be registered by third
      parties and on which HTTP cookies (which are described in detail
      in [RFC6265]) should not be set.  There is no indication in a
      domain name whether it is a public suffix; that can only be
      determined by outside means.  In fact, both a domain and a
      subdomain of that domain can be public suffixes.

      There is nothing inherent in a domain name to indicate whether it
      is a public suffix.  One resource for identifying public suffixes
      is the Public Suffix List (PSL) maintained by Mozilla
      (http://publicsuffix.org/).

      For example, at the time this document is published, the "com.au"
      domain is listed as a public suffix in the PSL.  (Note that this
      example might change in the future.)

      Note that the term "public suffix" is controversial in the DNS
      community for many reasons, and it may be significantly changed in
      the future.  One example of the difficulty of calling a domain a
      public suffix is that designation can change over time as the
      registration policy for the zone changes, such as was the case
      with the "uk" TLD in 2014.

   Subordinate and Superordinate:  These terms are introduced in
      [RFC5731] for use in the registration model, but not defined
      there.  Instead, they are given in examples.  "For example, domain
      name 'example.com' has a superordinate relationship to host name
      ns1.example.com'...  For example, host ns1.example1.com is a
      subordinate host of domain example1.com, but it is a not a
      subordinate host of domain example2.com."  (Quoted from [RFC5731],
      Section 1.1) These terms are strictly ways of referring to the
      relationship standing of two domains where one is a subdomain of
      the other.

10.  General DNSSEC

   Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and
   [RFC5155].  The terms that have caused confusion in the DNS community
   are highlighted here.

   DNSSEC-aware and DNSSEC-unaware:  These two terms, which are used in
      some RFCs, have not been formally defined.  However, Section 2 of
      [RFC4033] defines many types of resolvers and validators,
      including "non-validating security-aware stub resolver",
      "non-validating stub resolver", "security-aware name server",
      "security-aware recursive name server", "security-aware resolver",
      "security-aware stub resolver", and "security-oblivious
      'anything'".  (Note that the term "validating resolver", which is
      used in some places in DNSSEC-related documents, is also not
      defined in those RFCs, but is defined below.)

   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."  (Quoted from
      [RFC4033], Section 2) It has been noted in other contexts that the
      zone itself is not really signed, but all the relevant RRsets in
      the zone are signed.  Nevertheless, if a zone that should be
      signed contains any RRsets that are not signed (or opted out),
      those RRsets will be treated as bogus, so the whole zone needs to
      be handled in some way.

      It should also be noted that, since the publication of [RFC6840],
      NSEC records are no longer required for signed zones: a signed
      zone might include NSEC3 records instead.  [RFC7129] provides
      additional background commentary and some context for the NSEC and
      NSEC3 mechanisms used by DNSSEC to provide authenticated denial-
      of-existence responses.  NSEC and NSEC3 are described below.

   Unsigned zone:  Section 2 of [RFC4033] defines this as "a zone that
      is not signed".  Section 2 of [RFC4035] defines this as a "zone
      that does not include these records [properly constructed DNSKEY,
      Resource Record Signature (RRSIG), Next Secure (NSEC), and
      (optionally) DS records] according to the rules in this
      section..." There is an important note at the end of Section 5.2
      of [RFC4035] that defines an additional situation in which a zone
      is considered unsigned: "If the resolver does not support any of
      the algorithms listed in an authenticated DS RRset, then the
      resolver will not be able to verify the authentication path to the
      child zone.  In this case, the resolver SHOULD treat the child
      zone as if it were unsigned."

   NSEC:  "The NSEC record allows a security-aware resolver to
      authenticate a negative reply for either name or type
      non-existence with the same mechanisms used to authenticate other
      DNS replies."  (Quoted from [RFC4033], Section 3.2) In short, an
      NSEC record provides authenticated denial of existence.

      "The NSEC resource record lists two separate things: the next
      owner name (in the canonical ordering of the zone) that contains
      authoritative data or a delegation point NS RRset, and the set of
      RR types present at the NSEC RR's owner name."  (Quoted from
      Section 4 of RFC 4034)

   NSEC3:  Like the NSEC record, the NSEC3 record also provides
      authenticated denial of existence; however, NSEC3 records mitigate
      zone enumeration and support Opt-Out.  NSEC3 resource records
      require associated NSEC3PARAM resource records.  NSEC3 and
      NSEC3PARAM resource records are defined in [RFC5155].

      Note that [RFC6840] says that [RFC5155] "is now considered part of
      the DNS Security Document Family as described by Section 10 of
      [RFC4033]".  This means that some of the definitions from earlier
      RFCs that only talk about NSEC records should probably be
      considered to be talking about both NSEC and NSEC3.

   Opt-out:  "The Opt-Out Flag indicates whether this NSEC3 RR may cover
      unsigned delegations."  (Quoted from [RFC5155], Section 3.1.2.1)
      Opt-out tackles the high costs of securing a delegation to an
      insecure zone.  When using Opt-Out, names that are an insecure
      delegation (and empty non-terminals that are only derived from
      insecure delegations) don't require an NSEC3 record or its
      corresponding RRSIG records.  Opt-Out NSEC3 records are not able
      to prove or deny the existence of the insecure delegations.
      (Adapted from [RFC7129], Section 5.1)

   Insecure delegation:  "A signed name containing a delegation (NS
      RRset), but lacking a DS RRset, signifying a delegation to an
      unsigned subzone."  (Quoted from [RFC4956], Section 2)

   Zone enumeration:  "The practice of discovering the full content of a
      zone via successive queries."  (Quoted from [RFC5155],
      Section 1.3) This is also sometimes called "zone walking".  Zone
      enumeration is different from zone content guessing where the
      guesser uses a large dictionary of possible labels and sends
      successive queries for them, or matches the contents of NSEC3
      records against such a dictionary.

   Validation:  Validation, in the context of DNSSEC, refers to one of
      the following:

      *  Checking the validity of DNSSEC signatures,

      *  Checking the validity of DNS responses, such as those including
         authenticated denial of existence, or

      *  Building an authentication chain from a trust anchor to a DNS
         response or individual DNS RRsets in a response

      The first two definitions above consider only the validity of
      individual DNSSEC components such as the RRSIG validity or NSEC
      proof validity.  The third definition considers the components of
      the entire DNSSEC authentication chain; thus, it requires
      "configured knowledge of at least one authenticated DNSKEY or DS
      RR" (as described in [RFC4035], Section 5).

      [RFC4033], Section 2, says that a "Validating Security-Aware Stub
      Resolver... performs signature validation" and uses a trust anchor
      "as a starting point for building the authentication chain to a
      signed DNS response"; thus, it uses the first and third
      definitions above.  The process of validating an RRSIG resource
      record is described in [RFC4035], Section 5.3.

      [RFC5155] refers to validating responses throughout the document,
      in the context of hashed authenticated denial of existence; this
      uses the second definition above.

      The term "authentication" is used interchangeably with
      "validation", in the sense of the third definition above.
      [RFC4033], Section 2, describes the chain linking trust anchor to
      DNS data as the "authentication chain".  A response is considered
      to be authentic if "all RRsets in the Answer and Authority
      sections of the response [are considered] to be authentic" (Quoted
      from [RFC4035]) DNS data or responses deemed to be authentic or
      validated have a security status of "secure" ([RFC4035],
      Section 4.3; [RFC4033], Section 5).  "Authenticating both DNS keys
      and data is a matter of local policy, which may extend or even
      override the [DNSSEC] protocol extensions..." (Quoted from
      [RFC4033], Section 3.1)

      The term "verification", when used, is usually a synonym for
      "validation".

   Validating resolver:  A security-aware recursive name server,
      security-aware resolver, or security-aware stub resolver that is
      applying at least one of the definitions of validation (above), as
      appropriate to the resolution context.  For the same reason that
      the generic term "resolver" is sometimes ambiguous and needs to be
      evaluated in context (see Section 6), "validating resolver" is a
      context-sensitive term.

   Key signing key (KSK):  DNSSEC keys that "only sign the apex DNSKEY
      RRset in a zone."  (Quoted from [RFC6781], Section 3.1)

   Zone signing key (ZSK):  "DNSSEC keys that can be used to sign all
      the RRsets in a zone that require signatures, other than the apex
      DNSKEY RRset."  (Quoted from [RFC6781], Section 3.1) Also note
      that a ZSK is sometimes used to sign the apex DNSKEY RRset.

   Combined signing key (CSK):  "In cases where the differentiation
      between the KSK and ZSK is not made, i.e., where keys have the
      role of both KSK and ZSK, we talk about a Single-Type Signing
      Scheme."  (Quoted from [RFC6781], Section 3.1) This is sometimes
      called a "combined signing key" or "CSK".  It is operational
      practice, not protocol, that determines whether a particular key
      is a ZSK, a KSK, or a CSK.

   Secure Entry Point (SEP):  A flag in the DNSKEY RDATA that "can be
      used to distinguish between keys that are intended to be used as
      the secure entry point into the zone when building chains of
      trust, i.e., they are (to be) pointed to by parental DS RRs or
      configured as a trust anchor....  Therefore, it is suggested that
      the SEP flag be set on keys that are used as KSKs and not on keys
      that are used as ZSKs, while in those cases where a distinction
      between a KSK and ZSK is not made (i.e., for a Single-Type Signing
      Scheme), it is suggested that the SEP flag be set on all keys."
      (Quoted from [RFC6781], Section 3.2.3) Note that the SEP flag is
      only a hint, and its presence or absence may not be used to
      disqualify a given DNSKEY RR from use as a KSK or ZSK during
      validation.

      The original definition of SEPs was in [RFC3757].  That definition
      clearly indicated that the SEP was a key, not just a bit in the
      key.  The abstract of [RFC3757] says: "With the Delegation Signer
      (DS) resource record (RR), the concept of a public key acting as a
      secure entry point (SEP) has been introduced.  During exchanges of
      public keys with the parent there is a need to differentiate SEP
      keys from other public keys in the Domain Name System KEY (DNSKEY)
      resource record set.  A flag bit in the DNSKEY RR is defined to

      indicate that DNSKEY is to be used as a SEP."  That definition of
      the SEP as a key was made obsolete by [RFC4034], and the
      definition from [RFC6781] is consistent with [RFC4034].

   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."  (Quoted from
      [RFC4033], Section 2)

   DNSSEC Policy (DP):  A statement that "sets forth the security
      requirements and standards to be implemented for a DNSSEC-signed
      zone."  (Quoted from [RFC6841], Section 2)

   DNSSEC Practice Statement (DPS):  "A practices disclosure document
      that may support and be a supplemental document to the DNSSEC
      Policy (if such exists), and it states how the management of a
      given zone implements procedures and controls at a high level."
      (Quoted from [RFC6841], Section 2)

   Hardware security module (HSM):  A specialized piece of hardware that
      is used to create keys for signatures and to sign messages without
      ever disclosing the private key.  In DNSSEC, HSMs are often used
      to hold the private keys for KSKs and ZSKs and to create the
      signatures used in RRSIG records at periodic intervals.

   Signing software:  Authoritative DNS servers that support DNSSEC
      often contain software that facilitates the creation and
      maintenance of DNSSEC signatures in zones.  There is also stand-
      alone software that can be used to sign a zone regardless of
      whether the authoritative server itself supports signing.
      Sometimes signing software can support particular HSMs as part of
      the signing process.

11.  DNSSEC States

   A validating resolver can determine that a response is in one of four
   states: secure, insecure, bogus, or indeterminate.  These states are
   defined in [RFC4033] and [RFC4035], although the definitions in the
   two documents differ a bit.  This document makes no effort to
   reconcile the definitions in the two documents, and takes no position
   as to whether they need to be reconciled.

   Section 5 of [RFC4033] says:

      A validating resolver can determine the following 4 states:

      Secure: The validating resolver has a trust anchor, has a chain
         of trust, and is able to verify all the signatures in the
         response.

      Insecure: The validating resolver has a trust anchor, a chain
         of trust, and, at some delegation point, signed proof of the
         non-existence of a DS record.  This indicates that subsequent
         branches in the tree are provably insecure.  A validating
         resolver may have a local policy to mark parts of the domain
         space as insecure.

      Bogus: The validating resolver has a trust anchor and a secure
         delegation indicating that subsidiary data is signed, but
         the response fails to validate for some reason: missing
         signatures, expired signatures, signatures with unsupported
         algorithms, data missing that the relevant NSEC RR says
         should be present, and so forth.

      Indeterminate: There is no trust anchor that would indicate that a
         specific portion of the tree is secure.  This is the default
         operation mode.

   Section 4.3 of [RFC4035] says:

      A security-aware resolver must be able to distinguish between four
      cases:

      Secure: An RRset for which the resolver is able to build a chain
          of signed DNSKEY and DS RRs from a trusted security anchor to
          the RRset.  In this case, the RRset should be signed and is
          subject to signature validation, as described above.

      Insecure: An RRset for which the resolver knows that it has no
         chain of signed DNSKEY and DS RRs from any trusted starting
         point to the RRset.  This can occur when the target RRset lies
         in an unsigned zone or in a descendent [sic] of an unsigned
         zone.  In this case, the RRset may or may not be signed, but
         the resolver will not be able to verify the signature.

      Bogus: An RRset for which the resolver believes that it ought to
         be able to establish a chain of trust but for which it is
         unable to do so, either due to signatures that for some reason
         fail to validate or due to missing data that the relevant
         DNSSEC RRs indicate should be present.  This case may indicate

         an attack but may also indicate a configuration error or some
         form of data corruption.

      Indeterminate: An RRset for which the resolver is not able to
         determine whether the RRset should be signed, as the resolver
         is not able to obtain the necessary DNSSEC RRs.  This can occur
         when the security-aware resolver is not able to contact
         security-aware name servers for the relevant zones.

12.  Security Considerations

   These definitions do not change any security considerations for the
   DNS.

13.  IANA Considerations

   This document has no IANA actions.