5Internet Engineering Task Force (IETF) O. Sury
6Request for Comments: 9018 Internet Systems Consortium
8Category: Standards Track NLnet Labs
9ISSN: 2070-1721 D. Eastlake 3rd
10 Futurewei Technologies
12 Internet Systems Consortium
16 Interoperable Domain Name System (DNS) Server Cookies
20 DNS Cookies, as specified in RFC 7873, are a lightweight DNS
21 transaction security mechanism that provide limited protection to DNS
22 servers and clients against a variety of denial-of-service
23 amplification, forgery, or cache-poisoning attacks by off-path
26 This document updates RFC 7873 with precise directions for creating
27 Server Cookies so that an anycast server set including diverse
28 implementations will interoperate with standard clients, with
29 suggestions for constructing Client Cookies in a privacy-preserving
30 fashion, and with suggestions on how to update a Server Secret. An
31 IANA registry listing the methods and associated pseudorandom
32 function suitable for creating DNS Server Cookies has been created
33 with the method described in this document as the first and, as of
34 the time of publication, only entry.
38 This is an Internet Standards Track document.
40 This document is a product of the Internet Engineering Task Force
41 (IETF). It represents the consensus of the IETF community. It has
42 received public review and has been approved for publication by the
43 Internet Engineering Steering Group (IESG). Further information on
44 Internet Standards is available in Section 2 of RFC 7841.
46 Information about the current status of this document, any errata,
47 and how to provide feedback on it may be obtained at
48 https://www.rfc-editor.org/info/rfc9018.
52 Copyright (c) 2021 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (https://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
68 1.1. Terminology and Definitions
69 2. Changes to RFC 7873
70 3. Constructing a Client Cookie
71 4. Constructing a Server Cookie
72 4.1. The Version Sub-Field
73 4.2. The Reserved Sub-Field
74 4.3. The Timestamp Sub-Field
75 4.4. The Hash Sub-Field
76 5. Updating the Server Secret
78 7. IANA Considerations
79 8. Security and Privacy Considerations
80 8.1. Client Cookie Construction
81 8.2. Server Cookie Construction
83 9.1. Normative References
84 9.2. Informative References
85 Appendix A. Test Vectors
86 A.1. Learning a New Server Cookie
87 A.2. The Same Client Learning a Renewed (Fresh) Server Cookie
88 A.3. Another Client Learning a Renewed Server Cookie
89 A.4. IPv6 Query with Rolled Over Secret
90 Appendix B. Implementation Status
96 DNS Cookies, as specified in [RFC7873], are a lightweight DNS
97 transaction security mechanism that provide limited protection to DNS
98 servers and clients against a variety of denial-of-service
99 amplification, forgery, or cache-poisoning attacks by off-path
100 attackers. This document specifies a means of producing
101 interoperable cookies so that an anycast server set including diverse
102 implementations can be easily configured to interoperate with
103 standard clients. Also, single-implementation or non-anycast
104 services can benefit from a well-studied standardized algorithm for
105 which the behavioral and security characteristics are more widely
108 The threats considered for DNS Cookies and the properties of the DNS
109 Security features other than DNS Cookies are discussed in [RFC7873].
111 In Section 6 of [RFC7873], for simplicity, it is "RECOMMENDED that
112 the same Server Secret be used by each DNS server in a set of anycast
113 servers." However, how precisely a Server Cookie is calculated from
114 this Server Secret is left to the implementation.
116 This guidance has led to a gallimaufry of DNS Cookie implementations,
117 calculating the Server Cookie in different ways. As a result, DNS
118 Cookies are impractical to deploy on multi-vendor anycast networks
119 because even when all DNS Software shares the same secret, as
120 RECOMMENDED in Section 6 of [RFC7873], the Server Cookie constructed
121 by one implementation cannot generally be validated by another.
123 There is no need for DNS client (resolver) Cookies to be
124 interoperable across different implementations. Each client need
125 only be able to recognize its own cookies. However, this document
126 does contain recommendations for constructing Client Cookies in a
127 client-protecting fashion.
1291.1. Terminology and Definitions
131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
133 "OPTIONAL" in this document are to be interpreted as described in
134 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
135 capitals, as shown here.
137 Note: "IP address" is used herein as a length-independent term
138 covering both IPv4 and IPv6 addresses.
1402. Changes to RFC 7873
142 Appendices A.1 and B.1 of [RFC7873] provide example "simple"
143 algorithms for computing Client and Server Cookies, respectively.
144 These algorithms MUST NOT be used as the resulting cookies are too
145 weak when evaluated against modern security standards.
147 Appendix B.2 of [RFC7873] provides an example "more complex" server
148 algorithm. This algorithm is replaced by the interoperable
149 specification in Section 4 of this document, which MUST be used by
150 Server Cookie implementations.
152 This document has suggestions on Client Cookie construction in
153 Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT
1563. Constructing a Client Cookie
158 The Client Cookie acts as an identifier for a given client and its IP
159 address and needs to be unguessable. In order to provide minimal
160 authentication of the targeted server, a client MUST use a different
161 Client Cookie for each different Server IP address. This complicates
162 a server's ability to spoof answers for other DNS servers. The
163 Client Cookie SHOULD have 64 bits of entropy.
165 When a server does not support DNS Cookies, the client MUST NOT send
166 the same Client Cookie to that same server again. Instead, it is
167 recommended that the client does not send a Client Cookie to that
168 server for a certain period (for example, five minutes) before it
169 retries with a new Client Cookie.
171 When a server does support DNS Cookies, the client should store the
172 Client Cookie alongside the Server Cookie it registered for that
175 Except for when the Client IP address changes, there is no need to
176 change the Client Cookie often. It is then reasonable to change the
177 Client Cookie only if it has been compromised or after a relatively
178 long implementation-defined period of time. The time period should
179 be no longer than a year, and in any case, Client Cookies are not
180 expected to survive a program restart.
182 Client-Cookie = 64 bits of entropy
184 Previously, the recommended algorithm to compute the Client Cookie
185 included the Client IP address as an input to a hashing function.
186 However, when implementing the DNS Cookies, several DNS vendors found
187 it impractical to include the Client IP as the Client Cookie is
188 typically computed before the Client IP address is known. Therefore,
189 the requirement to put the Client IP address as input was removed.
191 However, for privacy reasons, in order to prevent tracking of devices
192 across links and to not circumvent IPv6 Privacy Extensions [RFC8981],
193 clients MUST NOT reuse a Client or Server Cookie after the Client IP
196 One way to satisfy this requirement for non-reuse is to register the
197 Client IP address alongside the Server Cookie when it receives the
198 Server Cookie. In subsequent queries to the server with that Server
199 Cookie, the socket MUST be bound to the Client IP address that was
200 also used (and registered) when it received the Server Cookie.
201 Failure to bind MUST then result in a new Client Cookie.
2034. Constructing a Server Cookie
205 The Server Cookie is effectively a Message Authentication Code (MAC).
206 The Server Cookie, when it occurs in a COOKIE option in a request, is
207 intended to weakly assure the server that the request came from a
208 client that is both at the source IP address of the request and using
209 the Client Cookie included in the option. This assurance is provided
210 by the Server Cookie that the server (or any other server from the
211 anycast set) sent to that client in an earlier response and that
212 appears as the Server Cookie field in the weakly authenticated
213 request (see Section 5.2 of [RFC7873]).
215 DNS Cookies do not provide protection against "on-path" adversaries
216 (see Section 9 of [RFC7873]). An on-path observer that has seen a
217 Server Cookie for a client can abuse that Server Cookie to spoof
218 request for that client within the time span a Server Cookie is valid
221 The Server Cookie is calculated from the Client Cookie, a series of
222 Sub-Fields specified below, the Client IP address, and a Server
223 Secret that is known only to the server or only to the set of servers
224 at the same anycast address.
226 For calculation of the Server Cookie, a pseudorandom function is
227 RECOMMENDED with the property that an attacker that does not know the
228 Server Secret, cannot find (any information about) the Server Secret,
229 and cannot create a Server Cookie for any combination of the Client
230 Cookie, the series of Sub-Fields specified below, and the client IP
231 address, for which it has not seen a Server Cookie before. Because
232 DNS servers need to use the pseudorandom function in order to verify
233 Server Cookies, it is RECOMMENDED that it be efficient to calculate.
234 The pseudorandom function described in [SipHash-2-4] and introduced
235 in Section 4.4 of this document fits these recommendations.
237 Changing the Server Secret regularly is RECOMMENDED but, when a
238 secure pseudorandom function is used, it need not be changed too
239 frequently. Once a month, for example, would be adequate. See
240 Section 5 on operator and implementation guidelines for updating a
243 The 128-bit Server Cookie consists of the following Sub-Fields: a
244 1-octet Version Sub-Field, a 3-octet Reserved Sub-Field, a 4-octet
245 Timestamp Sub-Field, and an 8-octet Hash Sub-Field.
248 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
249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
250 | Version | Reserved |
251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2584.1. The Version Sub-Field
260 The Version Sub-Field prescribes the structure and Hash calculation
261 formula. This document defines Version 1 to be the structure and way
262 to calculate the Hash Sub-Field as defined in this section.
2644.2. The Reserved Sub-Field
266 The value of the Reserved Sub-Field is reserved for future versions
267 of server-side cookie construction. On construction, it MUST be set
268 to zero octets. On Server Cookie verification, the server MUST NOT
269 enforce those fields to be zero, and the Hash should be computed with
270 the received value as described in Section 4.4.
2724.3. The Timestamp Sub-Field
274 The Timestamp value prevents Replay Attacks and MUST be checked by
275 the server to be within a defined period of time. The DNS server
276 SHOULD allow cookies within a 1-hour period in the past and a
277 5-minute period into the future to allow operation of low-volume
278 clients and some limited time skew between the DNS servers in the
281 The Timestamp value specifies a date and time in the form of a 32-bit
282 *unsigned* number of seconds elapsed since 1 January 1970 00:00:00
283 UTC, ignoring leap seconds, in network byte order. All comparisons
284 involving these fields MUST use "Serial number arithmetic", as
285 defined in [RFC1982]. [RFC1982] specifies how the differences should
286 be handled. This handles any relative time window less than 68
287 years, at any time in the future (2038, 2106, 2256, 22209, or later.)
289 The DNS server SHOULD generate a new Server Cookie at least if the
290 received Server Cookie from the client is more than half an hour old,
291 but it MAY generate a new cookie more often than that.
2934.4. The Hash Sub-Field
295 It's important that all the DNS servers use the same algorithm for
296 computing the Server Cookie. This document defines the Version 1 of
297 the server-side algorithm to be:
300 Client Cookie | Version | Reserved | Timestamp | Client-IP,
303 where "|" indicates concatenation.
305 Notice that Client-IP is used for hash generation even though it is
306 not included in the cookie value itself. Client-IP can be either 4
307 bytes for IPv4 or 16 bytes for IPv6. The length of all the
308 concatenated elements (the input into [SipHash-2-4]) MUST be either
309 precisely 20 bytes in case of an IPv4 Client-IP or precisely 32 bytes
310 in case of an IPv6 Client-IP.
312 When a DNS server receives a Server Cookie version 1 for validation,
313 the length of the received COOKIE option MUST be precisely 24 bytes:
314 8 bytes for the Client Cookie plus 16 bytes for the Server Cookie.
315 Verification of the length of the received COOKIE option is REQUIRED
316 to guarantee the length of the input into [SipHash-2-4] to be
317 precisely 20 bytes in the case of an IPv4 Client-IP and precisely 32
318 bytes in the case of an IPv6 Client-IP. This ensures that the input
319 into [SipHash-2-4] is an injective function of the elements making up
320 the input, and thereby prevents data substitution attacks. More
321 specifically, this prevents a 36-byte COOKIE option coming from an
322 IPv4 Client-IP to be validated as if it were coming from an IPv6
325 The Server Secret MUST be configurable to make sure that servers in
326 an anycast network return consistent results.
3285. Updating the Server Secret
330 Changing the Server Secret regularly is RECOMMENDED. All servers in
331 an anycast set must be able to verify the Server Cookies constructed
332 by all other servers in that anycast set at all times. Therefore, it
333 is vital that the Server Secret is shared among all servers before it
334 is used to generate Server Cookies on any server.
336 Also, to maximize maintaining established relationships between
337 clients and servers, an old Server Secret should be valid for
338 verification purposes for a specific period.
340 To facilitate this, deployment of a new Server Secret MUST be done in
344 The new Server Secret is deployed on all the servers in an anycast
347 Each server learns the new Server Secret but keeps using the
348 previous Server Secret to generate Server Cookies.
350 Server Cookies constructed with both the new Server Secret and the
351 previous Server Secret are considered valid when verifying.
353 After stage 1 is completed, all the servers in the anycast set
354 have learned the new Server Secret and can verify Server Cookies
355 constructed with it, but keep generating Server Cookies with the
359 This stage is initiated by the operator after the Server Cookie is
360 present on all members in the anycast set.
362 When entering Stage 2, servers start generating Server Cookies
363 with the new Server Secret. The previous Server Secret is not yet
366 Server Cookies constructed with both the new Server Secret and the
367 previous Server Secret are considered valid when verifying.
370 This stage is initiated by the operator when it can be assumed
371 that most clients have obtained a Server Cookie derived from the
374 With this stage, the previous Server Secret can be removed and
375 MUST NOT be used anymore for verifying.
377 It is RECOMMENDED that the operator wait, after initiating Stage 2
378 and before initiating Stage 3, at least a period of time equal to
379 the longest TTL in the zones served by the server plus 1 hour.
381 The operator SHOULD wait at least longer than the period clients
382 are allowed to use the same Server Cookie, which SHOULD be 1 hour
387 [SipHash-2-4] is a pseudorandom function suitable as a Message
388 Authentication Code. It is REQUIRED that a compliant DNS server use
389 SipHash-2-4 as a mandatory and default algorithm for DNS Cookies to
390 ensure interoperability between the DNS Implementations.
392 The construction method and pseudorandom function used in calculating
393 and verifying the Server Cookies are determined by the initial
394 version byte and by the length of the Server Cookie. Additional
395 pseudorandom or construction algorithms for Server Cookies might be
3987. IANA Considerations
400 IANA has created a registry under the "Domain Name System (DNS)
401 Parameters" heading as follows:
403 Registry Name: DNS Server Cookie Methods
405 Assignment Policy: Expert Review
407 Reference: [RFC9018], [RFC7873]
409 Note: A Server Cookie method (construction and pseudorandom
410 algorithm) is determined by the Version in the first byte of the
411 cookie and by the cookie size. Server Cookie size is limited to
412 the inclusive range of 8 to 32 bytes.
414 +=========+=======+=================================+
415 | Version | Size | Method |
416 +=========+=======+=================================+
417 | 0 | 8-32 | Reserved |
418 +---------+-------+---------------------------------+
419 | 1 | 8-15 | Unassigned |
420 +---------+-------+---------------------------------+
421 | 1 | 16 | SipHash-2-4 [RFC9018] Section 4 |
422 +---------+-------+---------------------------------+
423 | 1 | 17-32 | Unassigned |
424 +---------+-------+---------------------------------+
425 | 2-239 | 8-32 | Unassigned |
426 +---------+-------+---------------------------------+
427 | 240-254 | 8-32 | Reserved for Private Use |
428 +---------+-------+---------------------------------+
429 | 255 | 8-32 | Reserved |
430 +---------+-------+---------------------------------+
432 Table 1: DNS Server Cookie Methods
4348. Security and Privacy Considerations
436 DNS Cookies provide limited protection to DNS servers and clients
437 against a variety of denial-of-service amplification, forgery, or
438 cache-poisoning attacks by off-path attackers. They provide no
439 protection against on-path adversaries that can observe the plaintext
440 DNS traffic. An on-path adversary that can observe a Server Cookie
441 for a client and server interaction can use that Server Cookie for
442 denial-of-service amplification, forgery, or cache-poisoning attacks
443 directed at that client for the lifetime of the Server Cookie.
4458.1. Client Cookie Construction
447 In [RFC7873], it was RECOMMENDED to construct a Client Cookie by
448 using a pseudorandom function of the Client IP address, the Server IP
449 address, and a secret quantity known only to the client. The Client
450 IP address was included to ensure that a client could not be tracked
451 if its IP address changes due to privacy mechanisms or otherwise.
453 In this document, we changed Client Cookie construction to be just 64
454 bits of entropy newly created for each new upstream server the client
455 connects to. As a consequence, additional care needs to be taken to
456 prevent tracking of clients. To prevent tracking, a new Client
457 Cookie for a server MUST be created whenever the Client IP address
460 Unfortunately, tracking Client IP address changes is impractical with
461 servers that do not support DNS Cookies. To prevent tracking of
462 clients with non-DNS Cookie-supporting servers, a client MUST NOT
463 send a previously sent Client Cookie to a server not known to support
464 DNS Cookies. To prevent the creation of a new Client Cookie for each
465 query to a non-DNS Cookie-supporting server, it is RECOMMENDED to not
466 send a Client Cookie to that server for a certain period, for example
471 * In order to provide minimal authentication, a client MUST use a
472 different Client Cookie for each different Server IP address.
474 * To prevent tracking of clients, a new Client Cookie MUST be
475 created when the Client IP address changes.
477 * To prevent tracking of clients by a non-DNS Cookie-supporting
478 server, a client MUST NOT send a previously sent Client Cookie to
479 a server in the absence of an associated Server Cookie.
481 Note that it is infeasible for a client to detect a change in the
482 public IP address when the client is behind a routing device
483 performing Network Address Translation (NAT). A server may track the
484 public IP address of that routing device performing the NAT.
485 Preventing tracking of the public IP of a NAT-performing routing
486 device is beyond the scope of this document.
4888.2. Server Cookie Construction
490 [RFC7873] did not give a precise recipe for constructing Server
491 Cookies, but it did recommend usage of a pseudorandom function strong
492 enough to prevent the guessing of cookies. In this document,
493 SipHash-2-4 is assigned as the pseudorandom function to be used for
494 version 1 Server Cookies. SipHash-2-4 is considered sufficiently
495 strong for the immediate future, but predictions about future
496 development in cryptography and cryptanalysis are beyond the scope of
499 The precise structure of version 1 Server Cookies is defined in this
500 document. A portion of the structure is made up of unhashed data
501 elements that are exposed in cleartext to an on-path observer. These
502 unhashed data elements are taken along as input to the SipHash-2-4
503 function of which the result is the other portion of the Server
504 Cookie, so the unhashed portion of the Server Cookie cannot be
505 changed by an on-path attacker without also recalculating the hashed
506 portion for which the Server Secret needs to be known.
508 One of the elements in the unhashed portion of version 1 Server
509 Cookies is a Timestamp used to prevent Replay Attacks. Servers
510 verifying version 1 Server Cookies need to have access to a reliable
511 time value, one that cannot be altered by an attacker, to compare
512 with the Timestamp value. Furthermore, all servers participating in
513 an anycast set that validate version 1 Server Cookies need to have
514 their clocks synchronized.
516 For an on-path adversary observing a Server Cookie (as mentioned in
517 the first paragraph of Section 8), the cleartext Timestamp data
518 element reveals the lifetime during which the observed Server Cookie
519 can be used to attack the client.
521 In addition to the Security Considerations in this section, the
522 Security Considerations section of [RFC7873] still applies.
5269.1. Normative References
528 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
529 DOI 10.17487/RFC1982, August 1996,
530 <https://www.rfc-editor.org/info/rfc1982>.
532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
533 Requirement Levels", BCP 14, RFC 2119,
534 DOI 10.17487/RFC2119, March 1997,
535 <https://www.rfc-editor.org/info/rfc2119>.
537 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
538 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
539 <https://www.rfc-editor.org/info/rfc3339>.
541 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
542 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
543 <https://www.rfc-editor.org/info/rfc7873>.
545 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
546 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
547 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
550 Aumasson, J. and D. J. Bernstein, "SipHash: A Fast Short-
551 Input PRF", Progress in Cryptology - INDOCRYPT 2012,
552 Lecture Notes in Computer Science, vol. 7668, December
553 2012, <https://doi.org/10.1007/978-3-642-34931-7_28>.
5559.2. Informative References
557 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
558 "Temporary Address Extensions for Stateless Address
559 Autoconfiguration in IPv6", RFC 8981,
560 DOI 10.17487/RFC8981, February 2021,
561 <https://www.rfc-editor.org/info/rfc8981>.
563Appendix A. Test Vectors
565A.1. Learning a New Server Cookie
567 A resolver (client) sending from IPv4 address 198.51.100.100 sends a
568 query for "example.com" to an authoritative server listening on
569 192.0.2.53 from which it has not yet learned the server cookie.
571 The DNS requests and replies shown in this appendix are in a "dig"-
572 like format. The content of the DNS COOKIE Option is shown in
573 hexadecimal format after "; COOKIE:".
576 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406
577 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
579 ;; OPT PSEUDOSECTION:
580 ; EDNS: version: 0, flags:; udp: 4096
581 ; COOKIE: 2464c4abcf10c957
587 The authoritative nameserver (server) is configured with the
588 following secret: e5e973e5a6b2a43f48e7dc849e37bfcf (as hex data).
590 It receives the query on Wed Jun 5 10:53:05 UTC 2019.
592 The content of the DNS COOKIE Option that the server will return is
593 shown below in hexadecimal format after "; COOKIE:".
595 The Timestamp field Section 4.3 in the returned Server Cookie has
596 value 1559731985. In the format described in [RFC3339], this is
597 2019-06-05 10:53:05+00:00.
600 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406
601 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
603 ;; OPT PSEUDOSECTION:
604 ; EDNS: version: 0, flags:; udp: 4096
605 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 (good)
610 example.com. 86400 IN A 192.0.2.34
612 ;; Query time: 6 msec
613 ;; SERVER: 192.0.2.53#53(192.0.2.53)
614 ;; WHEN: Wed Jun 5 10:53:05 UTC 2019
617A.2. The Same Client Learning a Renewed (Fresh) Server Cookie
619 40 minutes later, the same resolver (client) queries the same server
620 for "example.org". It reuses the Server Cookie it learned in the
623 The Timestamp field in that previously learned Server Cookie, which
624 is now sent along in the request, was and is 1559731985. In the
625 format of [RFC3339], this is 2019-06-05 10:53:05+00:00.
628 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939
629 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
631 ;; OPT PSEUDOSECTION:
632 ; EDNS: version: 0, flags:; udp: 4096
633 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480
639 The authoritative nameserver (server) now generates a new Server
640 Cookie. The server SHOULD do this because it can see the Server
641 Cookie sent by the client is older than half an hour (Section 4.3),
642 but it is also fine for a server to generate a new Server Cookie
643 sooner or even for every answer.
645 The Timestamp field in the returned new Server Cookie has value
646 1559734385, which, in the format of [RFC3339], is 2019-06-05
650 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939
651 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
653 ;; OPT PSEUDOSECTION:
654 ; EDNS: version: 0, flags:; udp: 4096
655 ; COOKIE: 2464c4abcf10c957010000005cf7a871d4a564a1442aca77 (good)
660 example.org. 86400 IN A 192.0.2.34
662 ;; Query time: 6 msec
663 ;; SERVER: 192.0.2.53#53(192.0.2.53)
664 ;; WHEN: Wed Jun 5 11:33:05 UTC 2019
667A.3. Another Client Learning a Renewed Server Cookie
669 Another resolver (client) with IPv4 address 203.0.113.203 sends a
670 request to the same server with a valid Server Cookie that it learned
671 before (on Wed Jun 5 09:46:25 UTC 2019).
673 The Timestamp field of the Server Cookie in the request has value
674 1559727985, which, in the format of [RFC3339], is 2019-06-05
677 Note that the Server Cookie has Reserved bytes set but is still valid
678 with the configured secret; the Hash part is calculated taking along
682 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736
683 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
685 ;; OPT PSEUDOSECTION:
686 ; EDNS: version: 0, flags:; udp: 4096
687 ; COOKIE: fc93fc62807ddb8601abcdef5cf78f71a314227b6679ebf5
693 The authoritative nameserver (server) replies with a freshly
694 generated Server Cookie for this client conformant with this
695 specification, i.e., with the Reserved bits set to zero.
697 The Timestamp field in the returned new Server Cookie has value
698 1559734700, which, in the format of [RFC3339], is 2019-06-05
702 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736
703 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
705 ;; OPT PSEUDOSECTION:
706 ; EDNS: version: 0, flags:; udp: 4096
707 ; COOKIE: fc93fc62807ddb86010000005cf7a9acf73a7810aca2381e (good)
712 example.com. 86400 IN A 192.0.2.34
714 ;; Query time: 6 msec
715 ;; SERVER: 192.0.2.53#53(192.0.2.53)
716 ;; WHEN: Wed Jun 5 11:38:20 UTC 2019
719A.4. IPv6 Query with Rolled Over Secret
721 The query below is from a client with IPv6 address
722 2001:db8:220:1:59de:d0f4:8769:82b8 to a server with IPv6 address
723 2001:db8:8f::53. The client has learned a valid Server Cookie before
724 (on Wed Jun 5 13:36:57 UTC 2019) when the Server had the secret:
725 dd3bdf9344b678b185a6f5cb60fca715. The server now uses a new secret,
726 but it can still validate the Server Cookie provided by the client as
727 the old secret has not expired yet.
729 The Timestamp field in the Server Cookie in the request has value
730 1559741817, which, in the format of [RFC3339], is 2019-06-05
734 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774
735 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
737 ;; OPT PSEUDOSECTION:
738 ; EDNS: version: 0, flags:; udp: 4096
739 ; COOKIE: 22681ab97d52c298010000005cf7c57926556bd0934c72f8
745 The authoritative nameserver (server) replies with a freshly
746 generated server cookie for this client with its new secret:
747 445536bcd2513298075a5d379663c962.
749 The Timestamp field in the returned new Server Cookie has value
750 1559741961, which, in the format of [RFC3339], is 2019-06-05
754 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774
755 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
757 ;; OPT PSEUDOSECTION:
758 ; EDNS: version: 0, flags:; udp: 4096
759 ; COOKIE: 22681ab97d52c298010000005cf7c609a6bb79d16625507a (good)
764 example.net. 86400 IN A 192.0.2.34
766 ;; Query time: 6 msec
767 ;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53)
768 ;; WHEN: Wed Jun 5 13:36:57 UTC 2019
771Appendix B. Implementation Status
773 At the time of writing, BIND from version 9.16 and Knot DNS from
774 version 2.9.0 create Server Cookies according to the recipe described
775 in this document. Unbound and NSD have a Proof-of-Concept
776 implementation that has been tested for interoperability during the
777 hackathon at IETF 104 in Prague. Construction of privacy maintaining
778 Client Cookies according to the directions in this document have been
779 implemented in the getdns library and will be in the upcoming getdns-
780 1.6.1 release and in Stubby version 0.3.1.
784 Thanks to Witold Krecicki and Pieter Lexis for valuable input,
785 suggestions, text, and above all for implementing a prototype of an
786 interoperable DNS Cookie in Bind9, Knot, and PowerDNS during the
787 hackathon at IETF 104 in Prague. Thanks for valuable input and
788 suggestions go to Ralph Dolmans, Bob Harold, Daniel Salzman, Martin
789 Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron, Bob
790 Harold, Philip Homburg, Tim Wicinski, and Brian Dickson.
795 Internet Systems Consortium
798 Email: ondrej@isc.org
807 Email: willem@nlnetlabs.nl
810 Donald E. Eastlake 3rd
811 Futurewei Technologies
812 2386 Panoramic Circle
814 United States of America
816 Phone: +1-508-333-2270
817 Email: d3e3e3@gmail.com
821 Internet Systems Consortium
823 Redwood City, CA 94063
824 United States of America