idnits 2.17.1 draft-ietf-dnsop-serve-stale-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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC1034, but the abstract doesn't seem to directly say this. It does mention RFC1034 though, so this could be OK. -- The draft header indicates that this document updates RFC1035, but the abstract doesn't seem to directly say this. It does mention RFC1035 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1034, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 2018) is 2020 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 informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group D. Lawrence 3 Internet-Draft Oracle + Dyn 4 Updates: 1034, 1035 (if approved) W. Kumari 5 Intended status: Standards Track P. Sood 6 Expires: April 17, 2019 Google 7 October 14, 2018 9 Serving Stale Data to Improve DNS Resiliency 10 draft-ietf-dnsop-serve-stale-02 12 Abstract 14 This draft defines a method for recursive resolvers to use stale DNS 15 data to avoid outages when authoritative nameservers cannot be 16 reached to refresh expired data. It updates the definition of TTL 17 from [RFC1034] and [RFC1035] to make it clear that data can be kept 18 in the cache beyond the TTL expiry and used for responses when a 19 refreshed answer is not readily available. 21 Ed note 23 Text inside square brackets ([]) is additional background 24 information, answers to frequently asked questions, general musings, 25 etc. They will be removed before publication. This document is 26 being collaborated on in GitHub at . The most recent version of the document, open issues, etc 28 should all be available here. The authors gratefully accept pull 29 requests. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 17, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Notes to readers . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5. Standards Action . . . . . . . . . . . . . . . . . . . . . . 4 70 6. EDNS Option . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 6.1. Option Format Proposal 1 . . . . . . . . . . . . . . . . 5 72 6.2. Option Usage . . . . . . . . . . . . . . . . . . . . . . 6 73 6.3. Option Format Proposal 2 . . . . . . . . . . . . . . . . 7 74 7. Example Method . . . . . . . . . . . . . . . . . . . . . . . 7 75 8. Implementation Caveats . . . . . . . . . . . . . . . . . . . 9 76 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 79 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 15.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 15.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Traditionally the Time To Live (TTL) of a DNS resource record has 90 been understood to represent the maximum number of seconds that a 91 record can be used before it must be discarded, based on its 92 description and usage in [RFC1035] and clarifications in [RFC2181]. 94 This document proposes that the definition of the TTL be explicitly 95 expanded to allow for expired data to be used in the exceptional 96 circumstance that a recursive resolver is unable to refresh the 97 information. It is predicated on the observation that authoritative 98 server unavailability can cause outages even when the underlying data 99 those servers would return is typically unchanged. 101 We describe a method below for this use of stale data, balancing the 102 competing needs of resiliency and freshness. While this is intended 103 to be immediately useful to the installed base of DNS software, we 104 also propose an [RFC6891] EDNS option for enhanced signalling around 105 the use of stale data by implementations that understand it. 107 2. Notes to readers 109 [ RFC Editor, please remove this section before publication! 110 Readers: This is conversational text to describe what we've done, and 111 will be removed, please don't bother sending editorial nits. :-) ] 113 Due to circumstances, the authors of this document got sidetracked, 114 and we lost focus. We are now reviving it, and are trying to address 115 and incorporate comments. There has also been more deployment and 116 implementation recently, and so this document is now more describing 117 what is known to work instead of simply proposing a concept. 119 Open questions: 121 o The EDNS option that we propose for debugging is relatively full- 122 featured to identify which RRsets are stale. It could be 123 simplified to just indicate that an answer is stale, or even 124 removed entirely in favour of an Extended Error result that 125 indicates staleness. 127 o What TTL value to recommend be set in stale answers returned by 128 recursive resolvers. 130 3. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in 135 [RFC2119] when, and only when, they appear in all capitals, as shown 136 here. 138 For a comprehensive treatment of DNS terms, please see [RFC7719]. 140 4. Background 142 There are a number of reasons why an authoritative server may become 143 unreachable, including Denial of Service (DoS) attacks, network 144 issues, and so on. If the recursive server is unable to contact the 145 authoritative servers for a name but still has relevant data that has 146 aged past its TTL, that information can still be useful for 147 generating an answer under the metaphorical assumption that, "stale 148 bread is better than no bread." 150 [RFC1035] Section 3.2.1 says that the TTL "specifies the time 151 interval that the resource record may be cached before the source of 152 the information should again be consulted", and Section 4.1.3 further 153 says the TTL, "specifies the time interval (in seconds) that the 154 resource record may be cached before it should be discarded." 156 A natural English interpretation of these remarks would seem to be 157 clear enough that records past their TTL expiration must not be used, 158 However, [RFC1035] predates the more rigorous terminology of 159 [RFC2119] which softened the interpretation of "may" and "should". 161 [RFC2181] aimed to provide "the precise definition of the Time to 162 Live" but in Section 8 was mostly concerned with the numeric range of 163 values and the possibility that very large values should be capped. 164 (It also has the curious suggestion that a value in the range 165 2147483648 to 4294967295 should be treated as zero.) It closes that 166 section by noting, "The TTL specifies a maximum time to live, not a 167 mandatory time to live." This is again not [RFC2119]-normative 168 language, but does convey the natural language connotation that data 169 becomes unusable past TTL expiry. 171 Several major recursive resolver operators currently use stale data 172 for answers in some way, including Akamai (via both Nomimum and 173 Xerocole), Knot, OpenDNS, and Unbound. Apple can also use stale data 174 as part of the Happy Eyeballs algorithms in mDNSResponder. The 175 collective operational experience is that it provides significant 176 benefit with minimal downside. 178 5. Standards Action 180 The definition of TTL in [RFC1035] Sections 3.2.1 and 4.1.3 is 181 amended to read: 183 TTL a 32 bit unsigned integer number of seconds in the range 0 - 184 2147483647 that specifies the time interval that the resource 185 record MAY be cached before the source of the information MUST 186 again be consulted. Zero values are interpreted to mean that the 187 RR can only be used for the transaction in progress, and should 188 not be cached. Values with the high order bit set SHOULD be 189 capped at no more than 2147483647. If the authority for the data 190 is unavailable when attempting to refresh the data past the given 191 interval, the record MAY be used as though it is unexpired. 193 [ Discussion point: capping values with the high order bit as being 194 max positive, rather than 0, is a change from [RFC2181]. Also, we 195 could use this opportunity to recommend a much more sane maximum 196 value like 604800 seconds, one week, instead of the literal maximum 197 of 68 years. ] 199 6. EDNS Option 201 While the basic behaviour of this answer-of-last-resort can be 202 achieved with changes only to resolvers, explicit signalling about 203 the use of stale data can be done with an EDNS [RFC6891] option. 204 This option can be included from a stub or forwarding resolver to a 205 recursive resolver, explicitly signalling that it does not want stale 206 answers, or for learning that stale data was in use. It is expected 207 that this could be useful for debugging. 209 [ NOTE: This section will be fleshed out a bit more thoroughly if 210 there is interest in pursuing the option. Here are two potential 211 options that could be used, one more fully-featured to indicate which 212 RRsets are stale and one much more simple to indicate that stale data 213 is present. These are proposed as mutually exclusive; the final 214 document will have one or zero such options. We're especially 215 soliciting feedback on this from the working group. ] 217 6.1. Option Format Proposal 1 219 The option is structured as follows: 221 +0 (MSB) +1 (LSB) 222 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 223 0: | OPTION-CODE | 224 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 225 2: | OPTION-LENGTH | 226 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 227 4: | STALE-RRSET-INDEX 1 | 228 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 229 6: | | 230 8: | TTL-EXPIRY 1 | 231 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 232 : ... additional STALE-RRSET-INDEX / TTL-EXPIRY pairs ... : 233 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 235 OPTION-CODE: 2 octets per [RFC6891]. For Serve-Stale the code is 236 TBD by IANA. 238 OPTION-LENGTH: 2 octets per [RFC6891]. Contains the length of the 239 payload following OPTION-LENGTH, in octets. 241 STALE-RRSET-INDEX: Two octets as a signed integer, indicating the 242 first RRSet in the message which is beyond its TTL, with RRSet 243 counting starting at 1 and spanning message sections. 245 TTL-EXPIRY: Four octets as an unsigned integer, representing the 246 number of seconds that have passed since the TTL for the RRset 247 expired. 249 6.2. Option Usage 251 Software making a DNS request can signal that it understands Serve- 252 Stale by including the option with one STALE-RRSET-INDEX initialized 253 to any negative value and TTY-EXPIRY initialized to 0. The index is 254 set to a negative value to detect mere reflection of the option by 255 responders that don't really understand it. 257 If the request is made to a recursive resolver which used any stale 258 RRsets in its reply, it then fills in the corresponding indices and 259 staleness values. If no records are stale, STALE-RRSET-INDEX and 260 TTL-EXPIRY are set to 0. 262 If the request is made to an authoritative nameserver, it can use the 263 option in the reply to indicate how the resolver should treat the 264 records in the reply if they are unable to be refreshed later. A 265 default for all RRsets in the message is established by setting the 266 first STALE-RRSET-INDEX to 0, with optional additional STALE-RRSET- 267 INDEX values overriding the default. A TTL-EXPIRY value of 0 means 268 to never serve the RRset as stale, while non-zero values represent 269 the maximum amount of time it can be used before it MUST be evicted. 270 [ Does anyone really want to do this? It adds more state into 271 resolvers. Is the idea only for purists, or is there a practical 272 application? ] 274 No facility is made for a client of a resolver to signal that it 275 doesn't want stale answers, because if a client has knowledge of 276 Serve-Stale as an option, it also has enough knowledge to just ignore 277 any records that come back stale. [ There is admittedly the issue 278 that the client might just want to wait out the whole attempted 279 resolution, which there's currently no way to indicate. The absolute 280 value of STALE-RRSET-INDEX could be taken as a timer the requester is 281 willing to wait for an answer, but that's kind of gross overloading 282 it like that. Shame to burn another field on that, but on the other 283 hand it might also be nice if a client could always signal its 284 impatience level - "I must have an answer within 900 milliseconds!" ] 286 6.3. Option Format Proposal 2 288 The option is structured as follows: 290 +0 (MSB) +1 (LSB) 291 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 292 0: | OPTION-CODE | 293 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 294 2: | OPTION-LENGTH | 295 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 296 4: | D | U | S | RESERVED | 297 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 299 OPTION-CODE: 2 octets per [RFC6891]. For Serve-Stale the code is 300 TBD by IANA. 302 OPTION-LENGTH: 2 octets per [RFC6891]. Contains the length of the 303 payload following OPTION-LENGTH, in octets. 305 D Flag: If set, the client explicitly does NOT want stale answers. 306 If clear, the client would like an indication of whether any data 307 in the response is stale. 309 U Flag: This indicates that the server understands the Serve-Stale 310 EDNS option, and more information is communicated via the S flag. 311 It exists to get around the issue of some authorative servers 312 simply echoing back ENDS options it does not understand. 314 S Flag: If set, this indicates that the response contains stale 315 data. If clear, no data in the response has reached its TTL 316 expiry. 318 RESERVED: Reserved for future use. Should be set to zero on send 319 and ignored on receipt. 321 7. Example Method 323 There is conceivably more than one way a recursive resolver could 324 responsibly implement this resiliency feature while still respecting 325 the intent of the TTL as a signal for when data is to be refreshed. 327 In this example method three notable timers drive considerations for 328 the use of stale data, as follows: 330 o A client response timer, which is the maximum amount of time a 331 recursive resolver should allow between the receipt of a 332 resolution request and sending its response. 334 o A query resolution timer, which caps the total amount of time a 335 recursive resolver spends processing the query. 337 o A maximum stale timer, which caps the amount of time that records 338 will be kept past their expiration. 340 Recursive resolvers already have the second timer; the first and 341 third timers are new concepts for this mechanism. 343 When a request is received by the recursive resolver, it SHOULD start 344 the client response timer. This timer is used to avoid client 345 timeouts. It SHOULD be configurable, with a recommended value of 1.8 346 seconds. 348 The resolver then checks its cache for an unexpired answer. If it 349 finds none and the Recursion Desired flag is not set in the request, 350 it SHOULD immediately return the response without consulting the 351 cache for expired records. 353 If iterative lookups will be done, it SHOULD start the query 354 resolution timer. This timer bounds the work done by the resolver, 355 and is commonly around 10 to 30 seconds. 357 If the answer has not been completely determined by the time the 358 client response timer has elapsed, the resolver SHOULD then check its 359 cache to see whether there is expired data that would satisfy the 360 request. If so, it adds that data to the response message and SHOULD 361 set the TTL of each expired record in the message to 30 seconds. The 362 response is then sent to the client while the resolver continues its 363 attempt to refresh the data. 30 second was chosen because 364 historically 0 second TTLs have been problematic for some 365 implementations, and similarly very short TTLs could lead to 366 congestive collapse as TTL-respecting clients rapidly try to refresh. 367 30 seconds not only sidesteps those potential problems with no 368 practical negative consequence, it would also rate limit further 369 queries from any client that is honoring the TTL, such as a 370 forwarding resolver. [ NOTE: we're looking for further working group 371 feedback on this value. ] 373 The maximum stale timer is used for cache management and is 374 independent of the query resolution process. This timer is 375 conceptually different from the maximum cache TTL that exists in many 376 resolvers, the latter being a clamp on the value of TTLs as received 377 from authoritative servers. The maximum stale timer SHOULD be 378 configurable, and defines the length of time after a record expires 379 that it SHOULD be retained in the cache. The suggested value is 7 380 days, which gives time to notice the resolution problem and for human 381 intervention to fix it. 383 This same basic technique MAY be used to handle stale data associated 384 with delegations. If authoritative server addresses are not able to 385 be refreshed, resolution can possibly still be successful if the 386 authoritative servers themselves are still up. 388 8. Implementation Caveats 390 Answers from authoritative servers that have a DNS Response Code of 391 either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have 392 refreshed the data at the resolver. In particular, this means that 393 this method is not meant to protect against operator error at the 394 authoritative server that turns a name that is intended to be valid 395 into one that is non-existent, because there is no way for a resolver 396 to know intent. 398 Resolution is given a chance to succeed before stale data is used to 399 adhere to the original intent of the design of the DNS. This 400 mechanism is only intended to add robustness to failures, and to be 401 enabled all the time. If stale data were used immediately and then a 402 cache refresh attempted after the client response has been sent, the 403 resolver would frequently be sending data that it would have had no 404 trouble refreshing. As modern resolvers use techniques like pre- 405 fetching and request coalescing for efficiency, it is not necessary 406 that every client request needs to trigger a new lookup flow in the 407 presence of stale data, but rather than a good-faith effort have been 408 recently made to refresh the stale data before it is delivered to any 409 client. The recommended period between attempting refreshes is 30 410 seconds. 412 It is important to continue the resolution attempt after the stale 413 response has been sent, until the query resolution timeout, because 414 some pathological resolutions can take many seconds to succeed as 415 they cope with unavailable servers, bad networks, and other problems. 416 Stopping the resolution attempt when the response with expired data 417 has been sent would mean that answers in these pathological cases 418 would never be refreshed. 420 Canonical Name (CNAME) records mingled in the expired cache with 421 other records at the same owner name can cause surprising results. 422 This was observed with an initial implementation in BIND when a 423 hostname changed from having an IPv4 Address (A) record to a CNAME. 424 The version of BIND being used did not evict other types in the cache 425 when a CNAME was received, which in normal operations is not a 426 significant issue. However, after both records expired and the 427 authorities became unavailable, the fallback to stale answers 428 returned the older A instead of the newer CNAME. 430 [ This probably applies to other occluding types, so more thought 431 should be given to the overall issue. ] 433 Keeping records around after their normal expiration will of course 434 cause caches to grow larger than if records were removed at their 435 TTL. Specific guidance on managing cache sizes is outside the scope 436 of this document. Some areas for consideration include whether to 437 track the popularity of names in client requests versus evicting by 438 maximum age, and whether to provide a feature for manually flushing 439 only stale records. 441 9. Implementation Status 443 [RFC Editor: per RFC 6982 this section should be removed prior to 444 publication.] 446 The algorithm described in the Section 7 section was originally 447 implemented as a patch to BIND 9.7.0. It has been in production on 448 Akamai's production network since 2011, and effectively smoothed over 449 transient failures and longer outages that would have resulted in 450 major incidents. The patch was contributed to Internet Systems 451 Consortium and the functionality is now available in BIND 9.12 via 452 the options stale-answer-enable, stale-answer-ttl, and max-stale-ttl. 454 Unbound has a similar feature for serving stale answers, but it works 455 in a very different way by returning whatever cached answer it has 456 before trying to refresh expired records. This is unfortunately not 457 faithful to the ideal that data past expiry should attempt to be 458 refreshed before being served. 460 Knot Resolver has an demo module here: https://knot- 461 resolver.readthedocs.io/en/stable/modules.html#serve-stale 463 Details of Apple's implementation are not currently known. 465 In the research paper "When the Dike Breaks: Dissecting DNS Defenses 466 During DDoS" [DikeBreaks], the authors detected some use of stale 467 answers by resolvers when authorities came under attack. Their 468 research results suggest that more widespread adoption of the 469 technique would significantly improve resiliency for the large number 470 of requests that fail or experience abnormally long resolution times 471 during an attack. 473 10. Security Considerations 475 The most obvious security issue is the increased likelihood of DNSSEC 476 validation failures when using stale data because signatures could be 477 returned outside their validity period. This would only be an issue 478 if the authoritative servers are unreachable, the only time the 479 techniques in this document are used, and thus does not introduce a 480 new failure in place of what would have otherwise been success. 482 Additionally, bad actors have been known to use DNS caches to keep 483 records alive even after their authorities have gone away. This 484 potentially makes that easier, although without introducing a new 485 risk. 487 11. Privacy Considerations 489 This document does not add any practical new privacy issues. 491 12. NAT Considerations 493 The method described here is not affected by the use of NAT devices. 495 13. IANA Considerations 497 This document contains no actions for IANA. This section will be 498 removed during conversion into an RFC by the RFC editor. 500 14. Acknowledgements 502 The authors wish to thank Matti Klock, Mukund Sivaraman, Jean Roy, 503 and Jason Moreau for initial review. Feedback from Robert Edmonds, 504 Giovane Moura, Davey Song, and Ralf Weber has also been incorporated. 506 15. References 508 15.1. Normative References 510 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 511 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 512 . 514 [RFC1035] Mockapetris, P., "Domain names - implementation and 515 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 516 November 1987, . 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, 520 DOI 10.17487/RFC2119, March 1997, 521 . 523 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 524 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 525 . 527 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 528 for DNS (EDNS(0))", STD 75, RFC 6891, 529 DOI 10.17487/RFC6891, April 2013, 530 . 532 15.2. Informative References 534 [DikeBreaks] 535 Moura, G., Heidemann, J., Mueller, M., Schmidt, R., and M. 536 Davids, "When the Dike Breaks: Dissecting DNS Defenses 537 During DDos", ACM 2018 Internet Measurement Conference, 538 DOI 10.1145/3278532.3278534, October 2018, 539 . 541 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 542 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 543 2015, . 545 Authors' Addresses 547 David C Lawrence 548 Oracle + Dyn 550 Email: tale@dd.org 552 Warren Kumari 553 Google 554 1600 Amphitheatre Parkway 555 Mountain View CA 94043 556 USA 558 Email: warren@kumari.net 560 Puneet Sood 561 Google 563 Email: puneets@google.com