idnits 2.17.00 (12 Aug 2021) /tmp/idnits25384/draft-ietf-dnsop-server-cookies-01.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 (November 4, 2019) is 928 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: 'RFC4941' is mentioned on line 198, but not defined ** Obsolete undefined reference: RFC 4941 (Obsoleted by RFC 8981) == Missing Reference: 'DNSCOOKIE-IANA' is mentioned on line 372, but not defined Summary: 3 errors (**), 0 flaws (~~), 4 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: May 7, 2020 D. Eastlake 3rd 7 Futurewei Technologies 8 M. Andrews 9 Internet Systems Consortium 10 November 4, 2019 12 Interoperable Domain Name System (DNS) Server Cookies 13 draft-ietf-dnsop-server-cookies-01 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 May 7, 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 . . . . . . . . . . . . . . . . . . 6 70 4.2. The Reserved Sub-Field . . . . . . . . . . . . . . . . . 6 71 4.3. The Timestamp Sub-Field . . . . . . . . . . . . . . . . . 6 72 4.4. The Hash Sub-Field . . . . . . . . . . . . . . . . . . . 6 73 5. Updating the Server Secret . . . . . . . . . . . . . . . . . 7 74 6. Cookie Algorithms . . . . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 80 Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 10 81 B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 10 82 B.2. The same client learning a renewed (fresh) Server Cookie 11 83 B.3. Another client learning a renewed Server Cookie . . . . . 12 84 B.4. IPv6 query with rolled over secret . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 cryptographic nonce and should be treated as 173 such. For simplicity, it can be calculated from Server IP Address, 174 and a Client Secret known only to the Client that is changed whenever 175 an IP address previously used by the Client is no longer available. 176 The Client Cookie SHOULD have at least 64-bits of entropy. 178 Except for when the Client IP address changes, there is no need to 179 change the Client Secret often if a secure pseudorandom function 180 (like [SipHash-2.4]) is used. It is reasonable to change the Client 181 secret then only if it has been compromised or after a relatively 182 long period of time such as no longer than a year. 184 It is RECOMMENDED but not required that the following pseudorandom 185 function be used to construct the Client Cookie: 187 Client-Cookie = MAC_Algorithm( 188 Server IP Address, Client Secret ) 190 Previously, the recommended algorithm to compute the Client Cookie 191 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 was removed. 197 However, for privacy reasons, in order to prevent tracking of devices 198 across links and to not circumvent IPv6 Privacy Extensions [RFC4941], 199 Clients MUST NOT re-use a Client or Server Cookie after the Client IP 200 address has changed. 202 The Client IP address is available on the UDP socket when it receives 203 the Server Cookie and should be registered alongside the Server 204 Cookie. In subsequent queries to the Server with that Server Cookie, 205 the socket MUST be bound to the Client IP address that was also used 206 (and registered) when it received the Server Cookie. Failure to bind 207 must result in a new Client Cookie, which, for the method described 208 in this section means a new Client Secret. 210 4. Constructing a Server Cookie 212 The Server Cookie is effectively a Message Authentication Code (MAC) 213 and should be treated as such. The Server Cookie is calculated from 214 the Client Cookie, a series of Sub-Fields specified below, the Client 215 IP address, and a Server Secret known only to the servers responding 216 on the same address in an anycast set. 218 Changing the Server Secret regularly is RECOMMENDED but, when a 219 secure pseudorandom function is used, it need not be changed too 220 frequent. For example once a month would be adequate. See Section 5 221 on operator and implementation guidelines for updating a Server 222 Secret. 224 The 128-bit Server Cookie consists of Sub-Fields: a 1 octet Version 225 Sub-Field, a 3 octet Reserved Sub-Field, a 4 octet Timestamp Sub- 226 Field and an 8 octet Hash Sub-Field. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Version | Reserved | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Timestamp | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Hash | 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 4.1. The Version Sub-Field 241 The Version Sub-Field prescribes the structure and Hash calculation 242 formula. This document defines Version 1 to be the structure and way 243 to calculate the Hash Sub-Field as defined in this Section. 245 4.2. The Reserved Sub-Field 247 The value of the Reserved Sub-Field is reserved for future versions 248 of Server Side Cookie construction. On construction it SHOULD be set 249 to zero octets. On Server Cookie verification the server MUST NOT 250 enforce those fields to be zero and the Hash should be computed with 251 the received value as described in Section 4.4. 253 4.3. The Timestamp Sub-Field 255 The Timestamp value prevents Replay Attacks and MUST be checked by 256 the server to be within a defined period of time. The DNS Server 257 SHOULD allow Cookies within 1 hour period in the past and 5 minutes 258 into the future to allow operation of low volume clients and some 259 limited time skew between the DNS servers in the anycast. 261 The Timestamp value specifies a date and time in the form of a 32-bit 262 unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, 263 ignoring leap seconds, in network byte order. All comparisons 264 involving these fields MUST use "Serial number arithmetic", as 265 defined in [RFC1982] 267 The DNS Server SHOULD generate a new Server Cookie at least if the 268 received Server Cookie from the Client is more than half an hour old. 270 4.4. The Hash Sub-Field 272 It's important that all the DNS servers use the same algorithm for 273 computing the Server Cookie. This document defines the Version 1 of 274 the Server Side algorithm to be: 276 Hash = SipHash2.4( 277 Client Cookie | Version | Reserved | Timestamp | Client-IP, 278 Server Secret ) 280 where "|" indicates concatenation. 282 Notice that Client-IP is used for hash generation even though it's 283 not included in the cookie value itself. Client-IP can be either 4 284 bytes for IPv4 or 16 bytes for IPv6. 286 The Server Secret MUST be configurable to make sure that servers in 287 an anycast network return consistent results. 289 5. Updating the Server Secret 291 All servers in an anycast group must be able to verify the Server 292 Cookies constructed by all other servers in that anycast set at all 293 times. Therefore it is vital that the Server Secret is shared among 294 all servers before it us used to generate Server Cookies. 296 Also, to maximize maintaining established relationships between 297 clients and servers, an old Server Secret should be valid for 298 verification purposes for a specific period. 300 To facilitate this, deployment of a new Server Secret MUST be done in 301 three stages: 303 Stage 1 304 The new Server Secret is deployed on all the servers in an anycast 305 set by the operator. 307 Each server learns the new Server Secret, but keeps using the 308 previous Server Secret to generate Server Cookies. 310 Server Cookies constructed with the both the new Server Secret and 311 with the previous Server Secret are considered valid when 312 verifying. 314 After stage 1 completed, all the servers in the anycast set have 315 learned the new Server Secret, and can verify Server Cookies 316 constructed with it, but keep generating Server Cookies with the 317 old Server Secret. 319 Stage 2 320 This stage is initiated by the operator after the Server Cookie is 321 present on all members in the anycast set. 323 When entering Stage 2, servers start generating Server Cookies 324 with the new Server Secret. The previous Server Secret is not yet 325 removed/forgotten about. 327 Server Cookies constructed with the both the new Server Secret and 328 with the previous Server Secret are considered valid when 329 verifying. 331 Stage 3 332 This stage is initiated by the operator when it can be assumed 333 that most clients have learned the new Server Secret. 335 With this stage, the previous Server Secret can be removed and 336 MUST NOT be used anymore for verifying. 338 We RECOMMEND the operator to wait at least a period to be the 339 longest TTL in the zones served by the server plus half an hour 340 after it initiated Stage 2, before initiating Stage 3. 342 The operator SHOULD wait at least longer than the period clients 343 are allowed to use the same Server Cookie, which SHOULD be half an 344 hour, see Section 4.3. 346 6. Cookie Algorithms 348 [SipHash-2.4] is a pseudorandom function suitable as Message 349 Authentication Code. This document REQUIRES compliant DNS Server to 350 use SipHash-2.4 as a mandatory and default algorithm for DNS Cookies 351 to ensure interoperability between the DNS Implementations. 353 The construction method and pseudorandom function used in calculating 354 and verifying the Server Cookies are determined by the initial 355 version byte and by the length of the Server Cookie. Additional 356 pseudorandom or construction algorithms for Server Cookies might be 357 added in the future. 359 7. IANA Considerations 361 IANA is requested to create a registry on the "Domain Name System 362 (DNS) Parameters" IANA web page as follows: 364 Registry Name: DNS Server Cookie Methods 365 Assignment Policy: Expert Review 366 Reference: [this document], [RFC7873] 367 Note: Server Cookie method (construction and pseudorandom algorithm) 368 are determined by the Version in the first byte of the Cookie and by 369 the Cookie size. Server Cookie size is limited to the inclusive 370 range of 8 to 32 bytes. 372 Implementation recommendations for Cookie Algorithms [DNSCOOKIE- 373 IANA]: 375 +---------+-------+---------------------------------------+ 376 | Version | Size | Method | 377 +---------+-------+---------------------------------------+ 378 | 0 | 8-32 | reserved | 379 | 1 | 8-15 | unassiged | 380 | 1 | 16 | SipHash-2.4 [this document] Section 4 | 381 | 1 | 17-32 | unassigned | 382 | 2-239 | 8-32 | unassigned | 383 | 240-254 | 8-32 | private use | 384 | 255 | 8-32 | reserved | 385 +---------+-------+---------------------------------------+ 387 8. References 389 8.1. Normative References 391 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 392 DOI 10.17487/RFC1982, August 1996, 393 . 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, 397 DOI 10.17487/RFC2119, March 1997, 398 . 400 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 401 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 402 . 404 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 405 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 406 May 2017, . 408 [SipHash-2.4] 409 Aumasson, J. and D. Bernstein, "SipHash: a fast short- 410 input PRF", 2012, . 412 8.2. Informative References 414 [FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen, 415 "The FNV Non-Cryptographic Hash Algorithm", 416 . 418 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 419 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 420 DOI 10.17487/RFC6234, May 2011, 421 . 423 Appendix A. Acknowledgements 425 Thanks to Witold Krecicki and Pieter Lexis for valuable input, 426 suggestions and text and above all for implementing a prototype of an 427 interoperable DNS Cookie in Bind9, Knot and PowerDNS during the 428 hackathon of IETF104 in Prague. Thanks for valuable input and 429 suggestions go to Ralph Dolmans, Bob Harold, Daniel Salzman, Martin 430 Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron, Bob 431 Harold and Philip Homburg 433 Appendix B. Test vectors 435 B.1. Learning a new Server Cookie 437 A resolver (client) sending from IPv4 address 198.51.100.100, sends a 438 query for "example.com" to an authoritative server listening on 439 192.0.2.53 from which it has not yet learned the server cookie. 441 The DNS requests and replies shown in this Appendix, are in a "dig" 442 like format. The content of the DNS COOKIE Option is shown in 443 hexadecimal format after "; COOKIE:". 445 ;; Sending: 446 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 447 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 449 ;; OPT PSEUDOSECTION: 450 ; EDNS: version: 0, flags:; udp: 4096 451 ; COOKIE: 2464c4abcf10c957 452 ;; QUESTION SECTION: 453 ;example.com. IN A 455 ;; QUERY SIZE: 52 457 The authoritative nameserver (server) is configured with the 458 following secret: e5e973e5a6b2a43f48e7dc849e37bfcf (as hex data). 460 It receives the query at Wed Jun 5 10:53:05 UTC 2019. 462 The content of the DNS COOKIE Option that the server will return is 463 shown below in hexadecimal format after "; COOKIE:" 464 ;; Got answer: 465 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 466 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 468 ;; OPT PSEUDOSECTION: 469 ; EDNS: version: 0, flags:; udp: 4096 470 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 (good) 471 ;; QUESTION SECTION: 472 ;example.com. IN A 474 ;; ANSWER SECTION: 475 example.com. 86400 IN A 192.0.2.34 477 ;; Query time: 6 msec 478 ;; SERVER: 192.0.2.53#53(192.0.2.53) 479 ;; WHEN: Wed Jun 5 10:53:05 UTC 2019 480 ;; MSD SIZE rcvd: 84 482 B.2. The same client learning a renewed (fresh) Server Cookie 484 40 minutes later, the same resolver (client) queries the same server 485 for for "example.org" : 487 ;; Sending: 488 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 489 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 491 ;; OPT PSEUDOSECTION: 492 ; EDNS: version: 0, flags:; udp: 4096 493 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 494 ;; QUESTION SECTION: 495 ;example.org. IN A 497 ;; QUERY SIZE: 52 499 The authoritative nameserver (server) now generates a new Server 500 Cookie. The server SHOULD do this because it can see the Server 501 Cookie send by the client is older than half an hour Section 4.3, but 502 it is also fine for a server to generate a new Server Cookie sooner, 503 or even for every answer. 505 ;; Got answer: 506 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 507 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 509 ;; OPT PSEUDOSECTION: 510 ; EDNS: version: 0, flags:; udp: 4096 511 ; COOKIE: 2464c4abcf10c957010000005cf7a871d4a564a1442aca77 (good) 512 ;; QUESTION SECTION: 513 ;example.org. IN A 515 ;; ANSWER SECTION: 516 example.org. 86400 IN A 192.0.2.34 518 ;; Query time: 6 msec 519 ;; SERVER: 192.0.2.53#53(192.0.2.53) 520 ;; WHEN: Wed Jun 5 11:33:05 UTC 2019 521 ;; MSD SIZE rcvd: 84 523 B.3. Another client learning a renewed Server Cookie 525 Another resolver (client) with IPv4 address 203.0.113.203 sends a 526 request to the same server with a valid Server Cookie that it learned 527 before (at Wed Jun 5 09:46:25 UTC 2019). Note that the Server Cookie 528 has Reserved bytes set, but is still valid with the configured 529 secret; the Hash part is calculated taking along the Reserved bytes. 531 ;; Sending: 532 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 533 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 535 ;; OPT PSEUDOSECTION: 536 ; EDNS: version: 0, flags:; udp: 4096 537 ; COOKIE: fc93fc62807ddb8601abcdef5cf78f71a314227b6679ebf5 538 ;; QUESTION SECTION: 539 ;example.com. IN A 541 ;; QUERY SIZE: 52 543 The authoritative nameserver (server) replies with a freshly 544 generated Server Cookie for this client conformant with this 545 specification; so with the Reserved bits set to zero. 547 ;; Got answer: 548 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 549 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 551 ;; OPT PSEUDOSECTION: 552 ; EDNS: version: 0, flags:; udp: 4096 553 ; COOKIE: fc93fc62807ddb86010000005cf7a9acf73a7810aca2381e (good) 554 ;; QUESTION SECTION: 555 ;example.com. IN A 557 ;; ANSWER SECTION: 558 example.com. 86400 IN A 192.0.2.34 560 ;; Query time: 6 msec 561 ;; SERVER: 192.0.2.53#53(192.0.2.53) 562 ;; WHEN: Wed Jun 5 11:38:20 UTC 2019 563 ;; MSD SIZE rcvd: 84 565 B.4. IPv6 query with rolled over secret 567 The query below is from a client with IPv6 address 568 2001:db8:220:1:59de:d0f4:8769:82b8 to a server with IPv6 address 569 2001:db8:8f::53. The client has learned a valid Server Cookie before 570 when the Server had secret: dd3bdf9344b678b185a6f5cb60fca715. The 571 server now uses a new secret, but it can still validate the Server 572 Cookie provided by the client as the old secret has not expired yet. 574 ;; Sending: 575 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 576 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 578 ;; OPT PSEUDOSECTION: 579 ; EDNS: version: 0, flags:; udp: 4096 580 ; COOKIE: 22681ab97d52c298010000005cf7c57926556bd0934c72f8 581 ;; QUESTION SECTION: 582 ;example.net. IN A 584 ;; QUERY SIZE: 52 586 The authoritative nameserver (server) replies with a freshly 587 generated server cookie for this client with its new secret: 588 445536bcd2513298075a5d379663c962 589 ;; Got answer: 590 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 591 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 593 ;; OPT PSEUDOSECTION: 594 ; EDNS: version: 0, flags:; udp: 4096 595 ; COOKIE: 22681ab97d52c298010000005cf7c609a6bb79d16625507a (good) 596 ;; QUESTION SECTION: 597 ;example.net. IN A 599 ;; ANSWER SECTION: 600 example.net. 86400 IN A 192.0.2.34 602 ;; Query time: 6 msec 603 ;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53) 604 ;; WHEN: Wed Jun 5 13:36:57 UTC 2019 605 ;; MSD SIZE rcvd: 84 607 Authors' Addresses 609 Ondrej Sury 610 Internet Systems Consortium 611 CZ 613 Email: ondrej@isc.org 615 Willem Toorop 616 NLnet Labs 617 Science Park 400 618 Amsterdam 1098 XH 619 Netherlands 621 Email: willem@nlnetlabs.nl 623 Donald E. Eastlake 3rd 624 Futurewei Technologies 625 1424 Pro Shop Court 626 Davenport FL 33896 627 USA 629 Phone: +1-508-333-2270 630 Email: d3e3e3@gmail.com 631 Mark Andrews 632 Internet Systems Consortium 633 950 Charter Street 634 Redwood City CA 94063 635 USA 637 Email: marka@isc.org