Skip to main content

Delegation Revalidation by DNS Resolvers
draft-ietf-dnsop-ns-revalidation-06

Document Type Active Internet-Draft (dnsop WG)
Authors Shumon Huque , Paul A. Vixie , Willem Toorop
Last updated 2024-03-17
Replaces draft-huque-dnsop-ns-revalidation
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Reviews
Additional resources GitHub Repository
Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-dnsop-ns-revalidation-06
Domain Name System Operations                                   S. Huque
Internet-Draft                                                Salesforce
Intended status: Standards Track                                P. Vixie
Expires: 19 September 2024                              SIE Europe, U.G.
                                                               W. Toorop
                                                              NLnet Labs
                                                           18 March 2024

                Delegation Revalidation by DNS Resolvers
                  draft-ietf-dnsop-ns-revalidation-06

Abstract

   This document recommends improved DNS [RFC1034] [RFC1035] resolver
   behavior with respect to the processing of Name Server (NS) resource
   record sets (RRset) during iterative resolution.  When following a
   referral response from an authoritative server to a child zone, DNS
   resolvers should explicitly query the authoritative NS RRset at the
   apex of the child zone and cache this in preference to the NS RRset
   on the parent side of the zone cut.  The (A and AAAA) address RRsets
   in the additional section from referral responses and authoritative
   NS answers for the names of the NS RRset, should similarly be re-
   queried and used to replace the entries with the lower
   trustworthiness ranking in cache.  Resolvers should also periodically
   revalidate the child delegation by re-querying the parent zone at the
   expiration of the TTL of the parent side NS RRset.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/.

   Discussion of this document takes place on the DNSOP Working Group
   mailing list (mailto:dnsop@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/dnsop/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/dnsop/.

   Source for this draft and an issue tracker can be found at
   https://github.com/shuque/ns-revalidation.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Huque, et al.           Expires 19 September 2024               [Page 1]
Internet-Draft         DNS Delegation Revalidation            March 2024

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 19 September 2024.

Copyright Notice

   Copyright (c) 2024 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 (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Upgrading NS RRset Credibility  . . . . . . . . . . . . . . .   5
   4.  Upgrading A and AAAA RRset Credibility  . . . . . . . . . . .   6
   5.  Delegation Revalidation . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

Huque, et al.           Expires 19 September 2024               [Page 2]
Internet-Draft         DNS Delegation Revalidation            March 2024

1.  Introduction

   This document recommends improved DNS resolver behavior with respect
   to the processing of NS record sets during iterative resolution.  The
   first recommendation is that resolvers, when following a referral
   response from an authoritative server to a child zone, should
   explicitly query the authoritative NS RRset at the apex of the child
   zone and cache this in preference to the NS RRset on the parent side
   of the zone cut.  The address records in the additional section from
   the referral response (as glue) or authoritative NS response that
   match the names of the NS RRset should similarly be required if they
   are cached non-authoritatively.  The authoritative answers from those
   queries should replace the cached non-authoritative A and AAAA
   RRsets.  The second recommendation is to revalidate the delegation by
   re-querying the parent zone at the expiration of the TTL of the
   parent side NS RRset.

2.  Motivation

   There is wide variability in the behavior of deployed DNS resolvers
   today with respect to how they process delegation records.  Some of
   them prefer the parent NS set, some prefer the child, and for others,
   what they preferentially cache depends on the dynamic state of
   queries and responses they have processed.  This document aims to
   bring more commonality and predictability by standardizing the
   behavior in a way that comports with the DNS protocol.  Another goal
   is to improve DNS security.

Huque, et al.           Expires 19 September 2024               [Page 3]
Internet-Draft         DNS Delegation Revalidation            March 2024

   The delegation NS RRset at the bottom of the parent zone and the apex
   NS RRset in the child zone are unsynchronized in the DNS protocol.
   [RFC1034] Section 4.2.2 says "The administrators of both zones should
   insure that the NS and glue RRs which mark both sides of the cut are
   consistent and remain so.".  But for a variety of reasons they could
   not be.  Officially, a child zone's apex NS RRset is authoritative
   and thus has a higher cache credibility than the parent's delegation
   NS RRset, which is non-authoritative glue [RFC2181], Section 5.4.1.
   "Ranking data", and Section 6.1.  "Zone authority").  Hence the NS
   RRset "below the zone cut" should immediately replace the parent's
   delegating NS RRset in cache when an iterative caching DNS resolver
   crosses a zone boundary.  However, this can only happen if (1) the
   resolver receives the authoritative NS RRset in the Authority section
   of a response from the child zone, which is not mandatory, or (2) if
   the resolver explicitly issues an NS RRset query to the child zone as
   part of its iterative resolution algorithm.  In the absence of this,
   it is possible for an iterative caching resolver to never learn the
   authoritative NS RRset for a zone, unless a downstream client of the
   resolver explicitly issues such an NS query, which is not something
   that normal enduser applications do, and thus cannot be relied upon
   to occur with any regularity.

   Increasingly, there is a trend towards minimizing unnecessary data in
   DNS responses.  Several popular DNS implementations default to such a
   configuration (see "minimal-responses" in BIND and NSD).  So, they
   may never include the authoritative NS RRset in the Authority section
   of their responses.

   A common reason that zone owners want to ensure that resolvers place
   the authoritative NS RRset preferentially in their cache is that the
   TTLs may differ between the parent and child side of the zone cut.
   Some DNS Top Level Domains (TLDs) only support long fixed TTLs in
   their delegation NS sets.  This inhibits a child zone owner's ability
   to make more rapid changes to their nameserver configuration using a
   shorter TTL, if resolvers have no systematic mechanism to observe and
   cache the child NS RRset.

   Similarly, a child zone owner may also choose to have longer TTLs in
   their delegation NS sets and address records to decrease the attack
   window for cache poisoning attacks.  For example, at the time of
   writing, root-servers.net has a TTL of 6 weeks for the root server
   identifier address records, where the TTL in the priming response is
   6 days.

   A child zone's delegation still needs to be periodically revalidated
   at the parent to make sure that the parent zone has not legitimately
   re-delegated the zone to a different set of nameservers, or even
   removed the delegation.  Otherwise, resolvers that refresh the TTL of

Huque, et al.           Expires 19 September 2024               [Page 4]
Internet-Draft         DNS Delegation Revalidation            March 2024

   a child NS RRset on subsequent queries or due to pre-fetching, may
   cling to those nameservers long after they have been re-delegated
   elsewhere.  This leads to the second recommendation in this document,
   "Delegation Revalidation" - Resolvers should record the TTL of the
   parent's delegating NS RRset, and use it to trigger a revalidation
   action.  Attacks exploiting lack of this revalidation have been
   described in [GHOST1], [GHOST2].

3.  Upgrading NS RRset Credibility

   *  When a referral response is received during iteration, a
      validation query should be sent in parallel with the resolution of
      the triggering query, to the delegated nameservers for the newly
      discovered zone cut.  Note that validating resolvers today, when
      following a secure referral, already need to dispatch a query to
      the delegated nameservers for the DNSKEY RRset, so this validation
      query could be sent in parallel with that DNSKEY query.

   *  A validation query consists of a query for the child's apex NS
      RRset, sent to the newly discovered delegation's nameservers.
      Normal iterative logic applies to the processing of responses to
      validation queries, including storing the results in cache, trying
      the next server on SERVFAIL or timeout, and so on.  Positive
      responses to this validation query will be cached with an
      authoritative data ranking.  Successive queries directed to the
      same zone will be directed to the nameservers listed in the
      child's apex, due to the ranking of this answer.  If the
      validation query fails, the parent NS RRset will remain the one
      with the highest ranking and will be used for successive queries.

   *  Additional validation queries for the "glue" resource records of
      referral responses (if not already authoritatively present in
      cache) may be sent with the validation query for the NS RRset as
      well.  Positive responses will be cached authoritatively and
      replace the non authoritative "glue" entries.  Successive queries
      directed to the same zone will be directed to the authoritative
      values for the names of the NS RRset in the referral response.

   *  The names from the NS RRset from a validating NS query may differ
      from the names in NS RRset in the referral response.  Outstanding
      validation queries for "glue" that do not match names in the
      authoritative NS RRset be discarded, or they may be left running
      to completion.  Their result will no longer be used in queries for
      the zone.  Outstanding validation queries for "glue" that do match
      names in the authoritative NS RRset must be left running to
      completion.  They do not need to be re-queried after reception of
      the authoritative NS RRset (see Section 4).

Huque, et al.           Expires 19 September 2024               [Page 5]
Internet-Draft         DNS Delegation Revalidation            March 2024

   *  Resolvers may choose to delay the response to the triggering query
      until both the triggering query and the validation query have been
      answered.  In practice, we expect many implementations may answer
      the triggering query in advance of the validation query for
      performance reasons.  An additional reason is that there are
      unfortunately a number of nameservers in the field that
      (incorrectly) fail to properly answer explicit queries for zone
      apex NS records, and thus the revalidation logic may need to be
      applied lazily and opportunistically to deal with them.  In cases
      where the delegated nameservers respond incorrectly to an NS
      query, the resolver should abandon this algorithm for the zone in
      question and fall back to using only the information from the
      parent's referral response.

   *  If the resolver chooses to delay the response, and there are no
      nameserver names in common between the child's apex NS RRset and
      the parent's delegation NS RRset, then the responses received from
      forwarding the triggering query to the parent's delegated
      nameservers should be discarded after validation, and this query
      should be forwarded again to the child's apex nameservers.

4.  Upgrading A and AAAA RRset Credibility

   Authoritative responses for a zone's NS RRset at the apex can contain
   additional addresses.  A NS RRset validation response is such an
   example of such responses.  A priming response is another example of
   an authoritative zone's NS RRset response [RFC8109].

   Additional addresses in authoritative NS RRset responses SHOULD be
   validated if they are not already authoritatively in cache.  Only
   when such additional addresses are DNSSEC verifiable, (because the
   complete RRset is included, including a verifiable signature for the
   RRset), such additional addresses can be cached authoritatively
   immediately without additional validation queries.  DNSSEC validation
   is enough validation in those cases.  Otherwise, the addresses cannot
   be assumed to be complete or even authoritatively present in the same
   zone, and additional validation queries SHOULD be made for these
   addresses.

   Note that there may be outstanding address validation queries for the
   names of the authoritative NS RRset (from referral address validation
   queries).  In those cases no new validation queries need to be made.

   Resolvers may choose to delay the response to a triggering query
   until it can be verified that the answer came from a name server
   listening on an authoritatively acquired address for an
   authoritatively acquired name.  This would offer the most trustworthy
   responses with the least risk for forgery or eavesdropping.

Huque, et al.           Expires 19 September 2024               [Page 6]
Internet-Draft         DNS Delegation Revalidation            March 2024

5.  Delegation Revalidation

   The essence of this mechanism is re-validation of all delegation
   metadata that directly or indirectly supports an owner name in cache.
   This requires a cache to remember the delegated name server names for
   each zone cut as received from the parent (delegating) zone's name
   servers, and also the TTL of that NS RRset, and the TTL of the
   associated DS RRset (if seen).

   A delegation under re-validation is called a "re-validation point"
   and is "still valid" if its parent zone's servers still respond to an
   in-zone question with a referral to the re-validation point, and if
   that referral overlaps with the previously cached referral by at
   least one name server name, and the DS RRset (if seen) overlaps the
   previously cached DS RRset (if also seen) by at least one delegated
   signer.

   If the response is not a referral or refers to a different zone than
   before, then the shape of the delegation hierarchy has changed.  If
   the response is a referral to the re-validation point but to a wholly
   novel NS RRset or a wholly novel DS RRset, then the authority for
   that zone has changed.  For clarity, this includes transitions
   between empty and non-empty DS RRsets.

   If the shape of the delegation hierarchy or the authority for a zone
   has been found to change, then no currently cached data whose owner
   names are at or below that re-validation point can be used.  Such
   non-use can be by directed garbage collection or lazy generational
   garbage collection or some other method befitting the architecture of
   the cache.  What matters is that the cache behave as though this data
   was removed.

   Since re-validation can discover changes in the shape of the
   delegation hierarchy it is more efficient to re-validate from the top
   (root) downward (to the owner name) since an upper level re-
   validation may obviate lower level re-validations.  What matters is
   that the supporting chain of delegations from the root to the owner
   name be demonstrably valid; further specifics are implementation
   details.

   Re-validation is triggered when delegation meta-data has been cached
   for a period at most exceeding the delegating NS or DS (if seen)
   RRset TTL.  If the corresponding child zone's apex NS RRset TTL is
   smaller than the delegating NS RRset TTL, revalidation should happen
   at that interval instead.  However, resolvers should impose a
   sensitive minimum TTL floor they are willing to endure to avoid
   potential computational DoS attacks inflicted by zones with very
   short TTLs.

Huque, et al.           Expires 19 September 2024               [Page 7]
Internet-Draft         DNS Delegation Revalidation            March 2024

   In normal operations this meta-data can be quickly re-validated with
   no further work.  However, when re-delegation or take-down occurs, a
   re-validating cache will discover this within one delegation TTL
   period, allowing the rapid expulsion of old data from the cache.

6.  IANA Considerations

   This document includes no request to IANA.

7.  Security Considerations

   In [DNS-CACHE-INJECTIONS] an overview is given of 18 cache poisoning
   attacks from which 13 can be remedied with delegation revalidation.
   The paper provides recommendations for handling records in DNS
   response with respect to an earlier version of the idea presented in
   this document[I-D.wijngaards-dnsext-resolver-side-mitigation].

   Referral response NS RRsets and glue, and the additional addresses
   from authoritative NS RRset responses (such as the root priming
   response), are not protected with DNSSEC signatures.  An attacker
   that is able to alter the unsigned A and AAAA RRsets in the
   additional section of referral and authoritative NS RRset responses,
   can fool a resolver into taking addresses under the control of the
   attacker to be authoritative for the zone.  Such an attacker can
   redirect all traffic to the zone (of the referral or authoritative NS
   RRset response) to a rogue name server.

   A rogue name server can view all queries from the resolver to that
   zone and alter all unsigned parts of responses, such as the parent
   side NS RRsets and glue of further referral responses.  Resolvers
   following referrals from a rogue name server, that do not revalidate
   those referral responses, can subsequently be fooled into taking
   addresses under the control of the attacker to be authoritative for
   those delegations as well.  The higher up the DNS tree, the more
   impact such an attack has.  In case of non DNSSEC validating
   resolvers, an attacker controlling a rogue name server for the root
   has potentially complete control over the entire domain name space
   and can alter all unsigned parts undetected.

   Revalidating referral and authoritative NS RRsets responses enables
   to defend against the above described attack with DNSSEC signed
   infrastructure RRsets.  Unlike cache poisoning defences that leverage
   increase entropy to protect the transaction, revalidation of NS
   RRsets and addresses also provides protection against on-path
   attacks.

Huque, et al.           Expires 19 September 2024               [Page 8]
Internet-Draft         DNS Delegation Revalidation            March 2024

   Upgrading NS RRset Credibility (Section 3) allows resolvers to cache
   and utilize the authoritative child apex NS RRset in preference to
   the non-authoritative parent NS RRset.  However, it is important to
   implement the steps described in Delegation Revalidation (Section 5)
   at the expiration of the parent's delegating TTL.  Otherwise, the
   operator of a malicious child zone, originally delegated to, but
   subsequently delegated away from, can cause resolvers that refresh
   TTLs on subsequent NS set queries, or that pre-fetch NS queries, to
   never learn of the redelegated zone.

8.  References

8.1.  Normative References

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

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

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

   [RFC8109]  Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS
              Resolver with Priming Queries", BCP 209, RFC 8109,
              DOI 10.17487/RFC8109, March 2017,
              <https://www.rfc-editor.org/info/rfc8109>.

8.2.  Informative References

   [DNS-CACHE-INJECTIONS]
              Klein, A., Shulman, H., and M. Waidner, "Internet-Wide
              Study of DNS Cache Injections", n.d.,
              <https://ieeexplore.ieee.org/abstract/document/8057202>.

   [GHOST1]   Jiang, J., Liang, J., Li, K., Li, J., Duan, H., and J. Wu,
              "Ghost Domain Names: Revoked Yet Still Resolvable", n.d.,
              <https://www.ndss-symposium.org/ndss2012/>.

   [GHOST2]   Li, X., Liu, B., Bai, X., Zhang, M., Zhang, Q., Li, Z.,
              Duan, H., and Q. Li, "Ghost Domain Reloaded: Vulnerable
              Links in Domain Name Delegation and Revocation", n.d.,
              <https://www.ndss-symposium.org/ndss-paper/ghost-domain-
              reloaded-vulnerable-links-in-domain-name-delegation-and-
              revocation/>.

Huque, et al.           Expires 19 September 2024               [Page 9]
Internet-Draft         DNS Delegation Revalidation            March 2024

   [I-D.vixie-dnsext-resimprove]
              Vixie, P. A., Joffe, R., and F. Neves, "Improvements to
              DNS Resolvers for Resiliency, Robustness, and
              Responsiveness", Work in Progress, Internet-Draft, draft-
              vixie-dnsext-resimprove-00, 23 June 2010,
              <https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-
              resimprove-00>.

   [I-D.wijngaards-dnsext-resolver-side-mitigation]
              Wijngaards, W., "Resolver side mitigations", Work in
              Progress, Internet-Draft, draft-wijngaards-dnsext-
              resolver-side-mitigation-01, 24 February 2009,
              <https://datatracker.ietf.org/doc/html/draft-wijngaards-
              dnsext-resolver-side-mitigation-01>.

Appendix A.  Acknowledgements

   Wouter Wijngaards proposed explicitly obtaining authoritative child
   NS data in [I-D.wijngaards-dnsext-resolver-side-mitigation].  This
   behavior has been implemented in the Unbound DNS resolver via the
   "harden-referral-path" option.  The combination of child NS fetch and
   revalidating the child delegation was originally proposed in
   [I-D.vixie-dnsext-resimprove], by Paul Vixie, Rodney Joffe, and
   Frederico Neves.

   The authors would like to thank Ralph Dolmans who was an early
   collaborator on this work, as well as the many members of the IETF
   DNS Operations Working Group for helpful comments and discussion.

Authors' Addresses

   Shumon Huque
   Salesforce
   Email: shuque@gmail.com

   Paul Vixie
   SIE Europe, U.G.
   Email: paul@redbarn.org

   Willem Toorop
   NLnet Labs
   Science Park 400
   1098 XH Amsterdam
   Netherlands
   Email: willem@nlnetlabs.nl

Huque, et al.           Expires 19 September 2024              [Page 10]