tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7719

 
 
 

DNS Terminology

Part 2 of 2, p. 17 to 27
Prev RFC Part

 


prevText      Top      ToC       Page 17 
7.  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 superior zones 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, or 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.

Top      Up      ToC       Page 18 
8.  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.)

   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.

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

Top      Up      ToC       Page 19 
   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
      against zone enumeration and support Opt-Out.  NSEC3 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)

   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.

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

Top      Up      ToC       Page 20 
   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) Note that the
      roles KSK and ZSK are not mutually exclusive: a single key can be
      both KSK and ZSK at the same time.  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.

   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)

9.  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 two definitions
   differ a bit.  This document makes no effort to reconcile the two
   definitions, and takes no position as to whether they need to be
   reconciled.

Top      Up      ToC       Page 21 
   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.

Top      Up      ToC       Page 22 
      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.

10.  Security Considerations

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

11.  References

11.1.  Normative References

   [RFC882]   Mockapetris, P., "Domain names: Concepts and facilities",
              RFC 882, DOI 10.17487/RFC0882, November 1983,
              <http://www.rfc-editor.org/info/rfc882>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              DOI 10.17487/RFC1123, October 1989,
              <http://www.rfc-editor.org/info/rfc1123>.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996, <http://www.rfc-editor.org/info/rfc1996>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <http://www.rfc-editor.org/info/rfc2136>.

Top      Up      ToC       Page 23 
   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <http://www.rfc-editor.org/info/rfc2181>.

   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
              DOI 10.17487/RFC2182, July 1997,
              <http://www.rfc-editor.org/info/rfc2182>.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
              <http://www.rfc-editor.org/info/rfc2308>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <http://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <http://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <http://www.rfc-editor.org/info/rfc4035>.

   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
              System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
              <http://www.rfc-editor.org/info/rfc4592>.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
              <http://www.rfc-editor.org/info/rfc5155>.

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
              <http://www.rfc-editor.org/info/rfc5730>.

   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
              <http://www.rfc-editor.org/info/rfc5936>.

Top      Up      ToC       Page 24 
   [RFC6561]  Livingood, J., Mody, N., and M. O'Reirdan,
              "Recommendations for the Remediation of Bots in ISP
              Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012,
              <http://www.rfc-editor.org/info/rfc6561>.

   [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
              DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
              <http://www.rfc-editor.org/info/rfc6672>.

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,
              <http://www.rfc-editor.org/info/rfc6781>.

   [RFC6840]  Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
              Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
              DOI 10.17487/RFC6840, February 2013,
              <http://www.rfc-editor.org/info/rfc6840>.

   [RFC6841]  Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
              Framework for DNSSEC Policies and DNSSEC Practice
              Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
              <http://www.rfc-editor.org/info/rfc6841>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <http://www.rfc-editor.org/info/rfc6891>.

   [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
              DNSSEC Delegation Trust Maintenance", RFC 7344,
              DOI 10.17487/RFC7344, September 2014,
              <http://www.rfc-editor.org/info/rfc7344>.

11.2.  Informative References

   [DBOUND]   IETF, "Domain Boundaries (dbound) Working Group", 2015,
              <https://datatracker.ietf.org/wg/dbound/charter/>.

   [RFC819]   Su, Z. and J. Postel, "The Domain Naming Convention for
              Internet User Applications", RFC 819,
              DOI 10.17487/RFC0819, August 1982,
              <http://www.rfc-editor.org/info/rfc819>.

   [RFC952]   Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
              host table specification", RFC 952, DOI 10.17487/RFC0952,
              October 1985, <http://www.rfc-editor.org/info/rfc952>.

Top      Up      ToC       Page 25 
   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              DOI 10.17487/RFC1995, August 1996,
              <http://www.rfc-editor.org/info/rfc1995>.

   [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
              DOI 10.17487/RFC3912, September 2004,
              <http://www.rfc-editor.org/info/rfc3912>.

   [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
              RFC 4641, DOI 10.17487/RFC4641, September 2006,
              <http://www.rfc-editor.org/info/rfc4641>.

   [RFC4697]  Larson, M. and P. Barber, "Observed DNS Resolution
              Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697,
              October 2006, <http://www.rfc-editor.org/info/rfc4697>.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
              December 2006, <http://www.rfc-editor.org/info/rfc4786>.

   [RFC4956]  Arends, R., Kosters, M., and D. Blacka, "DNS Security
              (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July
              2007, <http://www.rfc-editor.org/info/rfc4956>.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
              BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
              <http://www.rfc-editor.org/info/rfc5625>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <http://www.rfc-editor.org/info/rfc5890>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <http://www.rfc-editor.org/info/rfc5891>.

   [RFC5892]  Faltstrom, P., Ed., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, DOI 10.17487/RFC5892, August 2010,
              <http://www.rfc-editor.org/info/rfc5892>.

   [RFC5893]  Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
              for Internationalized Domain Names for Applications
              (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
              <http://www.rfc-editor.org/info/rfc5893>.

Top      Up      ToC       Page 26 
   [RFC5894]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Background, Explanation, and
              Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
              <http://www.rfc-editor.org/info/rfc5894>.

   [RFC6055]  Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
              Encodings for Internationalized Domain Names", RFC 6055,
              DOI 10.17487/RFC6055, February 2011,
              <http://www.rfc-editor.org/info/rfc6055>.

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              DOI 10.17487/RFC6265, April 2011,
              <http://www.rfc-editor.org/info/rfc6265>.

   [RFC6365]  Hoffman, P. and J. Klensin, "Terminology Used in
              Internationalization in the IETF", BCP 166, RFC 6365,
              DOI 10.17487/RFC6365, September 2011,
              <http://www.rfc-editor.org/info/rfc6365>.

   [RFC7129]  Gieben, R. and W. Mekking, "Authenticated Denial of
              Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
              February 2014, <http://www.rfc-editor.org/info/rfc7129>.

   [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", RFC 7480,
              DOI 10.17487/RFC7480, March 2015,
              <http://www.rfc-editor.org/info/rfc7480>.

   [RFC7481]  Hollenbeck, S. and N. Kong, "Security Services for the
              Registration Data Access Protocol (RDAP)", RFC 7481,
              DOI 10.17487/RFC7481, March 2015,
              <http://www.rfc-editor.org/info/rfc7481>.

   [RFC7482]  Newton, A. and S. Hollenbeck, "Registration Data Access
              Protocol (RDAP) Query Format", RFC 7482,
              DOI 10.17487/RFC7482, March 2015,
              <http://www.rfc-editor.org/info/rfc7482>.

   [RFC7483]  Newton, A. and S. Hollenbeck, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", RFC 7483,
              DOI 10.17487/RFC7483, March 2015,
              <http://www.rfc-editor.org/info/rfc7483>.

   [RFC7484]  Blanchet, M., "Finding the Authoritative Registration Data
              (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
              2015, <http://www.rfc-editor.org/info/rfc7484>.

Top      Up      ToC       Page 27 
   [RFC7485]  Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
              "Inventory and Analysis of WHOIS Registration Objects",
              RFC 7485, DOI 10.17487/RFC7485, March 2015,
              <http://www.rfc-editor.org/info/rfc7485>.

Acknowledgements

   The authors gratefully acknowledge all of the authors of DNS-related
   RFCs that proceed this one.  Comments from Tony Finch, Stephane
   Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John
   Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman,
   David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis,
   John Klensin, David Black, and many others in the DNSOP Working Group
   have helped shape this document.

Authors' Addresses

   Paul Hoffman
   ICANN

   Email: paul.hoffman@icann.org


   Andrew Sullivan
   Dyn
   150 Dow Street, Tower 2
   Manchester, NH  03101
   United States

   Email: asullivan@dyn.com


   Kazunori Fujiwara
   Japan Registry Services Co., Ltd.
   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
   Chiyoda-ku, Tokyo  101-0065
   Japan

   Phone: +81 3 5215 8451
   Email: fujiwara@jprs.co.jp