idnits 2.17.1 draft-huque-dnsop-ns-revalidation-00.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 (November 4, 2019) is 1606 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) ** Obsolete normative reference: RFC 7816 (Obsoleted by RFC 9156) 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: May 7, 2020 Farsight Security 6 November 4, 2019 8 Delegation Revalidation by DNS Resolvers 9 draft-huque-dnsop-ns-revalidation-00 11 Abstract 13 This document recommends improved DNS [RFC1034] [RFC1035] resolver 14 behavior with respect to the processing of Name Server (NS) resource 15 record sets (RRset) during iterative resolution. When following a 16 referral response from an authoritative server to a child zone, DNS 17 resolvers should explicitly query the authoritative NS RRset at the 18 apex of the child zone and cache this in preference to the NS RRset 19 on the parent side of the zone cut. Resolvers should also 20 periodically revalidate the child delegation by re-quering the parent 21 zone at the expiration of the TTL of the parent side NS RRset. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 7, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Upgrading NS RRset Credibility . . . . . . . . . . . . . . . 4 60 4. Delegation Revalidation . . . . . . . . . . . . . . . . . . . 4 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 8.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 This document recommends improved DNS resolver behavior with respect 72 to the processing of NS record sets during iterative resolution. The 73 first recommendation is that resolvers, when following a referral 74 response from an authoritative server to a child zone, should 75 explicitly query the authoritative NS RRset at the apex of the child 76 zone and cache this in preference to the NS RRset on the parent side 77 of the zone cut. The second recommendation is to revalidate the 78 delegation by re-quering the parent zone at the expiration of the TTL 79 of the parent side NS RRset. 81 2. Motivation 83 The delegation NS RRset at the bottom of the parent zone and the apex 84 NS RRset in the child zone are unsynchronized in the DNS protocol. 85 [RFC1034] Section 4.2.2 says "The administrators of both zones should 86 insure that the NS and glue RRs which mark both sides of the cut are 87 consistent and remain so.". But for a variety of reasons they could 88 not be. Officially, a child zone's apex NS RRset is authoritative 89 and thus has a higher cache credibility than the parent's delegation 90 NS RRset, which is non-authoritative glue ([RFC2181], Section 5.4.1. 91 Ranking data). Hence the NS RRset "below the zone cut" should 92 immediately replace the parent's delegating NS RRset in cache when an 93 iterative caching DNS resolver crosses a zone boundary. However, 94 this can only happen if (1) the resolver receives the authoritative 95 NS RRset in the Authority section of a response from the child zone, 96 which is not mandatory, or (2) if the resolver explicitly issues an 97 NS RRset query to the child zone as part of its iterative resolution 98 algorithm. In the absence of this, it is possible for an iterative 99 caching resolver to never learn the authoritative NS RRset for a 100 zone, unless a downstream client of the resolver explicitly issues 101 such an NS query, which is not something that normal enduser 102 applications do. 104 Increasingly, there is a trend towards minimizing unnecessary data in 105 DNS responses. Several popular DNS implementations default to such a 106 configuration (see "minimal-responses" in BIND and Unbound). 108 Qname Minimisation [RFC7816], a more privacy preserving mode of 109 iterative resolution, specifies the use of the NS query type at every 110 step of the resolution process until the full query name has been 111 reconstructed at the leaf zone. This would provide a way to 112 definitively learn the child zone's authoritative NS RRset. In 113 practice however, many (most?) implementations of Qname Minimisation 114 currently employ the original query type or the A query type. Thus, 115 regardless of whether Qname Minimisation is in use or not, this 116 document recommends explicitly fetching the authoritative NS RRset at 117 the child zone when following a referral. 119 A common reason that zone owners want to ensure that resolvers place 120 the authoritative NS RRset preferentially in their cache is that the 121 TTLs may differ between the parent and child side of the zone cut. 122 Some DNS Top Level Domains (TLDs) only support long fixed TTLs in 123 their delegation NS sets, and this inhibits the zone owner's ability 124 to make more rapid changes to their nameserver configuration, if 125 resolvers have no systematic mechanism to observe 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. 136 Technically, if both parent and child zone are DNSSEC [RFC4033] 137 [RFC4034] [RFC4035] signed with a corresponding secure delegation 138 between them, then expiration of the DS record will cause 139 revalidation of the current child zone's DNSKEY set, so responses 140 from the orphaned child nameservers would no longer be trusted. 141 However, delegation revalidation is still necessary to locate the 142 current nameserver addresses. 144 3. Upgrading NS RRset Credibility 146 o When a delegation response is received during iteration, a 147 validation query should be sent in parallel with the forwarding of 148 the triggering query to the delegated nameservers for the newly 149 discovered zone cut. The response to the triggering query should 150 be delayed until both the forwarded query and the validation query 151 have been answered. 153 o A validation query consists of a query for the child's apex NS 154 RRset, sent to the newly discovered delegation's nameservers. 155 Normal iterative logic applies to the processing of responses to 156 validation queries, including storing the results in cache, 157 propagating NXDOMAIN back to the triggering query, trying the next 158 server on SERVFAIL or timeout, and so on. 160 o If there are no nameserver names in common between the child's 161 apex NS RRset and the parent's delegation NS RRset, then the 162 responses received from forwarding the triggering query to the 163 parent's delegated nameservers should be discarded after 164 validation, and this query should be forwarded again to the 165 child's apex nameservers. 167 o [TBD: There are a small but non trivial number of authoritative 168 DNS services that timeout on explicit NS queries. Should we 169 accommodate them by treating this practice lazily and 170 opportunistically? Or do we expect the DNS Flag Day efforts will 171 effectively banish them in the near future?] 173 4. Delegation Revalidation 175 o The lowest TTL found in a parent zone's delegating NS RRset should 176 be stored in the cache and used to trigger delegation revalidation 177 as follows: Whenever a cached RRset is being considered for use in 178 a response, the cache should be walked upward toward the root, 179 looking for expired delegations. At the first expired delegation 180 encountered while walking upward toward the root, revalidation 181 should be triggered, putting the processing of dependent queries 182 on hold until validation is complete. 184 o To revalidate a delegation, the iterative caching DNS resolver 185 will forward the query that triggered revalidation to the 186 nameservers at the closest enclosing zone cut above the 187 revalidation point. While searching for these nameservers, 188 additional revalidations may occur, perhaps placing a chain of 189 dependent queries on hold, unwinding in downward order as 190 revalidations closer to the root must be complete before 191 revalidations further from the root can begin. 193 o If a delegation can be revalidated at the same node, then the old 194 apex NS RRset should be deleted from cache and then the new 195 delegating NS RRset should be stored in cache. The minimum TTL 196 from the new delegating NS RRset should also be stored in cache to 197 facilitate future revalidations. This order of operations ensures 198 that the RRset credibility rules do not prevent the new delegating 199 NS RRset from entering the cache. It is expected that the child's 200 apex NS RRset will rapidly replace the parent's delegating NS 201 RRset as soon as iteration restarts after the revalidation event. 203 o If the new delegating NS RRset cannot be found (RCODE=NXDOMAIN) or 204 if there is a new zone cut at some different level of the 205 hierarchy (insertion or deletion of a delegation point above the 206 revalidation point) or if the new RRset shares no nameserver names 207 in common with the old one (indicating some kind of redelegation, 208 which is rare) then the cache should be purged of all names and 209 RRsets at or below the revalidation point. This facilitates 210 redelegation or revocation of a zone by a parent zone 211 administrator, and also conserves cache storage by deleting 212 unreachable data. 214 o To make the timing of a revalidation event unpredictable from the 215 point of view of a potential cache-spoof attacker, the parent's 216 delegating NS RRset TTL should be reduced by a random fraction of 217 its value before being stored for use in revalidation activities. 219 o This section describes a precise algorithm for delegation 220 revalidation. A simpler resolver implementation may choose 221 alternative methods, e.g. it may choose to perform the upward 222 search for expired delegations at scheduled intervals rather than 223 for every response decision. Or it may have a fixed maximum TTL 224 for child zones before they are expired from the cache and 225 requeried at the parent. 227 5. Acknowledgements 229 The practices described in this document were originally proposed in 230 [I-D.vixie-dnsext-resimprove], by Vixie, Joffe, and Neves. 232 6. IANA Considerations 234 This document includes no request to IANA. 236 7. Security Considerations 238 Upgrading NS RRset Credibility (Section 3) allows resolvers to cache 239 and utilize the authoritative child apex NS RRset in preference to 240 the non-authoriative parent NS RRset. However, it is very important 241 to implement the steps described in Delegation Revalidation 242 (Section 4) at the expiration of the parent's delegating TTL. 243 Otherwise, the operator of a malicious child zone, originally 244 delegated to, but subsequently delegated away from, can cause 245 resolvers that refresh TTLs on subsequent NS set queries, or that 246 pre-fetch NS queries, to never learn of the redelegated zone. This 247 problem has been seen in the wild [include reference to Ghost Domains 248 paper here]. 250 8. References 252 8.1. Normative References 254 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 255 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 256 . 258 [RFC1035] Mockapetris, P., "Domain names - implementation and 259 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 260 November 1987, . 262 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 263 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 264 . 266 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 267 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 268 . 270 8.2. Informative References 272 [I-D.vixie-dnsext-resimprove] 273 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS 274 Resolvers for Resiliency, Robustness, and Responsiveness", 275 draft-vixie-dnsext-resimprove-00 (work in progress), June 276 2010. 278 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 279 Rose, "DNS Security Introduction and Requirements", 280 RFC 4033, DOI 10.17487/RFC4033, March 2005, 281 . 283 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 284 Rose, "Resource Records for the DNS Security Extensions", 285 RFC 4034, DOI 10.17487/RFC4034, March 2005, 286 . 288 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 289 Rose, "Protocol Modifications for the DNS Security 290 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 291 . 293 Authors' Addresses 295 Shumon Huque 296 Salesforce 298 Email: shuque@gmail.com 300 Paul Vixie 301 Farsight Security 303 Email: paul@redbarn.org