idnits 2.17.1 draft-ietf-dnsop-ns-revalidation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC1034], [RFC1035]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.vixie-dnsext-resimprove' is defined on line 301, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Huque 3 Internet-Draft Salesforce 4 Intended status: Standards Track P. Vixie 5 Expires: 8 September 2022 Farsight Security 6 R. Dolmans 7 NLnet Labs 8 7 March 2022 10 Delegation Revalidation by DNS Resolvers 11 draft-ietf-dnsop-ns-revalidation-02 13 Abstract 15 This document recommends improved DNS [RFC1034] [RFC1035] resolver 16 behavior with respect to the processing of Name Server (NS) resource 17 record sets (RRset) during iterative resolution. When following a 18 referral response from an authoritative server to a child zone, DNS 19 resolvers should explicitly query the authoritative NS RRset at the 20 apex of the child zone and cache this in preference to the NS RRset 21 on the parent side of the zone cut. Resolvers should also 22 periodically revalidate the child delegation by re-quering the parent 23 zone at the expiration of the TTL of the parent side NS RRset. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 8 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Upgrading NS RRset Credibility . . . . . . . . . . . . . . . 4 61 4. Delegation Revalidation . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH BEFORE PUBLISHING: The 73 source for this draft is maintained in GitHub at: 74 https://github.com/shuque/ns-revalidation 76 This document recommends improved DNS resolver behavior with respect 77 to the processing of NS record sets during iterative resolution. The 78 first recommendation is that resolvers, when following a referral 79 response from an authoritative server to a child zone, should 80 explicitly query the authoritative NS RRset at the apex of the child 81 zone and cache this in preference to the NS RRset on the parent side 82 of the zone cut. The second recommendation is to revalidate the 83 delegation by re-quering the parent zone at the expiration of the TTL 84 of the parent side NS RRset. 86 2. Motivation 88 There is wide variability in the behavior of deployed DNS resolvers 89 today with respect to how they process delegation records. Some of 90 them prefer the parent NS set, some prefer the child, and for others, 91 what they preferentially cache depends on the dynamic state of 92 queries and responses they have processed. This document aims to 93 bring more commonality and predictability by standardizing the 94 behavior in a way that comports with the DNS protocol. 96 The delegation NS RRset at the bottom of the parent zone and the apex 97 NS RRset in the child zone are unsynchronized in the DNS protocol. 98 [RFC1034] Section 4.2.2 says "The administrators of both zones should 99 insure that the NS and glue RRs which mark both sides of the cut are 100 consistent and remain so.". But for a variety of reasons they could 101 not be. Officially, a child zone's apex NS RRset is authoritative 102 and thus has a higher cache credibility than the parent's delegation 103 NS RRset, which is non-authoritative glue ([RFC2181], Section 5.4.1. 104 "Ranking data", and Section 6.1. "Zone authority"). Hence the NS 105 RRset "below the zone cut" should immediately replace the parent's 106 delegating NS RRset in cache when an iterative caching DNS resolver 107 crosses a zone boundary. However, this can only happen if (1) the 108 resolver receives the authoritative NS RRset in the Authority section 109 of a response from the child zone, which is not mandatory, or (2) if 110 the resolver explicitly issues an NS RRset query to the child zone as 111 part of its iterative resolution algorithm. In the absence of this, 112 it is possible for an iterative caching resolver to never learn the 113 authoritative NS RRset for a zone, unless a downstream client of the 114 resolver explicitly issues such an NS query, which is not something 115 that normal enduser applications do, and thus cannot be relied upon 116 to occur with any regularity. 118 Increasingly, there is a trend towards minimizing unnecessary data in 119 DNS responses. Several popular DNS implementations default to such a 120 configuration (see "minimal-responses" in BIND and NSD). So, they 121 may never include the authoritative NS RRset in the Authority section 122 of their responses. 124 A common reason that zone owners want to ensure that resolvers place 125 the authoritative NS RRset preferentially in their cache is that the 126 TTLs may differ between the parent and child side of the zone cut. 127 Some DNS Top Level Domains (TLDs) only support long fixed TTLs in 128 their delegation NS sets. In fact, the Extensible Provisioning 129 Protocol (EPP) [RFC5731], that is often used by TLDs to configure 130 delegation parameters has no provision to set the TTL. This inhibits 131 a child zone owner's ability to make more rapid changes to their 132 nameserver configuration using a shorter TTL, if resolvers have no 133 systematic mechanism to observe and cache the child NS RRset. 135 A child zone's delegation still needs to be periodically revalidated 136 at the parent to make sure that the parent zone has not legitimately 137 re-delegated the zone to a different set of nameservers, or even 138 removed the delegation. Otherwise, resolvers that refresh the TTL of 139 a child NS RRset on subsequent queries or due to pre-fetching, may 140 cling to those nameservers long after they have been re-delegated 141 elsewhere. This leads to the second recommendation in this document, 142 "Delegation Revalidation" - Resolvers should record the TTL of the 143 parent's delegating NS RRset, and use it to trigger a revalidation 144 action. 146 3. Upgrading NS RRset Credibility 148 * When a delegation response is received during iteration, a 149 validation query should be sent in parallel with the resolution of 150 the triggering query, to the delegated nameservers for the newly 151 discovered zone cut. Note that validating resolvers today, when 152 following a secure referral, already need to dispatch a query to 153 the delegated nameservers for the DNSKEY RRset, so this validation 154 query could be sent in parallel with that DNSKEY query. 156 * A validation query consists of a query for the child's apex NS 157 RRset, sent to the newly discovered delegation's nameservers. 158 Normal iterative logic applies to the processing of responses to 159 validation queries, including storing the results in cache, trying 160 the next server on SERVFAIL or timeout, and so on. Positive 161 answers to this validation query will be cached with an 162 authoritative data ranking. Successive queries directed to the 163 same zone will be directed to the nameservers listed in the 164 child's apex, due to the ranking of this answer. If the 165 validation query fails, the parent NS RRset will remain the one 166 with the highest ranking and will be used for successive queries. 168 * Some resolvers may choose to delay the response to the triggering 169 query until both the triggering query and the validation query 170 have been answered. In practice, we expect many implementations 171 may answer the triggering query in advance of the validation query 172 for performance reasons. An additional reason is that there are 173 number of nameservers in the field that (incorrectly) fail to 174 answer explicit queries for NS records, and thus the revalidation 175 logic may need to be applied lazily and opportunistically to deal 176 with them. 178 * If the resolver chooses to delay the response, and there are no 179 nameserver names in common between the child's apex NS RRset and 180 the parent's delegation NS RRset, then the responses received from 181 forwarding the triggering query to the parent's delegated 182 nameservers should be discarded after validation, and this query 183 should be forwarded again to the child's apex nameservers. 185 4. Delegation Revalidation 187 The essence of this mechanism is re-validation of all delegation 188 metadata that directly or indirectly supports an owner name in cache. 189 This requires a cache to remember the delegated name server names for 190 each zone cut as received from the parent (delegating) zone's name 191 servers, and also the TTL of that NS RRset, and the TTL of the 192 associated DS RRset (if seen). 194 A delegation under re-validation is called a "re-validation point" 195 and is "still valid" if its parent zone's servers still respond to an 196 in-zone question with a referral to the re-validation point, and if 197 that referral overlaps with the previously cached referral by at 198 least one name server name, and the DS RRset (if seen) overlaps the 199 previously cached DS RRset (if also seen) by at least one delegated 200 signer. 202 If the response is not a referral or refers to a different zone than 203 before, then the shape of the delegation hierarchy has changed. If 204 the response is a referral to the re-validation point but to a wholly 205 novel NS RRset or a wholly novel DS RRset, then the authority for 206 that zone has changed. For clarity, this includes transitions 207 between empty and non-empty DS RRsets. 209 If the shape of the delegation hierarchy or the authority for a zone 210 has been found to change, then no currently cached data whose owner 211 names are at or below that re-validation point can be used. Such 212 non-use can be by directed garbage collection or lazy generational 213 garbage collection or some other method befitting the architecture of 214 the cache. What matters is that the cache behave as though this data 215 was removed. 217 Since re-validation can discover changes in the shape of the 218 delegation hierarchy it is more efficient to re-validate from the top 219 (root) downward (to the owner name) since an upper level re- 220 validation may obviate lower level re-validations. What matters is 221 that the supporting chain of delegations from the root to the owner 222 name be demonstrably valid; further specifics are implementation 223 details. 225 Re-validation is triggered when delegation meta-data has been cached 226 for a period at most exceeding the delegating NS or DS (if seen) 227 RRset TTL. If the corresponding child zone's apex NS RRset TTL is 228 smaller than the delegating NS RRset TTL, revalidation should happen 229 at that interval instead. However, resolvers should impose a 230 sensitive minimum TTL floor they are willing to endure to avoid 231 potential computational DoS attacks inflicted by zones with very 232 short TTLs. 234 In normal operations this meta-data can be quickly re-validated with 235 no further work. However, when re-delegation or take-down occurs, a 236 re-validating cache will discover this within one delegation TTL 237 period, allowing the rapid expulsion of old data from the cache. 239 5. IANA Considerations 241 This document includes no request to IANA. 243 6. Security Considerations 245 Upgrading NS RRset Credibility (Section 3) allows resolvers to cache 246 and utilize the authoritative child apex NS RRset in preference to 247 the non-authoriative parent NS RRset. However, it is important to 248 implement the steps described in Delegation Revalidation (Section 4) 249 at the expiration of the parent's delegating TTL. Otherwise, the 250 operator of a malicious child zone, originally delegated to, but 251 subsequently delegated away from, can cause resolvers that refresh 252 TTLs on subsequent NS set queries, or that pre-fetch NS queries, to 253 never learn of the redelegated zone. This problem has been seen in 254 the wild [include reference to Ghost Domains paper here]. 256 7. References 258 7.1. Normative References 260 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 261 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 262 . 264 [RFC1035] Mockapetris, P., "Domain names - implementation and 265 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 266 November 1987, . 268 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 269 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 270 . 272 7.2. Informative References 274 [I-D.vixie-dnsext-resimprove] 275 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS 276 Resolvers for Resiliency, Robustness, and Responsiveness", 277 Work in Progress, Internet-Draft, draft-vixie-dnsext- 278 resimprove-00, 23 June 2010, 279 . 282 [I-D.wijngaards-dnsext-resolver-side-mitigation] 283 Wijngaards, W., "Resolver side mitigations", Work in 284 Progress, Internet-Draft, draft-wijngaards-dnsext- 285 resolver-side-mitigation-01, 24 February 2009, 286 . 289 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 290 Domain Name Mapping", STD 69, RFC 5731, 291 DOI 10.17487/RFC5731, August 2009, 292 . 294 Acknowledgements 296 Wouter Wijngaards proposed explicitly obtaining authoritative child 297 NS data in [I-D.wijngaards-dnsext-resolver-side-mitigation]. This 298 behavior has been implemented in the Unbound DNS resolver via the 299 "harden-referral-path" option. The combination of child NS fetch and 300 revalidating the child delegation was originally proposed in 301 [I-D.vixie-dnsext-resimprove], by Vixie, Joffe, and Neves. 303 Authors' Addresses 305 Shumon Huque 306 Salesforce 307 Email: shuque@gmail.com 309 Paul Vixie 310 Farsight Security 311 Email: paul@redbarn.org 313 Ralph Dolmans 314 NLnet Labs 315 Email: ralph@nlnetlabs.nl