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