doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc8198.txt b/doc/rfc/rfc8198.txt
new file mode 100644
index 0000000..e2a1107
--- /dev/null
+++ b/doc/rfc/rfc8198.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       K. Fujiwara
+Request for Comments: 8198                                          JPRS
+Updates: 4035                                                    A. Kato
+Category: Standards Track                                      Keio/WIDE
+ISSN: 2070-1721                                                W. Kumari
+                                                                  Google
+                                                               July 2017
+
+
+                Aggressive Use of DNSSEC-Validated Cache
+
+Abstract
+
+   The DNS relies upon caching to scale; however, the cache lookup
+   generally requires an exact match.  This document specifies the use
+   of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers
+   to generate negative answers within a range and positive answers from
+   wildcards.  This increases performance, decreases latency, decreases
+   resource utilization on both authoritative and recursive servers, and
+   increases privacy.  Also, it may help increase resilience to certain
+   DoS attacks in some circumstances.
+
+   This document updates RFC 4035 by allowing validating resolvers to
+   generate negative answers based upon NSEC/NSEC3 records and positive
+   answers in the presence of wildcards.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8198.
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara, et al.             Standards Track                    [Page 1]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
+   4.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   5.  Aggressive Use of DNSSEC-Validated Cache  . . . . . . . . . .   6
+     5.1.  NSEC  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     5.2.  NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     5.3.  Wildcards . . . . . . . . . . . . . . . . . . . . . . . .   6
+     5.4.  Consideration on TTL  . . . . . . . . . . . . . . . . . .   7
+   6.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
+   7.  Update to RFC 4035  . . . . . . . . . . . . . . . . . . . . .   8
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
+   Appendix A.  Detailed Implementation Notes  . . . . . . . . . . .  11
+   Appendix B.  Procedure for Determining ENT vs. NXDOMAIN with NSEC  11
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara, et al.             Standards Track                    [Page 2]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+1.  Introduction
+
+   A DNS negative cache exists, and is used to cache the fact that an
+   RRset does not exist.  This method of negative caching requires exact
+   matching; this leads to unnecessary additional lookups, increases
+   latency, leads to extra resource utilization on both authoritative
+   and recursive servers, and decreases privacy by leaking queries.
+
+   This document updates RFC 4035 to allow resolvers to use NSEC/NSEC3
+   resource records to synthesize negative answers from the information
+   they have in the cache.  This allows validating resolvers to respond
+   with a negative answer immediately if the name in question falls into
+   a range expressed by an NSEC/NSEC3 resource record already in the
+   cache.  It also allows the synthesis of positive answers in the
+   presence of wildcard records.
+
+   Aggressive negative caching was first proposed in Section 6 of DNSSEC
+   Lookaside Validation (DLV) [RFC5074] in order to find covering NSEC
+   records efficiently.
+
+   [RFC8020] and [RES-IMPROVE] propose steps to using NXDOMAIN
+   information for more effective caching.  This document takes this
+   technique further.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Many of the specialized terms used in this document are defined in
+   DNS Terminology [RFC7719].
+
+   The key words "source of synthesis" in this document are to be
+   interpreted as described in [RFC4592].
+
+3.  Problem Statement
+
+   The DNS negative cache caches negative (non-existent) information,
+   and requires an exact match in most instances [RFC2308].
+
+   Assume that the (DNSSEC-signed) "example.com" zone contains:
+
+   albatross.example.com. IN A 192.0.2.1
+   elephant.example.com.  IN A 192.0.2.2
+   zebra.example.com.     IN A 192.0.2.3
+
+
+
+Fujiwara, et al.             Standards Track                    [Page 3]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+   If a validating resolver receives a query for cat.example.com, it
+   contacts its resolver (which may be itself) to query the example.com
+   servers and will get back an NSEC record stating that there are no
+   records (alphabetically) between albatross and elephant, or an NSEC3
+   record stating there is nothing between two hashed names.  The
+   resolver then knows that cat.example.com does not exist; however, it
+   does not use the fact that the proof covers a range (albatross to
+   elephant) to suppress queries for other labels that fall within this
+   range.  This means that if the validating resolver gets a query for
+   ball.example.com (or dog.example.com) it will once again go off and
+   query the example.com servers for these names.
+
+   Apart from wasting bandwidth, this also wastes resources on the
+   recursive server (it needs to keep state for outstanding queries),
+   wastes resources on the authoritative server (it has to answer
+   additional questions), increases latency (the end user has to wait
+   longer than necessary to get back an NXDOMAIN answer), can be used by
+   attackers to cause a DoS, and also has privacy implications (e.g.,
+   typos leak out further than necessary).
+
+   Another example: assume that the (DNSSEC-signed) "example.org" zone
+   contains:
+
+   avocado.example.org.   IN A 192.0.2.1
+   *.example.org.         IN A 192.0.2.2
+   zucchini.example.org.  IN A 192.0.2.3
+
+   If a query is received for leek.example.org, the system contacts its
+   resolver (which may be itself) to query the example.org servers and
+   will get back an NSEC record stating that there are no records
+   (alphabetically) between avocado and zucchini (or an NSEC3 record
+   stating there is nothing between two hashed names), as well as an
+   answer for leek.example.org, with the label count of the signature
+   set to two (see [RFC7129], Section 5.3 for more details).
+
+   If the validating resolver gets a query for banana.example.org, it
+   will once again go off and query the example.org servers for
+   banana.example.org (even though it already has proof that there is a
+   wildcard record) -- just like above, this has privacy implications,
+   wastes resources, can be used to contribute to a DoS, etc.
+
+4.  Background
+
+   DNSSEC [RFC4035] and [RFC5155] both provide "authenticated denial of
+   existence"; this is a cryptographic proof that the queried-for name
+   does not exist or the type does not exist.  Proof that a name does
+   not exist is accomplished by providing a (DNSSEC-secured) record
+   containing the names that appear alphabetically before and after the
+
+
+
+Fujiwara, et al.             Standards Track                    [Page 4]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+   queried-for name.  In the first example above, if the (DNSSEC-
+   validating) recursive server were to query for dog.example.com, it
+   would receive a (signed) NSEC record stating that there are no labels
+   between "albatross" and "elephant" (or, for NSEC3, a similar pair of
+   hashed names).  This is a signed, cryptographic proof that these
+   names are the ones before and after the queried-for label.  As
+   dog.example.com falls within this range, the recursive server knows
+   that dog.example.com really does not exist.  Proof that a type does
+   not exist is accomplished by providing a (DNSSEC-secured) record
+   containing the queried-for name, and a type bitmap that does not
+   include the requested type.
+
+   This document specifies that this NSEC/NSEC3 record should be used to
+   generate negative answers for any queries that the validating server
+   receives that fall within the range covered by the record (for the
+   TTL for the record).  This document also specifies that a positive
+   answer should be generated for any queries that the validating server
+   receives that are proven to be covered by a wildcard record.
+
+   Section 4.5 of [RFC4035] says:
+
+      In theory, a resolver could use wildcards or NSEC RRs to generate
+      positive and negative responses (respectively) until the TTL or
+      signatures on the records in question expire.  However, it seems
+      prudent for resolvers to avoid blocking new authoritative data or
+      synthesizing new data on their own.  Resolvers that follow this
+      recommendation will have a more consistent view of the namespace.
+
+   And, earlier, Section 4.5 of [RFC4035] says:
+
+      The reason for these recommendations is that, between the initial
+      query and the expiration of the data from the cache, the
+      authoritative data might have been changed (for example, via
+      dynamic update).
+
+   In other words, if a resolver generates negative answers from an NSEC
+   record, it will not send any queries for names within that NSEC range
+   (for the TTL).  If a new name is added to the zone during this
+   interval, the resolver will not know this.  Similarly, if the
+   resolver is generating responses from a wildcard record, it will
+   continue to do so (for the TTL).
+
+   We believe that this recommendation can be relaxed because, in the
+   absence of this technique, a lookup for the exact name could have
+   come in during this interval, and so a negative answer could already
+   be cached (see [RFC2308] for more background).  This means that zone
+   operators should have no expectation that an added name would work
+   immediately.  With DNSSEC and aggressive use of DNSSEC-validated
+
+
+
+Fujiwara, et al.             Standards Track                    [Page 5]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+   cache, the TTL of the NSEC/NSEC3 record and the SOA.MINIMUM field are
+   the authoritative statement of how quickly a name can start working
+   within a zone.
+
+5.  Aggressive Use of DNSSEC-Validated Cache
+
+   This document relaxes the restriction given in Section 4.5 of
+   [RFC4035].  See Section 7 for more detail.
+
+   If the negative cache of the validating resolver has sufficient
+   information to validate the query, the resolver SHOULD use NSEC,
+   NSEC3, and wildcard records to synthesize answers as described in
+   this document.  Otherwise, it MUST fall back to send the query to the
+   authoritative DNS servers.
+
+5.1.  NSEC
+
+   The validating resolver needs to check the existence of an NSEC RR
+   matching/covering the source of synthesis and an NSEC RR covering the
+   query name.
+
+   If denial of existence can be determined according to the rules set
+   out in Section 5.4 of [RFC4035], using NSEC records in the cache,
+   then the resolver can immediately return an NXDOMAIN or NODATA (as
+   appropriate) response.
+
+5.2.  NSEC3
+
+   NSEC3 aggressive negative caching is more difficult than NSEC
+   aggressive caching.  If the zone is signed with NSEC3, the validating
+   resolver needs to check the existence of non-terminals and wildcards
+   that derive from query names.
+
+   If denial of existence can be determined according to the rules set
+   out in [RFC5155], Sections 8.4, 8.5, 8.6, and 8.7, using NSEC3
+   records in the cache, then the resolver can immediately return an
+   NXDOMAIN or NODATA response (as appropriate).
+
+   If a covering NSEC3 RR has an Opt-Out flag, the covering NSEC3 RR
+   does not prove the non-existence of the domain name and the
+   aggressive negative caching is not possible for the domain name.
+
+5.3.  Wildcards
+
+   The last paragraph of [RFC4035], Section 4.5 also discusses the use
+   of wildcards and NSEC RRs to generate positive responses and
+   recommends that it not be relied upon.  Just like the case for the
+
+
+
+
+Fujiwara, et al.             Standards Track                    [Page 6]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+   aggressive use of NSEC/NSEC3 for negative answers, we revise this
+   recommendation.
+
+   As long as the validating resolver can determine that a name would
+   not exist without the wildcard match, determined according to the
+   rules set out in Section 5.3.4 of [RFC4035] (NSEC), or in Section 8.8
+   of [RFC5155], it SHOULD synthesize an answer (or NODATA response) for
+   that name using the cache-deduced wildcard.  If the corresponding
+   wildcard record is not in the cache, it MUST fall back to send the
+   query to the authoritative DNS servers.
+
+5.4.  Consideration on TTL
+
+   The TTL value of negative information is especially important,
+   because newly added domain names cannot be used while the negative
+   information is effective.
+
+   Section 5 of [RFC2308] suggests a maximum default negative cache TTL
+   value of 3 hours (10800).  It is RECOMMENDED that validating
+   resolvers limit the maximum effective TTL value of negative responses
+   (NSEC/NSEC3 RRs) to this same value.
+
+   Section 5 of [RFC2308] also states that a negative cache entry TTL is
+   taken from the minimum of the SOA.MINIMUM field and SOA's TTL.  This
+   can be less than the TTL of an NSEC or NSEC3 record, since their TTL
+   is equal to the SOA.MINIMUM field (see [RFC4035], Section 2.3 and
+   [RFC5155], Section 3).
+
+   A resolver that supports aggressive use of NSEC and NSEC3 SHOULD
+   reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM
+   field in the authority section of a negative response, if SOA.MINIMUM
+   is smaller.
+
+6.  Benefits
+
+   The techniques described in this document provide a number of
+   benefits, including (in no specific order):
+
+   Reduced latency:  By answering directly from cache, validating
+      resolvers can immediately inform clients that the name they are
+      looking for does not exist, improving the user experience.
+
+   Decreased recursive server load:  By answering queries from the cache
+      by synthesizing answers, validating servers avoid having to send a
+      query and wait for a response.  In addition to decreasing the
+      bandwidth used, it also means that the server does not need to
+      allocate and maintain state, thereby decreasing memory and CPU
+      load.
+
+
+
+Fujiwara, et al.             Standards Track                    [Page 7]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+   Decreased authoritative server load:  Because recursive servers can
+      answer queries without asking the authoritative server, the
+      authoritative servers receive fewer queries.  This decreases the
+      authoritative server bandwidth, queries per second, and CPU
+      utilization.
+
+   The scale of the benefit depends upon multiple factors, including the
+   query distribution.  For example, at the time of this writing, around
+   65% of queries to root name servers result in NXDOMAIN responses (see
+   statistics from [ROOT-SERVERS]); this technique will eliminate a
+   sizable quantity of these.
+
+   The technique described in this document may also mitigate so-called
+   "random QNAME attacks", in which attackers send many queries for
+   random subdomains to resolvers.  As the resolver will not have the
+   answers cached, it has to ask external servers for each random query,
+   leading to a DoS on the authoritative servers (and often resolvers).
+   The technique may help mitigate these attacks by allowing the
+   resolver to answer directly from the cache for any random queries
+   that fall within already requested ranges.  It will not always work
+   as an effective defense, not least because not many zones are DNSSEC
+   signed at all -- but it will still provide an additional layer of
+   defense.
+
+   As these benefits are only accrued by those using DNSSEC, it is hoped
+   that these techniques will lead to more DNSSEC deployment.
+
+7.  Update to RFC 4035
+
+   Section 4.5 of [RFC4035] shows that "In theory, a resolver could use
+   wildcards or NSEC RRs to generate positive and negative responses
+   (respectively) until the TTL or signatures on the records in question
+   expire.  However, it seems prudent for resolvers to avoid blocking
+   new authoritative data or synthesizing new data on their own.
+   Resolvers that follow this recommendation will have a more consistent
+   view of the namespace".
+
+   The paragraph is updated as follows:
+
+   +-----------------------------------------------------------------+
+   |  Once the records are validated, DNSSEC-enabled validating      |
+   |  resolvers SHOULD use wildcards and NSEC/NSEC3 resource records |
+   |  to generate positive and negative responses until the          |
+   |  effective TTLs or signatures for those records expire.         |
+   +-----------------------------------------------------------------+
+
+
+
+
+
+
+Fujiwara, et al.             Standards Track                    [Page 8]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+8.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+9.  Security Considerations
+
+   Use of NSEC/NSEC3 resource records without DNSSEC validation may
+   create serious security issues, and so this technique requires DNSSEC
+   validation.
+
+   Newly registered resource records may not be used immediately.
+   However, choosing a suitable TTL value and a negative cache TTL value
+   (SOA.MINIMUM field) will mitigate the delay concern, and it is not a
+   security problem.
+
+   It is also suggested to limit the maximum TTL value of NSEC/NSEC3
+   resource records in the negative cache to, for example, 10800 seconds
+   (3 hours), to mitigate this issue.
+
+   Although the TTL of NSEC/NSEC3 records is typically fairly short
+   (minutes or hours), their RRSIG expiration time can be much further
+   in the future (weeks).  An attacker who is able to successfully spoof
+   responses might poison a cache with old NSEC/NSEC3 records.  If the
+   resolver is not making aggressive use of NSEC/NSEC3, the attacker has
+   to repeat the attack for every query.  If the resolver is making
+   aggressive use of NSEC/NSEC3, one successful attack would be able to
+   suppress many queries for new names, up to the negative TTL.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+Fujiwara, et al.             Standards Track                    [Page 9]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+   [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>.
+
+   [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>.
+
+   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
+              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
+              2015, <http://www.rfc-editor.org/info/rfc7719>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <http://www.rfc-editor.org/info/rfc8174>.
+
+10.2.  Informative References
+
+   [RES-IMPROVE]
+              Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
+              Resolvers for Resiliency, Robustness, and Responsiveness",
+              Work in Progress, draft-vixie-dnsext-resimprove-00, June
+              2010.
+
+   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+              DOI 10.17487/RFC5074, November 2007,
+              <http://www.rfc-editor.org/info/rfc5074>.
+
+   [RFC8020]  Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
+              Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
+              November 2016, <http://www.rfc-editor.org/info/rfc8020>.
+
+   [ROOT-SERVERS]
+              "Root Server Technical Operations Assn",
+              <http://www.root-servers.org/>.
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara, et al.             Standards Track                   [Page 10]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+Appendix A.  Detailed Implementation Notes
+
+   o  Previously, cached negative responses were indexed by QNAME,
+      QCLASS, QTYPE, and the setting of the CD bit (see RFC 4035,
+      Section 4.7), and only queries matching the index key would be
+      answered from the cache.  With aggressive negative caching, the
+      validator, in addition to checking to see if the answer is in its
+      cache before sending a query, checks to see whether any cached and
+      validated NSEC record denies the existence of the sought
+      record(s).  Using aggressive negative caching, a validator will
+      not make queries for any name covered by a cached and validated
+      NSEC record.  Furthermore, a validator answering queries from
+      clients will synthesize a negative answer (or NODATA response)
+      whenever it has an applicable validated NSEC in its cache unless
+      the CD bit was set on the incoming query.  (Imported from
+      Section 6 of [RFC5074].)
+
+   o  Implementing aggressive negative caching suggests that a validator
+      will need to build an ordered data structure of NSEC and NSEC3
+      records for each signer domain name of NSEC/NSEC3 records in order
+      to efficiently find covering NSEC/NSEC3 records.  Call the table
+      as "NSEC_TABLE".  (Imported from Section 6.1 of [RFC5074] and
+      expanded.)
+
+   o  The aggressive negative caching may be inserted at the cache
+      lookup part of the recursive resolvers.
+
+   o  If errors happen in an aggressive negative caching algorithm,
+      resolvers MUST fall back to resolve the query as usual.  "Resolve
+      the query as usual" means that the resolver must process the query
+      as though it does not implement aggressive negative caching.
+
+Appendix B.  Procedure for Determining ENT vs. NXDOMAIN with NSEC
+
+   This procedure outlines how to determine if a given name does not
+   exist, or is an ENT (empty non-terminal; see [RFC5155], Section 1.3)
+   with NSEC.
+
+   If the NSEC record has not been verified as secure, discard it.
+
+   If the given name sorts before or matches the NSEC owner name,
+   discard it as it does not prove the NXDOMAIN or ENT.
+
+   If the given name is a subdomain of the NSEC owner name and the NS
+   bit is present and the SOA bit is absent, then discard the NSEC as it
+   is from a parent zone.
+
+
+
+
+
+Fujiwara, et al.             Standards Track                   [Page 11]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+   If the next domain name sorts after the NSEC owner name and the given
+   name sorts after or matches next domain name, then discard the NSEC
+   record as it does not prove the NXDOMAIN or ENT.
+
+   If the next domain name sorts before or matches the NSEC owner name
+   and the given name is not a subdomain of the next domain name, then
+   discard the NSEC as it does not prove the NXDOMAIN or ENT.
+
+   You now have an NSEC record that proves the NXDOMAIN or ENT.
+
+   If the next domain name is a subdomain of the given name, you have an
+   ENT.  Otherwise, you have an NXDOMAIN.
+
+Acknowledgments
+
+   The authors gratefully acknowledge DNSSEC Lookaside Validation (DLV)
+   [RFC5074] author Samuel Weiler and the Unbound developers.
+
+   Thanks to Mark Andrews for providing the helpful notes for
+   implementors provided in Appendix B.
+
+   The authors would like to specifically thank Stephane Bortzmeyer (for
+   standing next to and helping edit), Ralph Dolmans, Tony Finch, Tatuya
+   JINMEI for extensive review and comments, and also Mark Andrews,
+   Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob Harold, Shumon
+   Huque, John Levine, Pieter Lexis, Matthijs Mekking (who even sent
+   pull requests!), and Ondrej Sury.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara, et al.             Standards Track                   [Page 12]
+
+RFC 8198                    NSEC/NSEC3 Usage                   July 2017
+
+
+Authors' Addresses
+
+   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
+
+
+   Akira Kato
+   Keio University/WIDE Project
+   Graduate School of Media Design, 4-1-1 Hiyoshi
+   Kohoku, Yokohama  223-8526
+   Japan
+
+   Phone: +81 45 564 2490
+   Email: kato@wide.ad.jp
+
+
+   Warren Kumari
+   Google
+   1600 Amphitheatre Parkway
+   Mountain View, CA  94043
+   United States of America
+
+   Email: warren@kumari.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fujiwara, et al.             Standards Track                   [Page 13]
+