idnits 2.17.1 draft-ietf-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 (September 9, 2019) is 1688 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 359, 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: March 12, 2020 D. Eastlake 3rd 7 Futurewei Technologies 8 M. Andrews 9 Internet Systems Consortium 10 September 9, 2019 12 Interoperable Domain Name System (DNS) Server Cookies 13 draft-ietf-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 March 12, 2020. 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 . . . . . . . . . . . . . . . . . 6 72 4.4. The Hash Sub-Field . . . . . . . . . . . . . . . . . . . 6 73 5. Updating the Server Secret . . . . . . . . . . . . . . . . . 6 74 6. Cookie Algorithms . . . . . . . . . . . . . . . . . . . . . . 8 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 Server IP Address, and a secret 174 known only to the Client. The Client Cookie SHOULD have at least 175 64-bits of entropy. If a secure pseudorandom function (like 176 [SipHash-2.4]) is used, there's no need to change Client secret 177 often. It is reasonable to change the Client secret only if it has 178 been compromised or after a relatively long period of time such as no 179 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 Server IP Address, Client Secret ) 187 where "|" indicates concatenation. 189 Previously, the recommended algorithm to compute the Client Cookie 190 included Client IP Address as an input to the MAC_Algorithm. 192 However, when implementing the DNS Cookies, several DNS vendors found 193 impractical to include the Client IP as the Client Cookie is 194 typically computed before the Client IP address is known. Therefore, 195 the requirement to put Client IP address as input to was removed, and 196 it simply RECOMMENDED to disable the DNS Cookies when privacy is 197 required. 199 4. Constructing a Server Cookie 201 The Server Cookie is effectively a Message Authentication Code (MAC) 202 and should be treated as such. The Server Cookie is calculated from 203 the Client Cookie, a series of Sub-Fields specified below, the Client 204 IP address, and a Server Secret known only to the servers responding 205 on the same address in an anycast set. 207 Changing the Server Secret regularly is RECOMMENDED but, when a 208 secure pseudorandom function is used, it need not be changed too 209 frequent. For example once a month would be adequate. See Section 5 210 on operator and implementation guidelines for updating a Server 211 Secret. 213 The 128-bit Server Cookie consists of Sub-Fields: a 1 octet Version 214 Sub-Field, a 3 octet Reserved Sub-Field, a 4 octet Timestamp Sub- 215 Field and an 8 octet Hash Sub-Field. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Version | Reserved | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Timestamp | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Hash | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 4.1. The Version Sub-Field 230 The Version Sub-Field prescribes the structure and Hash calculation 231 formula. This document defines Version 1 to be the structure and way 232 to calculate the Hash Sub-Field as defined in this Section. 234 4.2. The Reserved Sub-Field 236 The value of the Reserved Sub-Field is reserved for future versions 237 of Server Side Cookie construction. On construction it SHOULD be set 238 to zero octets. On Server Cookie verification the server MUST NOT 239 enforce those fields to be zero and the Hash should be computed with 240 the received value as described in Section 4.4. 242 4.3. The Timestamp Sub-Field 244 The Timestamp value prevents Replay Attacks and MUST be checked by 245 the server to be within a defined period of time. The DNS Server 246 SHOULD allow Cookies within 1 hour period in the past and 5 minutes 247 into the future to allow operation of low volume clients and some 248 limited time skew between the DNS servers in the anycast. 250 The Timestamp value specifies a date and time in the form of a 32-bit 251 unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, 252 ignoring leap seconds, in network byte order. All comparisons 253 involving these fields MUST use "Serial number arithmetic", as 254 defined in [RFC1982] 256 The DNS Server SHOULD generate a new Server Cookie at least if the 257 received Server Cookie from the Client is more than half an hour old. 259 4.4. The Hash Sub-Field 261 It's important that all the DNS servers use the same algorithm for 262 computing the Server Cookie. This document defines the Version 1 of 263 the Server Side algorithm to be: 265 Hash = SipHash2.4( 266 Client Cookie | Version | Reserved | Timestamp | Client-IP, 267 Server Secret ) 269 Notice that Client-IP is used for hash generation even though it's 270 not included in the cookie value itself. Client-IP can be either 4 271 bytes for IPv4 or 16 bytes for IPv6. 273 The Server Secret MUST be configurable to make sure that servers in 274 an anycast network return consistent results. 276 5. Updating the Server Secret 278 All servers in an anycast group must be able to verify the Server 279 Cookies constructed by all other servers in that anycast set at all 280 times. Therefore it is vital that the Server Secret is shared among 281 all servers before it us used to generate Server Cookies. 283 Also, to maximize maintaining established relationships between 284 clients and servers, an old Server Secret should be valid for 285 verification purposes for a specific period. 287 To facilitate this, deployment of a new Server Secret MUST be done in 288 three stages: 290 Stage 1 291 The new Server Secret is deployed on all the servers in an anycast 292 set by the operator. 294 Each server learns the new Server Secret, but keeps using the 295 previous Server Secret to generate Server Cookies. 297 Server Cookies constructed with the both the new Server Secret and 298 with the previous Server Secret are considered valid when 299 verifying. 301 After stage 1 completed, all the servers in the anycast set have 302 learned the new Server Secret, and can verify Server Cookies 303 constructed with it, but keep generating Server Cookies with the 304 old Server Secret. 306 Stage 2 307 This stage is initiated by the operator after the Server Cookie is 308 present on all members in the anycast set. 310 When entering Stage 2, servers start generating Server Cookies 311 with the new Server Secret. The previous Server Secret is not yet 312 removed/forgotten about. 314 Server Cookies constructed with the both the new Server Secret and 315 with the previous Server Secret are considered valid when 316 verifying. 318 Stage 3 319 This stage is initiated by the operator when it can be assumed 320 that most clients have learned the new Server Secret. 322 With this stage, the previous Server Secret can be removed and 323 MUST NOT be used anymore for verifying. 325 We RECOMMEND the operator to wait at least a period to be the 326 longest TTL in the zones served by the server plus half an hour 327 after it initiated Stage 2, before initiating Stage 3. 329 The operator SHOULD wait at least longer than the period clients 330 are allowed to use the same Server Cookie, which SHOULD be half an 331 hour, see Section 4.3. 333 6. Cookie Algorithms 335 [SipHash-2.4] is a pseudorandom function suitable as Message 336 Authentication Code. This document REQUIRES compliant DNS Server to 337 use SipHash-2.4 as a mandatory and default algorithm for DNS Cookies 338 to ensure interoperability between the DNS Implementations. 340 The construction method and pseudorandom function used in calculating 341 and verifying the Server Cookies are determined by the initial 342 version byte and by the length of the Server Cookie. Additional 343 pseudorandom or construction algorithms for Server Cookies might be 344 added in the future. 346 7. IANA Considerations 348 IANA is requested to create a registry on the "Domain Name System 349 (DNS) Parameters" IANA web page as follows: 351 Registry Name: DNS Server Cookie Methods 352 Assignment Policy: Expert Review 353 Reference: [this document], [RFC7873] 354 Note: Server Cookie method (construction and pseudorandom algorithm) 355 are determined by the Version in the first byte of the Cookie and by 356 the Cookie size. Server Cookie size is limited to the inclusive 357 range of 8 to 32 bytes. 359 Implementation recommendations for Cookie Algorithms [DNSCOOKIE- 360 IANA]: 362 +---------+-------+---------------------------------------+ 363 | Version | Size | Method | 364 +---------+-------+---------------------------------------+ 365 | 0 | 8-32 | reserved | 366 | 1 | 8-15 | unassiged | 367 | 1 | 16 | SipHash-2.4 [this document] Section 4 | 368 | 1 | 17-32 | unassigned | 369 | 2-239 | 8-32 | unassigned | 370 | 240-254 | 8-32 | private use | 371 | 255 | 8-32 | reserved | 372 +---------+-------+---------------------------------------+ 374 8. References 376 8.1. Normative References 378 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 379 DOI 10.17487/RFC1982, August 1996, 380 . 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 388 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 389 . 391 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 392 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 393 May 2017, . 395 [SipHash-2.4] 396 Aumasson, J. and D. Bernstein, "SipHash: a fast short- 397 input PRF", 2012, . 399 8.2. Informative References 401 [FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen, 402 "The FNV Non-Cryptographic Hash Algorithm", 403 . 405 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 406 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 407 DOI 10.17487/RFC6234, May 2011, 408 . 410 Appendix A. Acknowledgements 412 Thanks to Witold Krecicki and Pieter Lexis for valuable input, 413 suggestions and text and above all for implementing a prototype of an 414 interoperable DNS Cookie in Bind9, Knot and PowerDNS during the 415 hackathon of IETF104 in Prague. Thanks for valuable input and 416 suggestions go to Ralph Dolmans, Bob Harold, Daniel Salzman, Martin 417 Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron, Bob 418 Harold 420 Appendix B. Test vectors 422 B.1. Learning a new Server Cookie 424 A resolver (client) sending from IPv4 address 198.51.100.100, sends a 425 query for "example.com" to an authoritative server listening on 426 192.0.2.53 from which it has not yet learned the server cookie. 428 The DNS requests and replies shown in this Appendix, are in a "dig" 429 like format. The content of the DNS COOKIE Option is shown in 430 hexadecimal format after "; COOKIE:". 432 ;; Sending: 433 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 434 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 436 ;; OPT PSEUDOSECTION: 437 ; EDNS: version: 0, flags:; udp: 4096 438 ; COOKIE: 2464c4abcf10c957 439 ;; QUESTION SECTION: 440 ;example.com. IN A 442 ;; QUERY SIZE: 52 444 The authoritative nameserver (server) is configured with the 445 following secret: e5e973e5a6b2a43f48e7dc849e37bfcf (as hex data). 447 It receives the query at Wed Jun 5 10:53:05 UTC 2019. 449 The content of the DNS COOKIE Option that the server will return is 450 shown below in hexadecimal format after "; COOKIE:" 452 ;; Got answer: 453 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 454 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 456 ;; OPT PSEUDOSECTION: 457 ; EDNS: version: 0, flags:; udp: 4096 458 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 (good) 459 ;; QUESTION SECTION: 460 ;example.com. IN A 462 ;; ANSWER SECTION: 463 example.com. 86400 IN A 192.0.2.34 465 ;; Query time: 6 msec 466 ;; SERVER: 192.0.2.53#53(192.0.2.53) 467 ;; WHEN: Wed Jun 5 10:53:05 UTC 2019 468 ;; MSD SIZE rcvd: 84 470 B.2. The same client learning a renewed (fresh) Server Cookie 472 40 minutes later, the same resolver (client) queries the same server 473 for for "example.org" : 475 ;; Sending: 476 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 477 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 479 ;; OPT PSEUDOSECTION: 480 ; EDNS: version: 0, flags:; udp: 4096 481 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 482 ;; QUESTION SECTION: 483 ;example.org. IN A 485 ;; QUERY SIZE: 52 487 The authoritative nameserver (server) now generates a new Server 488 Cookie. The server SHOULD do this because it can see the Server 489 Cookie send by the client is older than half an hour Section 4.3, but 490 it is also fine for a server to generate a new Server Cookie sooner, 491 or even for every answer. 493 ;; Got answer: 494 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 495 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 497 ;; OPT PSEUDOSECTION: 498 ; EDNS: version: 0, flags:; udp: 4096 499 ; COOKIE: 2464c4abcf10c957010000005cf7a871d4a564a1442aca77 (good) 500 ;; QUESTION SECTION: 501 ;example.org. IN A 503 ;; ANSWER SECTION: 504 example.org. 86400 IN A 192.0.2.34 506 ;; Query time: 6 msec 507 ;; SERVER: 192.0.2.53#53(192.0.2.53) 508 ;; WHEN: Wed Jun 5 11:33:05 UTC 2019 509 ;; MSD SIZE rcvd: 84 511 B.3. Another client learning a renewed Server Cookie 513 Another resolver (client) with IPv4 address 203.0.113.203 sends a 514 request to the same server with a valid Server Cookie that it learned 515 before (at Wed Jun 5 09:46:25 UTC 2019). Note that the Server Cookie 516 has Reserved bytes set, but is still valid with the configured 517 secret; the Hash part is calculated taking along the Reserved bytes. 519 ;; Sending: 520 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 521 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 523 ;; OPT PSEUDOSECTION: 524 ; EDNS: version: 0, flags:; udp: 4096 525 ; COOKIE: fc93fc62807ddb8601abcdef5cf78f71a314227b6679ebf5 526 ;; QUESTION SECTION: 527 ;example.com. IN A 529 ;; QUERY SIZE: 52 531 The authoritative nameserver (server) replies with a freshly 532 generated Server Cookie for this client conformant with this 533 specification; so with the Reserved bits set to zero. 535 ;; Got answer: 536 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 537 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 539 ;; OPT PSEUDOSECTION: 540 ; EDNS: version: 0, flags:; udp: 4096 541 ; COOKIE: fc93fc62807ddb86010000005cf7a9acf73a7810aca2381e (good) 542 ;; QUESTION SECTION: 543 ;example.com. IN A 545 ;; ANSWER SECTION: 546 example.com. 86400 IN A 192.0.2.34 548 ;; Query time: 6 msec 549 ;; SERVER: 192.0.2.53#53(192.0.2.53) 550 ;; WHEN: Wed Jun 5 11:38:20 UTC 2019 551 ;; MSD SIZE rcvd: 84 553 B.4. IPv6 query with rolled over secret 555 The query below is from a client with IPv6 address 556 2001:db8:220:1:59de:d0f4:8769:82b8 to a server with IPv6 address 557 2001:db8:8f::53. The client has learned a valid Server Cookie before 558 when the Server had secret: dd3bdf9344b678b185a6f5cb60fca715. The 559 server now uses a new secret, but it can still validate the Server 560 Cookie provided by the client as the old secret has not expired yet. 562 ;; Sending: 563 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 564 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 566 ;; OPT PSEUDOSECTION: 567 ; EDNS: version: 0, flags:; udp: 4096 568 ; COOKIE: 22681ab97d52c298010000005cf7c57926556bd0934c72f8 569 ;; QUESTION SECTION: 570 ;example.net. IN A 572 ;; QUERY SIZE: 52 574 The authoritative nameserver (server) replies with a freshly 575 generated server cookie for this client with its new secret: 576 445536bcd2513298075a5d379663c962 578 ;; Got answer: 579 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 580 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 582 ;; OPT PSEUDOSECTION: 583 ; EDNS: version: 0, flags:; udp: 4096 584 ; COOKIE: 22681ab97d52c298010000005cf7c609a6bb79d16625507a (good) 585 ;; QUESTION SECTION: 586 ;example.net. IN A 588 ;; ANSWER SECTION: 589 example.net. 86400 IN A 192.0.2.34 591 ;; Query time: 6 msec 592 ;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53) 593 ;; WHEN: Wed Jun 5 13:36:57 UTC 2019 594 ;; MSD SIZE rcvd: 84 596 Authors' Addresses 598 Ondrej Sury 599 Internet Systems Consortium 600 CZ 602 Email: ondrej@isc.org 603 Willem Toorop 604 NLnet Labs 605 Science Park 400 606 Amsterdam 1098 XH 607 Netherlands 609 Email: willem@nlnetlabs.nl 611 Donald E. Eastlake 3rd 612 Futurewei Technologies 613 1424 Pro Shop Court 614 Davenport FL 33896 615 USA 617 Phone: +1-508-333-2270 618 Email: d3e3e3@gmail.com 620 Mark Andrews 621 Internet Systems Consortium 622 950 Charter Street 623 Redwood City CA 94063 624 USA 626 Email: marka@isc.org