Internet-Draft DNS Delegation Revalidation July 2021
Huque, et al. Expires 13 January 2022 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-ietf-dnsop-ns-revalidation-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
S. Huque
Salesforce
P. Vixie
Farsight Security
R. Dolmans
NLnet Labs

Delegation Revalidation by DNS Resolvers

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

Status of This Memo

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

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 13 January 2022.

Table of Contents

1. Introduction

RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH BEFORE PUBLISHING: The source for this draft is maintained in GitHub at: https://github.com/shuque/ns-revalidation

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

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 Unbound). 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. In fact, the Extensible Provisioning Protocol (EPP) [RFC5731], that is often used by TLDs to configure delegation parameters has no provision to set the TTL. 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.

3. Upgrading NS RRset Credibility

4. Delegation Revalidation

This documents proposes two mechanisms to perform delegation revalidation: an extensive and a simple mechanism. [TODO: should we keep just the simple mechanism?]

The extensive mechanism:

The simple mechanism:

4.1. Using the DS Record TTL

If both parent and child zone are DNSSEC [RFC4033] [RFC4034] [RFC4035] signed with a corresponding secure delegation between them, then expiration of the Delegation Signer (DS) record set will cause revalidation of the current child zone's DNSKEY set. According to RFC 4035, Section 2.4, "The TTL of a DS RRSet SHOULD match the TTL of the delegating NS RRset", so this revalidation should be triggered on the same time scale, and thus responses from the stale child nameservers would no longer be trusted. However, delegation revalidation is still necessary to locate the current nameserver addresses to which subsequent DNS queries should be directed.

In practice, the DS TTL often differs from the delegating NS TTL. For example, currently the root zone and the COM and NET TLDs all set an NS RRset TTL of 2 days, while the DS RRset TTL is just 1 day. RSSAC-003 [rssac-003] makes the following observation: "In the root zone, delegating NS records have a 2 day TTL. However, the DS records have a 1 day TTL, against the advice of RFC 4035. This is not particularly surprising since a mistake with a DS record can deny resolution for all names under a TLD. Given the way that DS records are currently used in the root zone (e.g., usually matching just one TLD KSK) it is better for them to have a lower TTL in the event of an emergency change."

If a secure delegation is present, resolvers may use the DS RRset's TTL as the revalidation interval in preference to to the delegating NS RRSet TTL. (Question: should this be the recommendation instead?; after all the DS is signed so its TTL cannot be spoofed.?)

5. Optimizations

TODO: mention possible optimizations: record whether certain nameservers return the child NS set in their authoritative section responses and subsequently forego the extra child NS query for a period of time. Suggest that authoritative servers that do minimal responses return their NS sets in response to DNSKEY queries, and resolvers that see such behavior may also subsequently forego the extra child NS query (from Olafur G.).

6. Re-delegations and Delegation Removals

TODO: mention in more detail what to do when resolvers observe redelegations or removal of delegations at the parent. A quick initial summary follows.

If a delegation is removed (i.e. the parent returns NXDOMAIN), then cache contents should be treated as described in [RFC8020] -- ideally the resolver's cache should be entirely pruned at the delegation point, or the cached contents below the delegation may be allowed to be used until they expire. Similar treatment of the cache should be followed if the child zone has been entirely re-delegated to a new set of nameservers. If only a subset of nameservers have been re-delegated, then no new cache cleanup action is needed.

7. IANA Considerations

This document includes no request to IANA.

8. 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 4) 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. This problem has been seen in the wild [include reference to Ghost Domains paper here].

9. References

9.1. Normative References

[RFC1034]
Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, , <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035]
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <https://www.rfc-editor.org/info/rfc1035>.
[RFC2181]
Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, , <https://www.rfc-editor.org/info/rfc2181>.
[RFC7816]
Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, , <https://www.rfc-editor.org/info/rfc7816>.
[RFC8020]
Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, , <https://www.rfc-editor.org/info/rfc8020>.

9.2. Informative References

[I-D.vixie-dnsext-resimprove]
Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness", Work in Progress, Internet-Draft, draft-vixie-dnsext-resimprove-00, , <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, , <https://datatracker.ietf.org/doc/html/draft-wijngaards-dnsext-resolver-side-mitigation-01>.
[RFC4033]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, , <https://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, , <https://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, , <https://www.rfc-editor.org/info/rfc4035>.
[RFC5731]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, , <https://www.rfc-editor.org/info/rfc5731>.
[rssac-003]
RSSAC_Caucus, "RSSAC003 Report on Root Zone TTLs", , <https://www.icann.org/en/system/files/files/rssac-003-root-zone-ttls-21aug15-en.pdf>.

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
Paul Vixie
Farsight Security
Ralph Dolmans
NLnet Labs