Internet DRAFT - draft-ietf-dnsop-ns-revalidation
draft-ietf-dnsop-ns-revalidation
Domain Name System Operations S. Huque
Internet-Draft Salesforce
Intended status: Standards Track P. Vixie
Expires: 5 September 2024 SIE Europe, U.G.
W. Toorop
NLnet Labs
4 March 2024
Delegation Revalidation by DNS Resolvers
draft-ietf-dnsop-ns-revalidation-05
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
requeried and used to replace the entries with the lower
trustworthiness ranking in cache. Resolvers should also periodically
revalidate the child delegation by re-quering 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 5 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 5 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 . . . . . . . . . . . . . . . 4
4. Upgrading A and AAAA RRset Credibility . . . . . . . . . . . 5
5. Delegation Revalidation . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Huque, et al. Expires 5 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 respons (as glue) or authoritative NS respons 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-quering 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.
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.
Huque, et al. Expires 5 September 2024 [Page 3]
Internet-Draft DNS Delegation Revalidation March 2024
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.
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
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.
Huque, et al. Expires 5 September 2024 [Page 4]
Internet-Draft DNS Delegation Revalidation March 2024
* 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 ne 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 requeried after reception of
the authoritative NS RRset (see Section 4)
* 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].
Huque, et al. Expires 5 September 2024 [Page 5]
Internet-Draft DNS Delegation Revalidation March 2024
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 verifyable, (because the
complete RRset is included, including a verifyable signature for the
RRset), such additional addresses can be cached authoritively
immediatly 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.
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
Huque, et al. Expires 5 September 2024 [Page 6]
Internet-Draft DNS Delegation Revalidation March 2024
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.
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
Upgrading NS RRset Credibility (Section 3) allows resolvers to cache
and utilize the authoritative child apex NS RRset in preference to
the non-authoriative 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
Huque, et al. Expires 5 September 2024 [Page 7]
Internet-Draft DNS Delegation Revalidation March 2024
[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
[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/>.
[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>.
Huque, et al. Expires 5 September 2024 [Page 8]
Internet-Draft DNS Delegation Revalidation March 2024
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 Vixie, Joffe, and Neves.
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 5 September 2024 [Page 9]
