idnits 2.17.1 draft-muks-dnsop-dns-opportunistic-refresh-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2017) is 2493 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 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 M. Sivaraman 3 Internet-Draft Internet Systems Consortium 4 Intended status: Experimental S. Kerr 5 Expires: December 31, 2017 Oracle 6 S. Morris 7 Internet Systems Consortium 8 June 29, 2017 10 DNS Opportunistic Refresh for Resolvers 11 draft-muks-dnsop-dns-opportunistic-refresh-00 13 Abstract 15 This document describes a mechanism whereby a DNS resolver can 16 opportunistically refresh the TTLs of cached records of a zone using 17 serial number information carried in responses from the zone's 18 nameservers. As well as improving resolver response time by reducing 19 the need to make upstream queries, the mechanism can also reduce the 20 workload of authoritative servers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 31, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 58 3. Opportunistic DNS Refresh . . . . . . . . . . . . . . . . . . 3 59 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Detailed Description . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Resolver Behavior - Querying an Authoritative Server . . 4 62 4.2. Authoritative Server Behavior - Processing a Query . . . 4 63 4.3. Resolver Behavior - Processing a Response . . . . . . . . 5 64 4.4. Resolver Behavior - Processing a Subsequent Query . . . . 5 65 4.5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative references . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative references . . . . . . . . . . . . . . . . . 8 73 Appendix A. Change history (to be removed before publication) . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 DNS secondary nameservers use the value in a zone's SOA RR's SERIAL 79 field [RFC1035] to determine freshness of the copy of a zone that 80 they are maintaining locally and so establish whether a zone transfer 81 to update the zone is necessary. The SOA RR is retrieved either in 82 response to a NOTIFY message from the primary or by the passing of an 83 interval equal to the SOA refresh timeout. A comparison of the 84 serial numbers of the stored zone and that in the SOA record 85 [RFC1982] establishes whether a zone transfer is necessary. By using 86 the SOA RR's SERIAL field, nameservers avoid redundant and 87 unnecessary zone transfers for local data that is already fresh, 88 thereby reducing network traffic and nameserver resource usage. 90 This memo introduces a similar - but optional - scheme, to a regular 91 DNS query. A DNS resolver requests an authoritative server to return 92 the SOA record along with the the results of a query. By associating 93 these records with the serial number of zone at the time they were 94 retrieved, a resolver can use subsequent responses from the zone to 95 determine whether cached records have changed; if not, the cached 96 records can continue to be used, so eliminating the need to re-fetch 97 the record from its zone's nameservers. 99 2. Requirements Notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 3. Opportunistic DNS Refresh 107 3.1. Overview 109 The idea is best illustrated with an example: 111 1. At time t=0, a resolver queries an authoritative server of 112 example.com for the AAAA record of www.example.com. It includes 113 an EDNS0 option [RFC6891] that requests that the example.com 114 nameservers also return the SOA RR of example.com. The 115 authoritative server returns the AAAA record for www.example.com 116 along with the copy of the current SOA record. It also returns 117 the ZONESERIAL EDNS0 option that guarantees to the resolver that 118 any change in the example.com zone will be accompanied by a 119 change in the zone's serial number. Suppose that the AAAA record 120 is the address 2001:DB8::1 and that it has a TTL of 3600. Also 121 suppose that the serial number of the SOA record is 42. 123 2. At time t=3000, the resolver queries an authoritative server of 124 example.com for the MX record of example.com. This query also 125 includes the EDNS0 option requesting the SOA RR. The 126 authoritative server returns the requested data, together with 127 the SOA RR in the Additional Section of the response as well as 128 the ZONESERIAL EDNS0 option. Assume that the SOA record 129 indicates that the serial number is unchanged at 42. 131 3. At time t=4000, the resolver receives a query for the AAAA record 132 of www.example.com. In the normal course of events the resolver 133 would have to re-fetch the record because the cached record has 134 expired. However, the resolver knows that had it queried for the 135 AAAA record of www.example.com at t=3000, it would have got the 136 same answer as it has cached (2001:DB8::1 and an initial TTL of 137 3600), since the query for the MX record showed that the zone's 138 serial number was unchanged and that the server guarantees that 139 the serial number will change on every update to the zone. The 140 only difference would be that instead of the record being 141 expired, the TTL of the record would now be 2600 (the original 142 TTL of 3600 less the 1000 seconds that have elapsed since the 143 query for the MX record). Instead of fetching the record again, 144 the resolver can set the TTL to 2600, reflecting the valid state 145 that would have occurred had the resolver queried for the record 146 at the same time as it queried for the MX record. 148 Use of opportunistic refresh requires that both resolvers and 149 authoritative servers signal their support for the protocol via an 150 EDNS0 option. This is the ZONESERIAL option and is required because: 152 o Resolvers need to explicitly request that authoritative servers 153 include an SOA RR in their responses, since adding an SOA record 154 to a response when it is not needed just wastes bandwidth. 156 o Authoritative servers need to signal that the zone's serial number 157 changes every time the contents of the zone change, so confirming 158 to resolvers that the serial number is an indication of the zone's 159 freshness. This should be the normal state of affairs, but some 160 authoritative servers generate content on the fly and may not 161 update the SOA serial number. Although omission of the SOA RR 162 could be used as an indication that the server does not support 163 opportunistic refresh, this feature allows zone freshness 164 information to be extracted from any SOA record in the answer, 165 e.g. responses returning NXDOMAIN or explicit queries for the SOA. 166 Under these circumstances, the ZONESERIAL option is required in 167 the response in order to prevent misinterpretation. 169 4. Detailed Description 171 4.1. Resolver Behavior - Querying an Authoritative Server 173 To signal support for DNS opportunistic refresh, resolvers MUST add 174 the ZONESERIAL EDNS0 option to their queries. Bit 7 of the option's 175 FLAGS field is the request/acknowledge flag and MUST be clear in the 176 request to the authoritative server. 178 4.2. Authoritative Server Behavior - Processing a Query 180 Upon receiving a ZONESERIAL EDNS0 option with the request/acknowledge 181 flag clear, the action of the authoritative server depends on the 182 response being returned: 184 o If the answer is a negative response (e.g. NODATA or NXDOMAIN), 185 no special action is required: the SOA of the zone that was 186 searched for the answer will be included in the response. 188 o If the answer is a positive response or a referral, the SOA for 189 the zone from which the answer was obtained SHOULD be included in 190 the additional section of the answer. 192 In all cases, the authoritative server MUST include the ZONESERIAL 193 EDNS0 option in the response. The request/acknowledge bit in the 194 FLAGS field MUST also be set in the message. 196 4.3. Resolver Behavior - Processing a Response 198 Upon receiving a positive response containing an SOA RR and a valid 199 ZONESERIAL EDNS0 option, the resolver SHOULD associate the zone's 200 serial number with the RRs in the answer. In addition, it SHOULD 201 note the serial number as the indication of the zone's freshness 202 along with the time at which the serial number was valid. 204 If a negative response is received and the message contains a valid 205 ZONESERIAL EDNS0 option, the resolver SHOULD update its record of the 206 zone's serial number, as well as noting the time at which this serial 207 number was valid. 209 4.4. Resolver Behavior - Processing a Subsequent Query 211 When a resolver receives a query, it will check its cache to see 212 whether the answer is present. If it is, but the TTL has expired, an 213 opportunistic refresh-enabled resolver SHOULD check to see if the 214 record is associated with a zone serial number. If it is, the 215 resolver SHOULD compare the serial number against the latest serial 216 number it has for the zone. If the numbers are the same, the 217 resolver SHOULD calculate a new TTL: 219 candidate TTL = Original TTL - (current time - latest serial number 220 retrieval time) 222 If this value is positive and the record is not signed, the resolver 223 MAY set the TTL of the cached record to this value and return it to 224 the client without re-querying the authoritative server. 226 If the value is positive and the record is signed the resolver SHOULD 227 calculate the time to signature expiration. If this is a postive 228 value, the resolver MAY set the TTL of the record to: 230 New TTL = MIN(Candidate TTL, Time to Signature Expiration) 232 In all other cases (including cases where - perhaps for policy 233 reasons - the resolver chooses not to extend the TTL), the resolver 234 MUST NOT reset the TTL; instead, it should fetch a new copy of the 235 record from the appropriate nameservers. 237 4.5. Notes 239 There are a number of cases that require special processing: 241 o An authoritative server receiving a misconfigured ZONESERIAL 242 option in a query SHOULD return a FORMERR response. 244 o A resolver receiving a misconfigured ZONESERIAL option in a 245 response MUST NOT interpret the serial number in any SOA RR in 246 that response as an indication of zone freshness. It MAY however 247 regard the RRs in the response as valid. 249 o If, in response to a query containing the ZONESERIAL option to a 250 zone it has previously established supports this option, a 251 resolver receives a response containing either no ZONESERIAL 252 option or an invalid one, the resolver should assume that the zone 253 can no longer guarantee that the serial number will change on 254 every zone update. It MUST clear all existing serial number 255 information for the zone related to opportunistic DNS refresh. 256 Subequent queries to the zone SHOULD include the ZONESERIAL 257 option, allowing the resolver to start building up refresh 258 information again. 260 o In the case of NS records, although the child zone is 261 authoritative for the NS information, a resolver must periodically 262 query for the parent's copy of the NS records to ensure that the 263 delegation is still valid. To avoid the extension of an NS 264 record's TTL preventing the resolver from querying the parent, the 265 resolver MUST NOT extend the TTL of NS records using the method 266 described here. 268 o To avoid any complications related to transitive use of this 269 scheme through forwarders and other intermediate resolvers where 270 the nameserver may return a non- authoritative answer, nameservers 271 that are not authoritative for a zone MUST NOT include a 272 ZONESERIAL EDNS0 option in a response to a query for a name in 273 that zone. 275 o If Client Subnet [RFC7871] is enabled, resource records in the 276 cache may be associated with a subnet. In these cases, the 277 resolver MUST ensure that the zone serial number associated with 278 such records is obtained from an SOA record associated with the 279 identical subnet. 281 5. Option Format 283 The opportunistic DNS refresh option is encoded as follows: 285 1 2 3 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 287 +-------------------------------+-------------------------------+ 288 ! OPTION-CODE ! OPTION-LENGTH ! 289 +-------------------------------+-------------------------------+ 290 | FLAGS | 291 +---------------+ 293 ZONERSERIAL EDNS0 Option 295 where: 297 OPTION-CODE the EDNS0 option code assigned to opportunistic DNS 298 refresh, 300 OPTION-LENGTH the value 1. 302 FLAGS Flags field. Bit 7 of this field is the request/acknowledge 303 flag. This bit MUST be clear in requests from the resolver to the 304 authoritative server and MUST be set in responses from the 305 authoritative server to the resolver. By flipping the bit in a 306 response, answers from misbehaving authoritiative servers that 307 just copy unknown EDNS0 options from query to response are not 308 mistakenly treated as being from servers that understand 309 opportunistic DNS refresh. 311 Bits 0 to 6 of the FLAGS field are reserved. They MUST be set to 312 zero by the sender, and MUST be ignored by the receiving server. 314 6. Security Considerations 316 TDB 318 7. IANA considerations 320 The IANA is directed to assign an EDNS0 option code for the 321 ZONERSERIAL option from the DNS EDNS0 Option Codes (OPT) registry as 322 follows: 324 +-------+------------+--------+-----------------+ 325 | Value | Name | Status | Reference | 326 +-------+------------+--------+-----------------+ 327 | TBD | ZONESERIAL | TBD | [This document] | 328 +-------+------------+--------+-----------------+ 330 8. Acknowledgements 332 This document evolved from discussions with a number of people during 333 and after IETF-94: Ray Bellis, Geoff Huston, George Michaelson, Cathy 334 Almond, Mark Andrews, Evan Hunt, Witold Krecicki. We would also like 335 to acknowledge Bob Harold, who suggested the underlying idea in a 336 post to the DNSOP mailing list back in October 2015. 338 9. References 340 9.1. Normative references 342 [RFC1035] Mockapetris, P., "Domain names - implementation and 343 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 344 November 1987, . 346 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 347 DOI 10.17487/RFC1982, August 1996, 348 . 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, 352 DOI 10.17487/RFC2119, March 1997, 353 . 355 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 356 for DNS (EDNS(0))", STD 75, RFC 6891, 357 DOI 10.17487/RFC6891, April 2013, 358 . 360 9.2. Informative references 362 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 363 Kumari, "Client Subnet in DNS Queries", RFC 7871, 364 DOI 10.17487/RFC7871, May 2016, 365 . 367 Appendix A. Change history (to be removed before publication) 369 o draft-muks-dnsop-dns-opportunistic-refresh-00 370 Initial draft. 372 Authors' Addresses 374 Mukund Sivaraman 375 Internet Systems Consortium 376 950 Charter Street 377 Redwood City, CA 94063 378 US 380 Email: muks@isc.org 381 URI: http://www.isc.org/ 383 Shane Kerr 384 Oracle 386 Email: shane@timetravellers.org 388 Stephen Morris 389 Internet Systems Consortium 390 950 Charter Street 391 Redwood City, CA 94063 392 US 394 Email: stephen@isc.org 395 URI: http://www.isc.org/