idnits 2.17.1 draft-ietf-dnsop-server-cookies-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 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 18, 2019) is 1620 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 206, but not defined ** Obsolete undefined reference: RFC 4941 (Obsoleted by RFC 8981) == Missing Reference: 'DNSCOOKIE-IANA' is mentioned on line 379, 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 21, 2020 D. Eastlake 3rd 7 Futurewei Technologies 8 M. Andrews 9 Internet Systems Consortium 10 November 18, 2019 12 Interoperable Domain Name System (DNS) Server Cookies 13 draft-ietf-dnsop-server-cookies-02 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 21, 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. Security and Privacy Considerations . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 81 Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 11 82 B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 11 83 B.2. The same client learning a renewed (fresh) Server Cookie 12 84 B.3. Another client learning a renewed Server Cookie . . . . . 13 85 B.4. IPv6 query with rolled over secret . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 DNS cookies, as specified in [RFC7873], are a lightweight DNS 91 transaction security mechanism that provides limited protection to 92 DNS servers and clients against a variety of denial-of-service and 93 amplification, forgery, or cache poisoning attacks by off-path 94 attackers. This document specifies a means of producing 95 interoperable strong cookies so that an anycast server set including 96 diverse implementations can be easily configured to interoperate with 97 standard clients. 99 The threats considered for DNS Cookies and the properties of the DNS 100 Security features other than DNS Cookies are discussed in [RFC7873]. 102 In [RFC7873] in Section 6 it is "RECOMMENDED for simplicity that the 103 same Server Secret be used by each DNS server in a set of anycast 104 servers." However, how precisely a Server Cookie is calculated from 105 this Server Secret, is left to the implementation. 107 This guidance has led to a gallimaufry of DNS Cookie implementations, 108 calculating the Server Cookie in different ways. As a result, DNS 109 Cookies are impractical to deploy on multi-vendor anycast networks, 110 because even when all DNS Software share the same secret, as 111 RECOMMENDED in Section 6 of [RFC7873], the Server Cookie constructed 112 by one implementation cannot generally be validated by another. 114 There is no need for DNS client (resolver) Cookies to be 115 interoperable across different implementations. Each client need 116 only be able to recognize its own cookies. However, this document 117 does contain recommendations for constructing Client Cookies in a 118 Client protecting fashion. 120 1.1. Contents of this document 122 Section Section 2 summarises the changes to [RFC7873]. 124 In Section Section 3 suggestions for constructing a Client Cookie are 125 given. 127 In Section Section 4 instructions for constructing a Server Cookie 128 are given. 130 In Section Section 5 instructions on updating Server Secrets are 131 given. 133 In Section Section 6 the different hash functions usable for DNS 134 Cookie construction are listed. [FNV] and HMAC-SHA-256-64 [RFC6234] 135 are deprecated and [SipHash-2.4] is introduced as a REQUIRED hash 136 function for server side DNS Cookie implementations. 138 IANA considerations are in Section 7. 140 Privacy and Security Considerations in Section 8. 142 Acknowledgements are in Appendix A. 144 Test vectors are in Appendix B. 146 1.2. Definitions 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "*NOT RECOMMENDED*", "MAY", 150 and "OPTIONAL" in this document are to be interpreted as described in 151 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 o "IP Address" is used herein as a length independent term covering 155 both IPv4 and IPv6 addresses. 157 2. Changes to [RFC7873] 159 In its Appendices A.1 and B.1, [RFC7873] provides example "simple" 160 algorithms for computing Client and Server Cookies, respectively. 161 These algorithms MUST NOT be used as the resulting cookies are too 162 weak when evaluated against modern security standards. 164 In its Appendix B.2, [RFC7873] provides an example "more complex" 165 server algorithm. This algorithm is replaced by the interoperable 166 specification in Section 4 of this document, which MUST be used by 167 Server Cookie implementations. 169 This document has suggestions on Client Cookie construction in 170 Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT 171 RECOMMENDED. 173 3. Constructing a Client Cookie 175 The Client Cookie is a cryptographic nonce and should be treated as 176 such. It is RECOMMENDED to create a new Client Cookie for each new 177 upstream server a Client connects to. The Client Cookie SHOULD have 178 at least 64-bits of entropy. 180 When a Server does not support DNS Cookies, the Client MUST NOT send 181 the same Client Cookie to that same Server again. Instead, it is 182 recommended that the Client does not send a Client Cookie to that 183 Server for a certain period, like for example five minutes, before it 184 retries with a new Client Cookie. 186 When a Server does support DNS Cookies, the Client should store the 187 Client Cookie alongside the Server Cookie it registered for that 188 Server. 190 Except for when the Client IP address changes, there is no need to 191 change the Client Cookie often. It is reasonable to change the 192 Client Cookie then only if it has been compromised or after a 193 relatively long period of time such as no longer than a year. Client 194 Cookies are not expected to survive a program restart. 196 Client-Cookie = 64 bits of entropy 198 Previously, the recommended algorithm to compute the Client Cookie 199 included Client IP Address as an input to a hashing function. 200 However, when implementing the DNS Cookies, several DNS vendors found 201 impractical to include the Client IP as the Client Cookie is 202 typically computed before the Client IP address is known. Therefore, 203 the requirement to put Client IP address as input was removed. 205 However, for privacy reasons, in order to prevent tracking of devices 206 across links and to not circumvent IPv6 Privacy Extensions [RFC4941], 207 Clients MUST NOT re-use a Client or Server Cookie after the Client IP 208 address has changed. 210 One way to track Client IP addresses, is to register the Client IP 211 address alongside the Server Cookie when it receives the Server 212 Cookie. In subsequent queries to the Server with that Server Cookie, 213 the socket MAY be bound to the Client IP address that was also used 214 (and registered) when it received the Server Cookie. Failure to bind 215 MUST then result in a new Client Cookie. 217 4. Constructing a Server Cookie 219 The Server Cookie is effectively a Message Authentication Code (MAC) 220 and should be treated as such. The Server Cookie is calculated from 221 the Client Cookie, a series of Sub-Fields specified below, the Client 222 IP address, and a Server Secret known only to the servers responding 223 on the same address in an anycast set. 225 Changing the Server Secret regularly is RECOMMENDED but, when a 226 secure pseudorandom function is used, it need not be changed too 227 frequent. For example once a month would be adequate. See Section 5 228 on operator and implementation guidelines for updating a Server 229 Secret. 231 The 128-bit Server Cookie consists of Sub-Fields: a 1 octet Version 232 Sub-Field, a 3 octet Reserved Sub-Field, a 4 octet Timestamp Sub- 233 Field and an 8 octet Hash Sub-Field. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Version | Reserved | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Timestamp | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Hash | 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 4.1. The Version Sub-Field 248 The Version Sub-Field prescribes the structure and Hash calculation 249 formula. This document defines Version 1 to be the structure and way 250 to calculate the Hash Sub-Field as defined in this Section. 252 4.2. The Reserved Sub-Field 254 The value of the Reserved Sub-Field is reserved for future versions 255 of Server Side Cookie construction. On construction it SHOULD be set 256 to zero octets. On Server Cookie verification the server MUST NOT 257 enforce those fields to be zero and the Hash should be computed with 258 the received value as described in Section 4.4. 260 4.3. The Timestamp Sub-Field 262 The Timestamp value prevents Replay Attacks and MUST be checked by 263 the server to be within a defined period of time. The DNS Server 264 SHOULD allow Cookies within 1 hour period in the past and 5 minutes 265 into the future to allow operation of low volume clients and some 266 limited time skew between the DNS servers in the anycast. 268 The Timestamp value specifies a date and time in the form of a 32-bit 269 unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, 270 ignoring leap seconds, in network byte order. All comparisons 271 involving these fields MUST use "Serial number arithmetic", as 272 defined in [RFC1982] 274 The DNS Server SHOULD generate a new Server Cookie at least if the 275 received Server Cookie from the Client is more than half an hour old. 277 4.4. The Hash Sub-Field 279 It's important that all the DNS servers use the same algorithm for 280 computing the Server Cookie. This document defines the Version 1 of 281 the Server Side algorithm to be: 283 Hash = SipHash2.4( 284 Client Cookie | Version | Reserved | Timestamp | Client-IP, 285 Server Secret ) 287 where "|" indicates concatenation. 289 Notice that Client-IP is used for hash generation even though it's 290 not included in the cookie value itself. Client-IP can be either 4 291 bytes for IPv4 or 16 bytes for IPv6. 293 The Server Secret MUST be configurable to make sure that servers in 294 an anycast network return consistent results. 296 5. Updating the Server Secret 298 All servers in an anycast group must be able to verify the Server 299 Cookies constructed by all other servers in that anycast set at all 300 times. Therefore it is vital that the Server Secret is shared among 301 all servers before it us used to generate Server Cookies. 303 Also, to maximize maintaining established relationships between 304 clients and servers, an old Server Secret should be valid for 305 verification purposes for a specific period. 307 To facilitate this, deployment of a new Server Secret MUST be done in 308 three stages: 310 Stage 1 311 The new Server Secret is deployed on all the servers in an anycast 312 set by the operator. 314 Each server learns the new Server Secret, but keeps using the 315 previous Server Secret to generate Server Cookies. 317 Server Cookies constructed with the both the new Server Secret and 318 with the previous Server Secret are considered valid when 319 verifying. 321 After stage 1 completed, all the servers in the anycast set have 322 learned the new Server Secret, and can verify Server Cookies 323 constructed with it, but keep generating Server Cookies with the 324 old Server Secret. 326 Stage 2 327 This stage is initiated by the operator after the Server Cookie is 328 present on all members in the anycast set. 330 When entering Stage 2, servers start generating Server Cookies 331 with the new Server Secret. The previous Server Secret is not yet 332 removed/forgotten about. 334 Server Cookies constructed with the both the new Server Secret and 335 with the previous Server Secret are considered valid when 336 verifying. 338 Stage 3 339 This stage is initiated by the operator when it can be assumed 340 that most clients have learned the new Server Secret. 342 With this stage, the previous Server Secret can be removed and 343 MUST NOT be used anymore for verifying. 345 We RECOMMEND the operator to wait at least a period to be the 346 longest TTL in the zones served by the server plus half an hour 347 after it initiated Stage 2, before initiating Stage 3. 349 The operator SHOULD wait at least longer than the period clients 350 are allowed to use the same Server Cookie, which SHOULD be half an 351 hour, see Section 4.3. 353 6. Cookie Algorithms 355 [SipHash-2.4] is a pseudorandom function suitable as Message 356 Authentication Code. This document REQUIRES compliant DNS Server to 357 use SipHash-2.4 as a mandatory and default algorithm for DNS Cookies 358 to ensure interoperability between the DNS Implementations. 360 The construction method and pseudorandom function used in calculating 361 and verifying the Server Cookies are determined by the initial 362 version byte and by the length of the Server Cookie. Additional 363 pseudorandom or construction algorithms for Server Cookies might be 364 added in the future. 366 7. IANA Considerations 368 IANA is requested to create a registry on the "Domain Name System 369 (DNS) Parameters" IANA web page as follows: 371 Registry Name: DNS Server Cookie Methods 372 Assignment Policy: Expert Review 373 Reference: [this document], [RFC7873] 374 Note: Server Cookie method (construction and pseudorandom algorithm) 375 are determined by the Version in the first byte of the Cookie and by 376 the Cookie size. Server Cookie size is limited to the inclusive 377 range of 8 to 32 bytes. 379 Implementation recommendations for Cookie Algorithms [DNSCOOKIE- 380 IANA]: 382 +---------+-------+---------------------------------------+ 383 | Version | Size | Method | 384 +---------+-------+---------------------------------------+ 385 | 0 | 8-32 | reserved | 386 | 1 | 8-15 | unassiged | 387 | 1 | 16 | SipHash-2.4 [this document] Section 4 | 388 | 1 | 17-32 | unassigned | 389 | 2-239 | 8-32 | unassigned | 390 | 240-254 | 8-32 | private use | 391 | 255 | 8-32 | reserved | 392 +---------+-------+---------------------------------------+ 394 8. Security and Privacy Considerations 396 DNS Cookies provides limited protection to DNS servers and clients 397 against a variety of denial-of-service and amplification/forgery or 398 cache poisoning attacks by off-path attackers. They provide no 399 protection against on-path adversaries that can observe the plaintext 400 DNS traffic. An on-path adversary that can observe a Server Cookie 401 for a client and server interaction, can use that Server Cookie for 402 amplification and denial-of-service forgery attacks for the lifetime 403 of the Server Cookie. 405 In [RFC7873] it was RECOMMENDED to construct a Client Cookie by using 406 a pseudorandom function of the Client IP Address, the Server IP 407 Address, and a secret quantity known only to the client. The Client 408 IP Address was included to ensure that a client could not be tracked 409 if its IP Address changes due to privacy mechanisms or otherwise. 411 In this document, we changed Client Cookie construction to be just 64 412 bits of entropy newly created for each new upstream server the client 413 connects to. As a consequence additional care needs to be taken to 414 prevent tracking of clients. To prevent tracking, a new Client 415 Cookie for a server MUST be created whenever the Client IP Address 416 changes. 418 Unfortunately, tracking Client IP Address Changes is impractical with 419 servers that do not support DNS Cookies. To prevent tracking of 420 clients with non DNS Cookie supporting servers, a client MUST NOT 421 send a previously sent Client Cookie. To prevent the creation of a 422 new Client Cookie for each query to an non DNS Cookies supporting 423 server, it is RECOMMENDED to not send a Client Cookie to that server 424 for a certain period, like for example five minute. 426 Summarizing: 428 o In order to provide minimal authentication, a client MUST use a 429 different Client Cookie for each different Server IP Address. 431 o To prevent tracking of clients, a new Client Cookie MUST be 432 created when the Client IP Address changes. 434 o To prevent tracking of clients for a non DNS Cookie supporting 435 server, a client MUST NOT send a previously sent Client Cookie to 436 that server, unless it can track Client IP Address changes for 437 those servers too. 439 Besides the Client Cookie construction, this update on [RFC7873] does 440 not introduce any new characteristics to DNS Cookies operations and 441 the Security Considerations section of [RFC7873] still applies. 443 9. References 445 9.1. Normative References 447 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 448 DOI 10.17487/RFC1982, August 1996, 449 . 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, 453 DOI 10.17487/RFC2119, March 1997, 454 . 456 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 457 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 458 . 460 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 461 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 462 May 2017, . 464 [SipHash-2.4] 465 Aumasson, J. and D. Bernstein, "SipHash: a fast short- 466 input PRF", 2012, . 468 9.2. Informative References 470 [FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen, 471 "The FNV Non-Cryptographic Hash Algorithm", 472 . 474 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 475 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 476 DOI 10.17487/RFC6234, May 2011, 477 . 479 Appendix A. Acknowledgements 481 Thanks to Witold Krecicki and Pieter Lexis for valuable input, 482 suggestions and text and above all for implementing a prototype of an 483 interoperable DNS Cookie in Bind9, Knot and PowerDNS during the 484 hackathon of IETF104 in Prague. Thanks for valuable input and 485 suggestions go to Ralph Dolmans, Bob Harold, Daniel Salzman, Martin 486 Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron, Bob 487 Harold and Philip Homburg 489 Appendix B. Test vectors 491 B.1. Learning a new Server Cookie 493 A resolver (client) sending from IPv4 address 198.51.100.100, sends a 494 query for "example.com" to an authoritative server listening on 495 192.0.2.53 from which it has not yet learned the server cookie. 497 The DNS requests and replies shown in this Appendix, are in a "dig" 498 like format. The content of the DNS COOKIE Option is shown in 499 hexadecimal format after "; COOKIE:". 501 ;; Sending: 502 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 503 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 505 ;; OPT PSEUDOSECTION: 506 ; EDNS: version: 0, flags:; udp: 4096 507 ; COOKIE: 2464c4abcf10c957 508 ;; QUESTION SECTION: 509 ;example.com. IN A 511 ;; QUERY SIZE: 52 513 The authoritative nameserver (server) is configured with the 514 following secret: e5e973e5a6b2a43f48e7dc849e37bfcf (as hex data). 516 It receives the query at Wed Jun 5 10:53:05 UTC 2019. 518 The content of the DNS COOKIE Option that the server will return is 519 shown below in hexadecimal format after "; COOKIE:" 520 ;; Got answer: 521 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 522 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 524 ;; OPT PSEUDOSECTION: 525 ; EDNS: version: 0, flags:; udp: 4096 526 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 (good) 527 ;; QUESTION SECTION: 528 ;example.com. IN A 530 ;; ANSWER SECTION: 531 example.com. 86400 IN A 192.0.2.34 533 ;; Query time: 6 msec 534 ;; SERVER: 192.0.2.53#53(192.0.2.53) 535 ;; WHEN: Wed Jun 5 10:53:05 UTC 2019 536 ;; MSD SIZE rcvd: 84 538 B.2. The same client learning a renewed (fresh) Server Cookie 540 40 minutes later, the same resolver (client) queries the same server 541 for for "example.org" : 543 ;; Sending: 544 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 545 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 547 ;; OPT PSEUDOSECTION: 548 ; EDNS: version: 0, flags:; udp: 4096 549 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 550 ;; QUESTION SECTION: 551 ;example.org. IN A 553 ;; QUERY SIZE: 52 555 The authoritative nameserver (server) now generates a new Server 556 Cookie. The server SHOULD do this because it can see the Server 557 Cookie send by the client is older than half an hour Section 4.3, but 558 it is also fine for a server to generate a new Server Cookie sooner, 559 or even for every answer. 561 ;; Got answer: 562 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 563 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 565 ;; OPT PSEUDOSECTION: 566 ; EDNS: version: 0, flags:; udp: 4096 567 ; COOKIE: 2464c4abcf10c957010000005cf7a871d4a564a1442aca77 (good) 568 ;; QUESTION SECTION: 569 ;example.org. IN A 571 ;; ANSWER SECTION: 572 example.org. 86400 IN A 192.0.2.34 574 ;; Query time: 6 msec 575 ;; SERVER: 192.0.2.53#53(192.0.2.53) 576 ;; WHEN: Wed Jun 5 11:33:05 UTC 2019 577 ;; MSD SIZE rcvd: 84 579 B.3. Another client learning a renewed Server Cookie 581 Another resolver (client) with IPv4 address 203.0.113.203 sends a 582 request to the same server with a valid Server Cookie that it learned 583 before (at Wed Jun 5 09:46:25 UTC 2019). Note that the Server Cookie 584 has Reserved bytes set, but is still valid with the configured 585 secret; the Hash part is calculated taking along the Reserved bytes. 587 ;; Sending: 588 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 589 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 591 ;; OPT PSEUDOSECTION: 592 ; EDNS: version: 0, flags:; udp: 4096 593 ; COOKIE: fc93fc62807ddb8601abcdef5cf78f71a314227b6679ebf5 594 ;; QUESTION SECTION: 595 ;example.com. IN A 597 ;; QUERY SIZE: 52 599 The authoritative nameserver (server) replies with a freshly 600 generated Server Cookie for this client conformant with this 601 specification; so with the Reserved bits set to zero. 603 ;; Got answer: 604 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 605 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 607 ;; OPT PSEUDOSECTION: 608 ; EDNS: version: 0, flags:; udp: 4096 609 ; COOKIE: fc93fc62807ddb86010000005cf7a9acf73a7810aca2381e (good) 610 ;; QUESTION SECTION: 611 ;example.com. IN A 613 ;; ANSWER SECTION: 614 example.com. 86400 IN A 192.0.2.34 616 ;; Query time: 6 msec 617 ;; SERVER: 192.0.2.53#53(192.0.2.53) 618 ;; WHEN: Wed Jun 5 11:38:20 UTC 2019 619 ;; MSD SIZE rcvd: 84 621 B.4. IPv6 query with rolled over secret 623 The query below is from a client with IPv6 address 624 2001:db8:220:1:59de:d0f4:8769:82b8 to a server with IPv6 address 625 2001:db8:8f::53. The client has learned a valid Server Cookie before 626 when the Server had secret: dd3bdf9344b678b185a6f5cb60fca715. The 627 server now uses a new secret, but it can still validate the Server 628 Cookie provided by the client as the old secret has not expired yet. 630 ;; Sending: 631 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 632 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 634 ;; OPT PSEUDOSECTION: 635 ; EDNS: version: 0, flags:; udp: 4096 636 ; COOKIE: 22681ab97d52c298010000005cf7c57926556bd0934c72f8 637 ;; QUESTION SECTION: 638 ;example.net. IN A 640 ;; QUERY SIZE: 52 642 The authoritative nameserver (server) replies with a freshly 643 generated server cookie for this client with its new secret: 644 445536bcd2513298075a5d379663c962 645 ;; Got answer: 646 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 647 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 649 ;; OPT PSEUDOSECTION: 650 ; EDNS: version: 0, flags:; udp: 4096 651 ; COOKIE: 22681ab97d52c298010000005cf7c609a6bb79d16625507a (good) 652 ;; QUESTION SECTION: 653 ;example.net. IN A 655 ;; ANSWER SECTION: 656 example.net. 86400 IN A 192.0.2.34 658 ;; Query time: 6 msec 659 ;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53) 660 ;; WHEN: Wed Jun 5 13:36:57 UTC 2019 661 ;; MSD SIZE rcvd: 84 663 Authors' Addresses 665 Ondrej Sury 666 Internet Systems Consortium 667 CZ 669 Email: ondrej@isc.org 671 Willem Toorop 672 NLnet Labs 673 Science Park 400 674 Amsterdam 1098 XH 675 Netherlands 677 Email: willem@nlnetlabs.nl 679 Donald E. Eastlake 3rd 680 Futurewei Technologies 681 1424 Pro Shop Court 682 Davenport FL 33896 683 USA 685 Phone: +1-508-333-2270 686 Email: d3e3e3@gmail.com 687 Mark Andrews 688 Internet Systems Consortium 689 950 Charter Street 690 Redwood City CA 94063 691 USA 693 Email: marka@isc.org