idnits 2.17.1 draft-huque-dnsop-ns-revalidation-01.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '...TL of a DS RRSet SHOULD match the TTL ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1499 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: September 10, 2020 Farsight Security 6 R. Dolmans 7 NLnet Labs 8 March 9, 2020 10 Delegation Revalidation by DNS Resolvers 11 draft-huque-dnsop-ns-revalidation-01 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 September 10, 2020. 42 Copyright Notice 44 Copyright (c) 2020 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 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Upgrading NS RRset Credibility . . . . . . . . . . . . . . . 4 62 4. Delegation Revalidation . . . . . . . . . . . . . . . . . . . 4 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 74 The source for this draft is maintained in GitHub at: 75 https://github.com/shuque/ns-revalidation 77 This document recommends improved DNS resolver behavior with respect 78 to the processing of NS record sets during iterative resolution. The 79 first recommendation is that resolvers, when following a referral 80 response from an authoritative server to a child zone, should 81 explicitly query the authoritative NS RRset at the apex of the child 82 zone and cache this in preference to the NS RRset on the parent side 83 of the zone cut. The second recommendation is to revalidate the 84 delegation by re-quering the parent zone at the expiration of the TTL 85 of the parent side NS RRset. 87 2. Motivation 89 The delegation NS RRset at the bottom of the parent zone and the apex 90 NS RRset in the child zone are unsynchronized in the DNS protocol. 91 [RFC1034] Section 4.2.2 says "The administrators of both zones should 92 insure that the NS and glue RRs which mark both sides of the cut are 93 consistent and remain so.". But for a variety of reasons they could 94 not be. Officially, a child zone's apex NS RRset is authoritative 95 and thus has a higher cache credibility than the parent's delegation 96 NS RRset, which is non-authoritative glue ([RFC2181], Section 5.4.1. 98 Ranking data). Hence the NS RRset "below the zone cut" should 99 immediately replace the parent's delegating NS RRset in cache when an 100 iterative caching DNS resolver crosses a zone boundary. However, 101 this can only happen if (1) the resolver receives the authoritative 102 NS RRset in the Authority section of a response from the child zone, 103 which is not mandatory, or (2) if the resolver explicitly issues an 104 NS RRset query to the child zone as part of its iterative resolution 105 algorithm. In the absence of this, it is possible for an iterative 106 caching resolver to never learn the authoritative NS RRset for a 107 zone, unless a downstream client of the resolver explicitly issues 108 such an NS query, which is not something that normal enduser 109 applications do, and thus cannot be relied upon to occur with any 110 regularity. 112 Increasingly, there is a trend towards minimizing unnecessary data in 113 DNS responses. Several popular DNS implementations default to such a 114 configuration (see "minimal-responses" in BIND and Unbound). So, 115 they may never include the authoritative NS RRset in the Authority 116 section of their responses. 118 A common reason that zone owners want to ensure that resolvers place 119 the authoritative NS RRset preferentially in their cache is that the 120 TTLs may differ between the parent and child side of the zone cut. 121 Some DNS Top Level Domains (TLDs) only support long fixed TTLs in 122 their delegation NS sets, and this inhibits a child zone owner's 123 ability to make more rapid changes to their nameserver configuration 124 using a shorter TTL, if resolvers have no systematic mechanism to 125 observe and cache the child NS RRset. 127 A child zone's delegation still needs to be periodically revalidated 128 at the parent to make sure that the parent zone has not legitimately 129 re-delegated the zone to a different set of nameservers. Otherwise, 130 resolvers that refresh the TTL of a child NS RRset on subsequent 131 queries or due to pre-fetching, may cling to those nameservers long 132 after they have been re-delegated elsewhere. This leads to the 133 second recommendation in this document, "Delegation Revalidation". 134 Essentially, the resolver should record the TTL of the parent's 135 delegating NS RRset, and use it to trigger a revalidation action. 137 If both parent and child zone are DNSSEC [RFC4033] [RFC4034] 138 [RFC4035] signed with a corresponding secure delegation between them, 139 then expiration of the Delegation Signer (DS) record set will cause 140 revalidation of the current child zone's DNSKEY set. According to 141 RFC 4035, Section 2.4, "The TTL of a DS RRSet SHOULD match the TTL of 142 the delegating NS RRset", so this revalidation should be triggered on 143 the same time scale, and thus responses from the stale child 144 nameservers would no longer be trusted. However, delegation 145 revalidation is still necessary to locate the current nameserver 146 addresses to which subsequent DNS queries should be directed. 148 3. Upgrading NS RRset Credibility 150 o When a delegation response is received during iteration, a 151 validation query should be sent in parallel with the resolution of 152 the triggering query, to the delegated nameservers for the newly 153 discovered zone cut. Note that validating resolvers today, when 154 following a secure delegation response, already need to dispatch a 155 query to the delegated nameservers for the DNSKEY RRset, so this 156 validation query could be sent in parallel with that DNSKEY query. 158 o A validation query consists of a query for the child's apex NS 159 RRset, sent to the newly discovered delegation's nameservers. 160 Normal iterative logic applies to the processing of responses to 161 validation queries, including storing the results in cache, trying 162 the next server on SERVFAIL or timeout, and so on. Positive 163 answers to this validation query will be cached with an 164 authoritative data ranking. Successive queries directed to the 165 same zone will be directed to the nameservers listed in the 166 child's apex, due to the ranking of this answer. If the 167 validation query fails, the parent NS RRset will remain the one 168 with the highest ranking and will be used for successive queries. 170 o Some resolvers may choose to delay the response to the triggering 171 query until both the triggering query and the validation query 172 have been answered. In practice, we expect many implementations 173 may answer the triggering query in advance of the validation query 174 for performance reasons. An additional reason is that there are 175 number of nameservers in the field that (incorrectly) fail to 176 answer explicit queries for NS records, and thus the revalidation 177 logic may need to be applied lazily and opportunistically to deal 178 with them. 180 o If the resolver chooses to delay the response, and there are no 181 nameserver names in common between the child's apex NS RRset and 182 the parent's delegation NS RRset, then the responses received from 183 forwarding the triggering query to the parent's delegated 184 nameservers should be discarded after validation, and this query 185 should be forwarded again to the child's apex nameservers. 187 4. Delegation Revalidation 189 This documents proposes two mechanisms to perform delegation 190 revalidation: an extensive and a simple mechanism. [TODO: in the 191 next revision of this draft, we would prefer to discard the extensive 192 mechanism description and keep only the simple one, assuming 193 agreement.] 195 The extensive mechanism: 197 o The lowest TTL found in a parent zone's delegating NS RRset should 198 be stored in the cache and used to trigger delegation revalidation 199 as follows: Whenever a cached RRset is being considered for use in 200 a response, the cache should be walked upward toward the root, 201 looking for expired delegations. At the first expired delegation 202 encountered while walking upward toward the root, revalidation 203 should be triggered, putting the processing of dependent queries 204 on hold until validation is complete. 206 o To revalidate a delegation, the iterative caching DNS resolver 207 will forward the query that triggered revalidation to the 208 nameservers at the closest enclosing zone cut above the 209 revalidation point. While searching for these nameservers, 210 additional revalidations may occur, perhaps placing a chain of 211 dependent queries on hold, unwinding in downward order as 212 revalidations closer to the root must be complete before 213 revalidations further from the root can begin. 215 o If a delegation can be revalidated at the same node, then the old 216 apex NS RRset should be deleted from cache and then the new 217 delegating NS RRset should be stored in cache. The minimum TTL 218 from the new delegating NS RRset should also be stored in cache to 219 facilitate future revalidations. This order of operations ensures 220 that the RRset credibility rules do not prevent the new delegating 221 NS RRset from entering the cache. It is expected that the child's 222 apex NS RRset will rapidly replace the parent's delegating NS 223 RRset as soon as iteration restarts after the revalidation event. 225 o If the new delegating NS RRset cannot be found (RCODE=NXDOMAIN) or 226 if there is a new zone cut at some different level of the 227 hierarchy (insertion or deletion of a delegation point above the 228 revalidation point) or if the new RRset shares no nameserver names 229 in common with the old one (indicating some kind of redelegation, 230 which is rare) then the cache should be purged of all names and 231 RRsets at or below the revalidation point. This facilitates 232 redelegation or revocation of a zone by a parent zone 233 administrator, and also conserves cache storage by deleting 234 unreachable data. 236 The simple mechanism: 238 o Cap the time to cache the child NS RRset to the lower of child and 239 parent NS RRset TTL. The normal iterative resolution algorithm 240 will then cause delegation revalidation to naturally occur at the 241 expiration of the capped child NS TTL, along with dispatching of 242 the validation query to upgrade NS RRset credibility. 244 5. Acknowledgements 246 Wouter Wijngaards proposed explicitly obtaining authoritative child 247 NS data in [I-D.wijngaards-dnsext-resolver-side-mitigation]. This 248 behavior has been implemented in the Unbound DNS resolver via the 249 "harden-referral-path" option. The combination of child NS fetch and 250 revalidating the child delegation was originally proposed in 251 [I-D.vixie-dnsext-resimprove], by Vixie, Joffe, and Neves. 253 6. IANA Considerations 255 This document includes no request to IANA. 257 7. Security Considerations 259 Upgrading NS RRset Credibility (Section 3) allows resolvers to cache 260 and utilize the authoritative child apex NS RRset in preference to 261 the non-authoriative parent NS RRset. However, it is important to 262 implement the steps described in Delegation Revalidation (Section 4) 263 at the expiration of the parent's delegating TTL. Otherwise, the 264 operator of a malicious child zone, originally delegated to, but 265 subsequently delegated away from, can cause resolvers that refresh 266 TTLs on subsequent NS set queries, or that pre-fetch NS queries, to 267 never learn of the redelegated zone. This problem has been seen in 268 the wild [include reference to Ghost Domains paper here]. 270 8. References 272 8.1. Normative References 274 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 275 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 276 . 278 [RFC1035] Mockapetris, P., "Domain names - implementation and 279 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 280 November 1987, . 282 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 283 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 284 . 286 8.2. Informative References 288 [I-D.vixie-dnsext-resimprove] 289 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS 290 Resolvers for Resiliency, Robustness, and Responsiveness", 291 draft-vixie-dnsext-resimprove-00 (work in progress), June 292 2010. 294 [I-D.wijngaards-dnsext-resolver-side-mitigation] 295 Wijngaards, W., "Resolver side mitigations", draft- 296 wijngaards-dnsext-resolver-side-mitigation-01 (work in 297 progress), February 2009. 299 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 300 Rose, "DNS Security Introduction and Requirements", 301 RFC 4033, DOI 10.17487/RFC4033, March 2005, 302 . 304 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 305 Rose, "Resource Records for the DNS Security Extensions", 306 RFC 4034, DOI 10.17487/RFC4034, March 2005, 307 . 309 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 310 Rose, "Protocol Modifications for the DNS Security 311 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 312 . 314 Authors' Addresses 316 Shumon Huque 317 Salesforce 319 Email: shuque@gmail.com 321 Paul Vixie 322 Farsight Security 324 Email: paul@redbarn.org 326 Ralph Dolmans 327 NLnet Labs 329 Email: ralph@nlnetlabs.nl