idnits 2.17.1 draft-sury-toorop-dnsop-server-cookies-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 document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC7873]), 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 26, 2019) is 1728 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) == Missing Reference: 'DNSCOOKIE-IANA' is mentioned on line 349, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group O. Sury 3 Internet-Draft Internet Systems Consortium 4 Updates: 7873 (if approved) W. Toorop 5 Intended status: Standards Track NLnet Labs 6 Expires: December 28, 2019 D. Eastlake 3rd 7 Futurewei Technologies 8 M. Andrews 9 Internet Systems Consortium 10 June 26, 2019 12 Interoperable Domain Name System (DNS) Server Cookies 13 draft-sury-toorop-dnsop-server-cookies-00 15 Abstract 17 DNS cookies, as specified in RFC 7873, are a lightweight DNS 18 transaction security mechanism that provides limited protection to 19 DNS servers and clients against a variety of denial-of-service and 20 amplification, forgery, or cache poisoning attacks by off-path 21 attackers. 23 This document provides precise directions for creating Server Cookies 24 so that an anycast server set including diverse implementations will 25 interoperate with standard clients. 27 This document updates [RFC7873] 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 28, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Contents of this document . . . . . . . . . . . . . . . . 3 65 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Changes to [RFC7873] . . . . . . . . . . . . . . . . . . . . 4 67 3. Constructing a Client Cookie . . . . . . . . . . . . . . . . 4 68 4. Constructing a Server Cookie . . . . . . . . . . . . . . . . 5 69 4.1. The Version Sub-Field . . . . . . . . . . . . . . . . . . 5 70 4.2. The Reserved Sub-Field . . . . . . . . . . . . . . . . . 5 71 4.3. The Timestamp Sub-Field . . . . . . . . . . . . . . . . . 5 72 4.4. The Hash Sub-Field . . . . . . . . . . . . . . . . . . . 6 73 5. Updating the Server Secret . . . . . . . . . . . . . . . . . 6 74 6. Cookie Algorithms . . . . . . . . . . . . . . . . . . . . . . 7 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 8.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 80 Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 9 81 B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 9 82 B.2. The same client learning a renewed (fresh) Server Cookie 10 83 B.3. Another client learning a renewed Server Cookie . . . . . 11 84 B.4. IPv6 query with rolled over secret . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 DNS cookies, as specified in [RFC7873], are a lightweight DNS 90 transaction security mechanism that provides limited protection to 91 DNS servers and clients against a variety of denial-of-service and 92 amplification, forgery, or cache poisoning attacks by off-path 93 attackers. This document specifies a means of producing 94 interoperable strong cookies so that an anycast server set including 95 diverse implementations can be easily configured to interoperate with 96 standard clients. 98 The threats considered for DNS Cookies and the properties of the DNS 99 Security features other than DNS Cookies are discussed in [RFC7873]. 101 In [RFC7873] in Section 6 it is "RECOMMENDED for simplicity that the 102 same Server Secret be used by each DNS server in a set of anycast 103 servers." However, how precisely a Server Cookie is calculated from 104 this Server Secret, is left to the implementation. 106 This guidance has led to a gallimaufry of DNS Cookie implementations, 107 calculating the Server Cookie in different ways. As a result, DNS 108 Cookies are impractical to deploy on multi-vendor anycast networks, 109 because even when all DNS Software share the same secret, as 110 RECOMMENDED in Section 6 of [RFC7873], the Server Cookie constructed 111 by one implementation cannot generally be validated by another. 113 There is no need for DNS client (resolver) Cookies to be 114 interoperable across different implementations. Each client need 115 only be able to recognize its own cookies. However, this document 116 does contain recommendations for constructing Client Cookies in a 117 Client protecting fashion. 119 1.1. Contents of this document 121 Section Section 2 summarises the changes to [RFC7873]. 123 In Section Section 3 suggestions for constructing a Client Cookie are 124 given. 126 In Section Section 4 instructions for constructing a Server Cookie 127 are given. 129 In Section Section 5 instructions on updating Server Secrets are 130 given. 132 In Section Section 6 the different hash functions usable for DNS 133 Cookie construction are listed. [FNV] and HMAC-SHA-256-64 [RFC6234] 134 are deprecated and [SipHash-2.4] is introduced as a REQUIRED hash 135 function for server side DNS Cookie implementations. 137 IANA considerations are in Section 7. 139 Acknowledgements are in Appendix A. 141 Test vectors are in Appendix B. 143 1.2. Definitions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "*NOT RECOMMENDED*", "MAY", 147 and "OPTIONAL" in this document are to be interpreted as described in 148 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 o "IP Address" is used herein as a length independent term covering 152 both IPv4 and IPv6 addresses. 154 2. Changes to [RFC7873] 156 In its Appendices A.1 and B.1, [RFC7873] provides example "simple" 157 algorithms for computing Client and Server Cookies, respectively. 158 These algorithms MUST NOT be used as the resulting cookies are too 159 weak when evaluated against modern security standards. 161 In its Appendix B.2, [RFC7873] provides an example "more complex" 162 server algorithm. This algorithm is replaced by the interoperable 163 specification in Section 4 of this document, which MUST be used by 164 Server Cookie implementations. 166 This document has suggestions on Client Cookie construction in 167 Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT 168 RECOMMENDED. 170 3. Constructing a Client Cookie 172 The Client Cookie is a nonce and should be treated as such. For 173 simplicity, it can be calculated from Client IP Address, Server IP 174 Address, and a secret known only to the Client. The Client Cookie 175 SHOULD have at least 64-bits of entropy. If a secure pseudorandom 176 function (like [SipHash-2.4]) is used, there's no need to change 177 Client secret often. It is reasonable to change the Client secret 178 only if it has been compromised or after a relatively long period of 179 time such as no longer than a year. 181 It is RECOMMENDED but not required that the following pseudorandom 182 function be used to construct the Client Cookie: 184 Client-Cookie = MAC_Algorithm( 185 Client IP Address | Server IP Address, Client Secret ) 187 where "|" indicates concatenation. 189 4. Constructing a Server Cookie 191 The Server Cookie is effectively a Message Authentication Code (MAC) 192 and should be treated as such. The Server Cookie is calculated from 193 the Client Cookie, a series of Sub-Fields specified below, the Client 194 IP address, and a Server Secret known only to the servers responding 195 on the same address in an anycast set. 197 Changing the Server Secret regularly Is RECOMMENDED but, when a 198 secure pseudorandom function is used, it need not be changed too 199 frequent. For example once a month would be adequate. See Section 5 200 on operator and implementation guidelines for updating a Server 201 Secret. 203 The 128-bit Server Cookie consists of Sub-Fields: a 1 octet Version 204 Sub-Field, a 3 octet Reserved Sub-Field, a 4 octet Timestamp Sub- 205 Field and an 8 octet Hash Sub-Field. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Version | Reserved | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Timestamp | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Hash | 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 4.1. The Version Sub-Field 220 The Version Sub-Field prescribes the structure and Hash calculation 221 formula. This document defines Version 1 to be the structure and way 222 to calculate the Hash Sub-Field as defined in this Section. 224 4.2. The Reserved Sub-Field 226 The value of the Reserved Sub-Field is reserved for future versions 227 of Server Side Cookie construction. On construction it SHOULD be set 228 to zero octets. On Server Cookie verification the server MUST NOT 229 enforce those fields to be zero and the Hash should be computed with 230 the received value as described in Section 4.4. 232 4.3. The Timestamp Sub-Field 234 The Timestamp value prevents Replay Attacks and MUST be checked by 235 the server to be within a defined period of time. The DNS Server 236 SHOULD allow Cookies within 1 hour period in the past and 5 minutes 237 into the future to allow operation of low volume clients and some 238 limited time skew between the DNS servers in the anycast. 240 The Timestamp value specifies a date and time in the form of a 32-bit 241 unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, 242 ignoring leap seconds, in network byte order. All comparisons 243 involving these fields MUST use "Serial number arithmetic", as 244 defined in [RFC1982] 246 The DNS Server SHOULD generate a new Server Cookie at least if the 247 received Server Cookie from the Client is more than half an hour old. 249 4.4. The Hash Sub-Field 251 It's important that all the DNS servers use the same algorithm for 252 computing the Server Cookie. This document defines the Version 1 of 253 the Server Side algorithm to be: 255 Hash = SipHash2.4( 256 Client Cookie | Version | Reserved | Timestamp | Client-IP, 257 Server Secret ) 259 Notice that Client-IP is used for hash generation even though it's 260 not included in the cookie value itself. Client-IP can be either 4 261 bytes for IPv4 or 16 bytes for IPv6. 263 The Server Secret MUST be configurable to make sure that servers in 264 an anycast network return consistent results. 266 5. Updating the Server Secret 268 All servers in an anycast group must be able to verify the Server 269 Cookies constructed by all other servers in that anycast set at all 270 times. Therefore it is vital that the Server Secret is shared among 271 all servers before it us used to generate Server Cookies. 273 Also, to maximize maintaining established relationships between 274 clients and servers, an old Server Secret should be valid for 275 verification purposes for a specific period. 277 To facilitate this, deployment of a new Server Secret MUST be done in 278 three stages: 280 Stage 1 281 The new Server Secret is deployed on all the servers in an anycast 282 set by the operator. 284 Each server learns the new Server Secret, but keeps using the 285 previous Server Secret to generate Server Cookies. 287 Server Cookies constructed with the both the new Server Secret and 288 with the previous Server Secret are considered valid when 289 verifying. 291 After stage 1 completed, all the servers in the anycast set have 292 learned the new Server Secret, and can verify Server Cookies 293 constructed with it, but keep generator Server Cookies with the 294 old Server Secret. 296 Stage 2 297 This stage is initiated by the operator after the Server Cookie is 298 present on all members in the anycast set. 300 When entering Stage 2, servers start generating Server Cookies 301 with the new Server Secret. The previous Server Secret is not yet 302 removed/forgotten about. 304 Server Cookies constructed with the both the new Server Secret and 305 with the previous Server Secret are considered valid when 306 verifying. 308 Stage 3 309 This stage is initiated by the operator when it can be assumed 310 that most clients have learned the new Server Secret. 312 With this stage, the previous Server Secret can be removed and 313 MUST NOT be used anymore for verifying. 315 We RECOMMEND the operator to wait at least a period to be the 316 longest TTL in the zones served by the server plus half an hour 317 after it initiated Stage 2, before initiating Stage 3. 319 The operator SHOULD wait at least longer than the period clients 320 are allowed to use the same Server Cookie, which SHOULD be half an 321 hour, see Section 4.3. 323 6. Cookie Algorithms 325 [SipHash-2.4] is a pseudorandom function suitable as Message 326 Authentication Code. This document REQUIRES compliant DNS Server to 327 use SipHash-2.4 as a mandatory and default algorithm for DNS Cookies 328 to ensure interoperability between the DNS Implementations. 330 The construction method and pseudorandom function used in calculating 331 and verifying the Server Cookies are determined by the initial 332 version byte and by the length of the Server Cookie. Additional 333 pseudorandom or construction algorithms for Server Cookies might be 334 added in the future. 336 7. IANA Considerations 338 IANA is requested to create a registry on the "Domain Name System 339 (DNS) Parameters" IANA web page as follows: 341 Registry Name: DNS Server Cookie Methods 342 Assignment Policy: Expert Review 343 Reference: [this document], [RFC7873] 344 Note: Server Cookie method (construction and pseudorandom algorithm) 345 are determined by the Version in the first byte of the Cookie and by 346 the Cookie size. Server Cookie size is limited to the inclusive 347 range of 8 to 32 bytes. 349 Implementation recommendations for Cookie Algorithms [DNSCOOKIE- 350 IANA]: 352 +---------+-------+---------------------------------------+ 353 | Version | Size | Method | 354 +---------+-------+---------------------------------------+ 355 | 0 | 8-32 | reserved | 356 | 1 | 8-15 | unassiged | 357 | 1 | 16 | SipHash-2.4 [this document] Section 4 | 358 | 1 | 17-32 | unassigned | 359 | 2-239 | 8-32 | unassigned | 360 | 240-254 | 8-32 | private use | 361 | 255 | 8-32 | reserved | 362 +---------+-------+---------------------------------------+ 364 8. References 366 8.1. Normative References 368 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 369 DOI 10.17487/RFC1982, August 1996, 370 . 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, 374 DOI 10.17487/RFC2119, March 1997, 375 . 377 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 378 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 379 . 381 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 382 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 383 May 2017, . 385 [SipHash-2.4] 386 Aumasson, J. and D. Bernstein, "SipHash: a fast short- 387 input PRF", 2012, . 389 8.2. Informative References 391 [FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen, 392 "The FNV Non-Cryptographic Hash Algorithm", 393 . 395 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 396 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 397 DOI 10.17487/RFC6234, May 2011, 398 . 400 Appendix A. Acknowledgements 402 Thanks to Witold Krecicki and Pieter Lexis for valuable input, 403 suggestions and text and above all for implementing a prototype of an 404 interoperable DNS Cookie in Bind9, Knot and PowerDNS during the 405 hackathon of IETF104 in Prague. Thanks for valuable input and 406 suggestions go to Ralph Dolmans, Bob Harold, Daniel Salzman, Martin 407 Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron 409 Appendix B. Test vectors 411 B.1. Learning a new Server Cookie 413 A resolver (client) sending from IPv4 address 198.51.100.100, sends a 414 query for "example.com" to an authoritative server listening on 415 192.0.2.53 from which it has not yet learned the server cookie. 417 The DNS requests and replies shown in this Appendix, are in a "dig" 418 like format. The content of the DNS COOKIE Option is shown in 419 hexadecimal format after "; COOKIE:". 421 ;; Sending: 422 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 423 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 425 ;; OPT PSEUDOSECTION: 426 ; EDNS: version: 0, flags:; udp: 4096 427 ; COOKIE: a05862bf552bbd22 428 ;; QUESTION SECTION: 429 ;example.com. IN A 431 ;; QUERY SIZE: 52 433 The authoritative nameserver (server) is configured with the 434 following secret: e5e973e5a6b2a43f48e7dc849e37bfcf (as hex data). 436 It receives the query at Wed Jun 5 10:53:05 UTC 2019. 438 The content of the DNS COOKIE Option that the server will return is 439 shown below in hexadecimal format after "; COOKIE:" 441 ;; Got answer: 442 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 443 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 445 ;; OPT PSEUDOSECTION: 446 ; EDNS: version: 0, flags:; udp: 4096 447 ; COOKIE: a05862bf552bbd22010000005cf79f11de1bba0952b0ff82 (good) 448 ;; QUESTION SECTION: 449 ;example.com. IN A 451 ;; ANSWER SECTION: 452 example.com. 86400 IN A 192.0.2.34 454 ;; Query time: 6 msec 455 ;; SERVER: 192.0.2.53#53(192.0.2.53) 456 ;; WHEN: Wed Jun 5 10:53:05 UTC 2019 457 ;; MSD SIZE rcvd: 84 459 B.2. The same client learning a renewed (fresh) Server Cookie 461 40 minutes later, the same resolver (client) queries the same server 462 for for "example.org" : 464 ;; Sending: 465 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 466 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 468 ;; OPT PSEUDOSECTION: 469 ; EDNS: version: 0, flags:; udp: 4096 470 ; COOKIE: a05862bf552bbd22010000005cf79f11de1bba0952b0ff82 471 ;; QUESTION SECTION: 472 ;example.org. IN A 474 ;; QUERY SIZE: 52 476 The authoritative nameserver (server) now generates a new Server 477 Cookie. The server SHOULD do this because it can see the Server 478 Cookie send by the client is older than half an hour Section 4.3, but 479 it is also fine for a server to generate a new Server Cookie sooner, 480 or even for every answer. 482 ;; Got answer: 483 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 484 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 486 ;; OPT PSEUDOSECTION: 487 ; EDNS: version: 0, flags:; udp: 4096 488 ; COOKIE: a05862bf552bbd22010000005cf7a87144c909a80f560a7f (good) 489 ;; QUESTION SECTION: 490 ;example.org. IN A 492 ;; ANSWER SECTION: 493 example.org. 86400 IN A 192.0.2.34 495 ;; Query time: 6 msec 496 ;; SERVER: 192.0.2.53#53(192.0.2.53) 497 ;; WHEN: Wed Jun 5 11:33:05 UTC 2019 498 ;; MSD SIZE rcvd: 84 500 B.3. Another client learning a renewed Server Cookie 502 Another resolver (client) with IPv4 address 198.51.100.100 sends a 503 request to the same server with a valid Server Cookie that it learned 504 before (at Wed Jun 5 09:46:25 UTC 2019). Note that the Server Cookie 505 has Reserved bytes set, but is still valid with the configured 506 secret; the Hash part is calculated taking along the Reserved bytes. 508 ;; Sending: 509 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 510 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 512 ;; OPT PSEUDOSECTION: 513 ; EDNS: version: 0, flags:; udp: 4096 514 ; COOKIE: 35fe2405c6e35ce201abcdef5cf78f71f36da1fa58a43879 515 ;; QUESTION SECTION: 516 ;example.com. IN A 518 ;; QUERY SIZE: 52 520 The authoritative nameserver (server) replies with a freshly 521 generated Server Cookie for this client conformant with this 522 specification; so with the Reserved bits set to zero. 524 ;; Got answer: 525 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 526 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 528 ;; OPT PSEUDOSECTION: 529 ; EDNS: version: 0, flags:; udp: 4096 530 ; COOKIE: 35fe2405c6e35ce2010000005cf7a9ac70f66429813e466a (good) 531 ;; QUESTION SECTION: 532 ;example.com. IN A 534 ;; ANSWER SECTION: 535 example.com. 86400 IN A 192.0.2.34 537 ;; Query time: 6 msec 538 ;; SERVER: 192.0.2.53#53(192.0.2.53) 539 ;; WHEN: Wed Jun 5 11:38:20 UTC 2019 540 ;; MSD SIZE rcvd: 84 542 B.4. IPv6 query with rolled over secret 544 The query below is from a client with IPv6 address 545 2001:db8:220:1:59de:d0f4:8769:82b8 to a server with IPv6 address 546 2001:db8:8f::53. The client has learned a valid Server Cookie before 547 when the Server had secret: dd3bdf9344b678b185a6f5cb60fca715. The 548 server now uses a new secret, but it can still validate the Server 549 Cookie provided by the client as the old secret has not expired yet. 551 ;; Sending: 552 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 553 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 555 ;; OPT PSEUDOSECTION: 556 ; EDNS: version: 0, flags:; udp: 4096 557 ; COOKIE: fedba308ab9fddb2010000005cf7c579bbc73b7d5da18dd1 558 ;; QUESTION SECTION: 559 ;example.net. IN A 561 ;; QUERY SIZE: 52 563 The authoritative nameserver (server) replies with a freshly 564 generated server cookie for this client with its new secret: 565 445536bcd2513298075a5d379663c962 567 ;; Got answer: 568 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 569 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 571 ;; OPT PSEUDOSECTION: 572 ; EDNS: version: 0, flags:; udp: 4096 573 ; COOKIE: fedba308ab9fddb2010000005cf7c609449d89428c0e2d92 (good) 574 ;; QUESTION SECTION: 575 ;example.net. IN A 577 ;; ANSWER SECTION: 578 example.net. 86400 IN A 192.0.2.34 580 ;; Query time: 6 msec 581 ;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53) 582 ;; WHEN: Wed Jun 5 13:36:57 UTC 2019 583 ;; MSD SIZE rcvd: 84 585 Authors' Addresses 587 Ondrej Sury 588 Internet Systems Consortium 589 CZ 591 Email: ondrej@isc.org 592 Willem Toorop 593 NLnet Labs 594 Science Park 400 595 Amsterdam 1098 XH 596 Netherlands 598 Email: willem@nlnetlabs.nl 600 Donald E. Eastlake 3rd 601 Futurewei Technologies 602 1424 Pro Shop Court 603 Davenport FL 33896 604 USA 606 Phone: +1-508-333-2270 607 Email: d3e3e3@gmail.com 609 Mark Andrews 610 Internet Systems Consortium 611 950 Charter Street 612 Redwood City CA 94063 613 USA 615 Email: marka@isc.org