| RFC 9018 | Interoperable DNS Server Cookies | April 2021 |
| Sury, et al. | Standards Track | [Page] |
DNS Cookies, as specified in RFC 7873, are alightweight DNS transaction security mechanism that provide limited protectionto DNS servers and clients against a variety of denial-of-serviceamplification, forgery, or cache-poisoning attacks by off-path attackers.¶
This document updates RFC 7873 with precise directions for creating ServerCookies so that an anycast server set including diverse implementations willinteroperate with standard clients, with suggestions for constructing Client Cookiesin a privacy-preserving fashion, and with suggestions on how to update a ServerSecret. An IANA registry listing the methods and associated pseudorandomfunction suitable for creating DNS Server Cookies has been created with the methoddescribed in this document as the first and, as of the time of publication, only entry.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9018.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
DNS Cookies, as specified in[RFC7873], are alightweight DNS transaction security mechanism that provide limited protectionto DNS servers and clients against a variety of denial-of-serviceamplification, forgery, or cache-poisoning attacks by off-path attackers. Thisdocument specifies a means of producing interoperable cookies so that ananycast server set including diverse implementations can be easily configuredto interoperate with standard clients. Also, single-implementation ornon-anycast services can benefit from a well-studied standardized algorithmfor which the behavioral and security characteristics are more widelyknown.¶
The threats considered for DNS Cookies and the properties of the DNSSecurity features other than DNS Cookies are discussed in[RFC7873].¶
InSection 6 of [RFC7873], for simplicity, it is "RECOMMENDED that the same Server Secret be used byeach DNS server in a set of anycast servers." However, how precisely aServer Cookie is calculated from this Server Secret is left to theimplementation.¶
This guidance has led to a gallimaufry of DNS Cookie implementations,calculating the Server Cookie in different ways. As a result, DNS Cookiesare impractical to deploy on multi-vendor anycast networks because evenwhen all DNS Software shares the same secret, asRECOMMENDED inSection 6 of [RFC7873], the Server Cookie constructed by one implementationcannot generally be validated by another.¶
There is no need for DNS client (resolver) Cookies to be interoperableacross different implementations. Each client need only be able to recognizeits own cookies. However, this document does contain recommendations forconstructing Client Cookies in a client-protecting fashion.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Note: "IP address" is used herein as a length-independent term coveringboth IPv4 and IPv6 addresses.¶
AppendicesA.1 andB.1 of[RFC7873] provideexample "simple" algorithms for computing Client and Server Cookies,respectively. These algorithmsMUST NOT be used as theresulting cookies are too weak when evaluated against modern securitystandards.¶
Appendix B.2 of [RFC7873] provides an example "more complex" serveralgorithm. This algorithm is replaced by the interoperable specification inSection 4 of this document, whichMUST be used by Server Cookieimplementations.¶
This document has suggestions on Client Cookie construction inSection 3.The previous example inAppendix A.2 of [RFC7873] isNOT RECOMMENDED.¶
The Client Cookie acts as an identifier for a given client and its IPaddress and needs to be unguessable. In order to provide minimalauthentication of the targeted server, a clientMUST use adifferent Client Cookie for each different Server IP address. This complicatesa server's ability to spoof answers for other DNS servers. The Client CookieSHOULD have 64 bits of entropy.¶
When a server does not support DNS Cookies, the clientMUST NOT send the sameClient Cookie to that same server again. Instead, it is recommended that theclient does not send a Client Cookie to that server for a certain period(for example, five minutes) before it retries with a new Client Cookie.¶
When a server does support DNS Cookies, the client should store the ClientCookie alongside the Server Cookie it registered for that server.¶
Except for when the Client IP address changes, there is no need to change theClient Cookie often. It is then reasonable to change the Client Cookie only ifit has been compromised or after a relatively long implementation-definedperiod of time. The time period should be no longer than a year, and in anycase, Client Cookies are not expected to survive a program restart.¶
Client-Cookie = 64 bits of entropy¶
Previously, the recommended algorithm to compute the Client Cookie includedthe Client IP address as an input to a hashing function. However, when implementingthe DNS Cookies, several DNS vendors found it impractical to include the Client IPas the Client Cookie is typically computed before the Client IP address isknown. Therefore, the requirement to put the Client IP address as input wasremoved.¶
However, for privacy reasons, in order to prevent tracking of devices acrosslinks and to not circumvent IPv6 Privacy Extensions[RFC8981], clientsMUST NOT reuse a Client or Server Cookie after the Client IP address has changed.¶
One way to satisfy this requirement for non-reuse is to register the Client IPaddress alongside the Server Cookie when it receives the Server Cookie. Insubsequent queries to the server with that Server Cookie, the socketMUST bebound to the Client IP address that was also used (and registered) when itreceived the Server Cookie. Failure to bindMUST then result in a new ClientCookie.¶
The Server Cookie is effectively a Message Authentication Code (MAC). TheServer Cookie, when it occurs in a COOKIE option in a request, is intended toweakly assure the server that the request came from a client that is both atthe source IP address of the request and using the Client Cookie included inthe option. This assurance is provided by the Server Cookie that the server (or any other server from the anycast set) sent to that client in an earlier response and that appears as the Server Cookie field in the weakly authenticated request (seeSection 5.2 of [RFC7873]).¶
DNS Cookies do not provide protection against "on-path"adversaries (seeSection 9 of [RFC7873]). Anon-path observer that has seen a Server Cookie for a client can abuse thatServer Cookie to spoof request for that client within the time span a ServerCookie is valid (seeSection 4.3).¶
The Server Cookie is calculated from the Client Cookie, a series of Sub-Fields specified below, the Client IP address, and a Server Secret that is known only to the server or only to the set of servers at the same anycast address.¶
For calculation of the Server Cookie, a pseudorandom function isRECOMMENDED with the property that an attacker that does notknow the Server Secret, cannot find (any information about) the Server Secret,and cannot create a Server Cookie for any combination of the Client Cookie,the series of Sub-Fields specified below, and the client IP address, for whichit has not seen a Server Cookie before. Because DNS servers need to use the pseudorandom function in order to verifyServer Cookies, it isRECOMMENDED that it be efficient tocalculate.The pseudorandom function described in[SipHash-2-4] andintroduced inSection 4.4 of this document fits theserecommendations.¶
Changing the Server Secret regularly isRECOMMENDED but,when a secure pseudorandom function is used, it need not be changed toofrequently. Once a month, for example, would be adequate. SeeSection 5 on operator and implementation guidelines forupdating a Server Secret.¶
The 128-bit Server Cookie consists of the following Sub-Fields: a 1-octet Version Sub-Field,a 3-octet Reserved Sub-Field, a 4-octet Timestamp Sub-Field, and an 8-octet HashSub-Field.¶
0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Version | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Timestamp |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Hash || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The Version Sub-Field prescribes the structure and Hash calculation formula.This document defines Version 1 to be the structure and way to calculate theHash Sub-Field as defined in this section.¶
The value of the Reserved Sub-Field is reserved for future versions ofserver-side cookie construction. On construction, itMUST beset to zero octets. On Server Cookie verification, the serverMUST NOT enforce those fields to be zero, and the Hash should be computedwith the received value as described inSection 4.4.¶
The Timestamp value prevents Replay Attacks andMUST bechecked by the server to be within a defined period of time. The DNS serverSHOULD allow cookies within a 1-hour period in the past and a5-minute period into the future to allow operation of low-volume clients andsome limited time skew between the DNS servers in the anycast set.¶
The Timestamp value specifies a date and time in the form of a 32-bitunsigned number of seconds elapsed since 1 January 197000:00:00 UTC, ignoring leap seconds, in network byte order. All comparisonsinvolving these fieldsMUST use "Serial numberarithmetic", as defined in[RFC1982].[RFC1982] specifies how the differences should be handled. Thishandles any relative time window less than 68 years, at any time in the future(2038, 2106, 2256, 22209, or later.)¶
The DNS serverSHOULD generate a new Server Cookie at least if the receivedServer Cookie from the client is more than half an hour old, but itMAYgenerate a new cookie more often than that.¶
It's important that all the DNS servers use the same algorithm for computingthe Server Cookie. This document defines the Version 1 of the server-sidealgorithm to be:¶
Hash = SipHash-2-4( Client Cookie | Version | Reserved | Timestamp | Client-IP, Server Secret )¶
where "|" indicates concatenation.¶
Notice that Client-IP is used for hash generation even though it is notincluded in the cookie value itself. Client-IP can be either 4 bytes for IPv4or 16 bytes for IPv6. The length of all the concatenated elements (the inputinto[SipHash-2-4])MUST be either precisely 20 bytes in case of an IPv4Client-IP or precisely 32 bytes in case of an IPv6 Client-IP.¶
When a DNS server receives a Server Cookie version 1 for validation, the lengthof the received COOKIE optionMUST be precisely 24 bytes: 8 bytes for theClient Cookie plus 16 bytes for the Server Cookie. Verification of the lengthof the received COOKIE option isREQUIRED to guarantee the length of the inputinto[SipHash-2-4] to be precisely 20 bytes in the case of an IPv4 Client-IP andprecisely 32 bytes in the case of an IPv6 Client-IP. This ensures that the inputinto[SipHash-2-4] is an injective function of the elements making up theinput, and thereby prevents data substitution attacks. More specifically, thisprevents a 36-byte COOKIE option coming from an IPv4 Client-IP to be validatedas if it were coming from an IPv6 Client-IP.¶
The Server SecretMUST be configurable to make sure that servers in an anycastnetwork return consistent results.¶
Changing the Server Secret regularly isRECOMMENDED. All servers in an anycastset must be able to verify the Server Cookies constructed by all other serversin that anycast set at all times. Therefore, it is vital that the Server Secretis shared among all servers before it is used to generate Server Cookies on anyserver.¶
Also, to maximize maintaining established relationships between clients andservers, an old Server Secret should be valid for verification purposes for aspecific period.¶
To facilitate this, deployment of a new Server SecretMUST be done in threestages:¶
The new Server Secret is deployed on all the servers in an anycast set bythe operator.¶
Each server learns the new Server Secret but keeps using the previous ServerSecret to generate Server Cookies.¶
Server Cookies constructed with both the new Server Secret and the previousServer Secret are considered valid when verifying.¶
After stage 1 is completed, all the servers in the anycast set have learned thenew Server Secret and can verify Server Cookies constructed with it, but keepgenerating Server Cookies with the old Server Secret.¶
This stage is initiated by the operator after the Server Cookie is presenton all members in the anycast set.¶
When entering Stage 2, servers start generating Server Cookies with the newServer Secret. The previous Server Secret is not yet removed/forgotten.¶
Server Cookies constructed with both the new Server Secret and theprevious Server Secret are considered valid when verifying.¶
This stage is initiated by the operator when it can be assumed that mostclients have obtained a Server Cookie derived from the new Server Secret.¶
With this stage, the previous Server Secret can be removed andMUST NOT beused anymore for verifying.¶
It isRECOMMENDED that the operator wait, after initiating Stage 2 and before initiating Stage 3, at least a period of time equal to the longest TTL in the zones served by the server plus 1 hour.¶
The operatorSHOULD wait at least longer than the period clients are allowedto use the same Server Cookie, whichSHOULD be 1 hour (seeSection 4.3).¶
[SipHash-2-4] is a pseudorandom function suitable as a Message AuthenticationCode. It isREQUIRED that a compliant DNS server use SipHash-2-4 as amandatory and default algorithm for DNS Cookies to ensure interoperabilitybetween the DNS Implementations.¶
The construction method and pseudorandom function used in calculating andverifying the Server Cookies are determined by the initial version byte and bythe length of the Server Cookie. Additional pseudorandom or constructionalgorithms for Server Cookies might be added in the future.¶
IANA has created a registry under the "Domain Name System (DNS) Parameters" heading as follows:¶
| Version | Size | Method |
|---|---|---|
| 0 | 8-32 | Reserved |
| 1 | 8-15 | Unassigned |
| 1 | 16 | SipHash-2-4 [RFC9018]Section 4 |
| 1 | 17-32 | Unassigned |
| 2-239 | 8-32 | Unassigned |
| 240-254 | 8-32 | Reserved for Private Use |
| 255 | 8-32 | Reserved |
DNS Cookies provide limited protection to DNS servers and clients against avariety of denial-of-service amplification, forgery, or cache-poisoning attacksby off-path attackers. They provide no protection against on-path adversariesthat can observe the plaintext DNS traffic. An on-path adversary that canobserve a Server Cookie for a client and server interaction can use thatServer Cookie for denial-of-service amplification, forgery, or cache-poisoningattacks directed at that client for the lifetime of the Server Cookie.¶
In[RFC7873], it wasRECOMMENDED to construct a Client Cookie by using apseudorandom function of the Client IP address, the Server IP address, and asecret quantity known only to the client. The Client IP address was included toensure that a client could not be tracked if its IP address changes due toprivacy mechanisms or otherwise.¶
In this document, we changed Client Cookie construction to be just 64 bits ofentropy newly created for each new upstream server the client connects to.As a consequence, additional care needs to be taken to prevent tracking ofclients. To prevent tracking, a new Client Cookie for a serverMUST be createdwhenever the Client IP address changes.¶
Unfortunately, tracking Client IP address changes is impractical with serversthat do not support DNS Cookies. To prevent tracking of clients with non-DNSCookie-supporting servers, a clientMUST NOT send a previously sent ClientCookie to a server not known to support DNS Cookies. To prevent the creation ofa new Client Cookie for each query to a non-DNS Cookie-supporting server, itisRECOMMENDED to not send a Client Cookie to that server for a certain period,for example five minutes.¶
Summarizing:¶
In order to provide minimal authentication, a clientMUST use adifferent Client Cookie for each different Server IP address.¶
To prevent tracking of clients, a new Client CookieMUST be createdwhen the Client IP address changes.¶
To prevent tracking of clients by a non-DNS Cookie-supporting server,a clientMUST NOT send a previously sent Client Cookie to a server in theabsence of an associated Server Cookie.¶
Note that it is infeasible for a client to detect a change in the public IPaddress when the client is behind a routing device performing Network AddressTranslation (NAT). A server may track the public IP address of that routingdevice performing the NAT. Preventing tracking of the public IP of aNAT-performing routing device is beyond the scope of this document.¶
[RFC7873] did not give a precise recipe for constructing Server Cookies, butit did recommend usage of a pseudorandom function strong enough to preventthe guessing of cookies. In this document, SipHash-2-4 is assigned as thepseudorandom function to be used for version 1 Server Cookies. SipHash-2-4 isconsidered sufficiently strong for the immediate future, but predictions aboutfuture development in cryptography and cryptanalysis are beyond the scope ofthis document.¶
The precise structure of version 1 Server Cookies is defined in thisdocument. A portion of the structure is made up of unhashed data elementsthat are exposed in cleartext to an on-path observer. These unhashed dataelements are taken along as input to the SipHash-2-4 function of which theresult is the other portion of the Server Cookie, so the unhashed portion ofthe Server Cookie cannot be changed by an on-path attacker without alsorecalculating the hashed portion for which the Server Secret needs to beknown.¶
One of the elements in the unhashed portion of version 1 Server Cookies isa Timestamp used to prevent Replay Attacks. Servers verifying version 1Server Cookies need to have access to a reliable time value, one that cannotbe altered by an attacker, to compare with the Timestamp value. Furthermore,all servers participating in an anycast set that validate version 1 ServerCookies need to have their clocks synchronized.¶
For an on-path adversary observing a Server Cookie (as mentioned in the firstparagraph ofSection 8), the cleartext Timestamp data element reveals thelifetime during which the observed Server Cookie can be used to attack theclient.¶
In addition to the Security Considerations in this section, the SecurityConsiderations section of[RFC7873] still applies.¶
A resolver (client) sending from IPv4 address 198.51.100.100 sends a query forexample.com to an authoritative server listening on 192.0.2.53 fromwhich it has not yet learned the server cookie.¶
The DNS requests and replies shown in this appendix are in a "dig"-like format.The content of the DNS COOKIE Option is shown in hexadecimal format after; COOKIE:.¶
;; Sending:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: 2464c4abcf10c957;; QUESTION SECTION:;example.com. IN A;; QUERY SIZE: 52¶
The authoritative nameserver (server) is configured with the following secret:e5e973e5a6b2a43f48e7dc849e37bfcf (as hex data).¶
It receives the query on Wed Jun 5 10:53:05 UTC 2019.¶
The content of the DNS COOKIE Option that the server will return is shownbelow in hexadecimal format after; COOKIE:.¶
The Timestamp fieldSection 4.3 in the returned Server Cookie has value1559731985. In the format described in[RFC3339], this is 2019-06-05 10:53:05+00:00.¶
;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 (good);; QUESTION SECTION:;example.com. IN A;; ANSWER SECTION:example.com. 86400 IN A 192.0.2.34;; Query time: 6 msec;; SERVER: 192.0.2.53#53(192.0.2.53);; WHEN: Wed Jun 5 10:53:05 UTC 2019;; MSD SIZE rcvd: 84¶
40 minutes later, the same resolver (client) queries the same server forexample.org. It reuses the Server Cookie it learned in the previousquery.¶
The Timestamp field in that previously learned Server Cookie, which is now sentalong in the request, was and is 1559731985. In the format of[RFC3339], this is2019-06-05 10:53:05+00:00.¶
;; Sending:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480;; QUESTION SECTION:;example.org. IN A;; QUERY SIZE: 52¶
The authoritative nameserver (server) now generates a new Server Cookie.The serverSHOULD do this because it can see the Server Cookiesent by the client is older than half an hour (Section 4.3), but it is also fine for a server to generatea new Server Cookie sooner or even for every answer.¶
The Timestamp field in the returned new Server Cookie has value 1559734385,which, in the format of[RFC3339], is 2019-06-05 11:33:05+00:00.¶
;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: 2464c4abcf10c957010000005cf7a871d4a564a1442aca77 (good);; QUESTION SECTION:;example.org. IN A;; ANSWER SECTION:example.org. 86400 IN A 192.0.2.34;; Query time: 6 msec;; SERVER: 192.0.2.53#53(192.0.2.53);; WHEN: Wed Jun 5 11:33:05 UTC 2019;; MSD SIZE rcvd: 84¶
Another resolver (client) with IPv4 address 203.0.113.203 sends a request tothe same server with a valid Server Cookie that it learned before(on Wed Jun 5 09:46:25 UTC 2019).¶
The Timestamp field of the Server Cookie in the request has value 1559727985,which, in the format of[RFC3339], is 2019-06-05 09:46:25+00:00.¶
Note that the Server Cookie has Reserved bytes set but is still valid with theconfigured secret; the Hash part is calculated taking along the Reserved bytes.¶
;; Sending:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: fc93fc62807ddb8601abcdef5cf78f71a314227b6679ebf5;; QUESTION SECTION:;example.com. IN A;; QUERY SIZE: 52¶
The authoritative nameserver (server) replies with a freshly generated ServerCookie for this client conformant with this specification, i.e., with the Reservedbits set to zero.¶
The Timestamp field in the returned new Server Cookie has value 1559734700,which, in the format of[RFC3339], is 2019-06-05 11:38:20+00:00.¶
;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: fc93fc62807ddb86010000005cf7a9acf73a7810aca2381e (good);; QUESTION SECTION:;example.com. IN A;; ANSWER SECTION:example.com. 86400 IN A 192.0.2.34;; Query time: 6 msec;; SERVER: 192.0.2.53#53(192.0.2.53);; WHEN: Wed Jun 5 11:38:20 UTC 2019;; MSD SIZE rcvd: 84¶
The query below is from a client with IPv6 address 2001:db8:220:1:59de:d0f4:8769:82b8 to a serverwith IPv6 address 2001:db8:8f::53. The client has learned a valid Server Cookiebefore (on Wed Jun 5 13:36:57 UTC 2019) when the Server had the secret:dd3bdf9344b678b185a6f5cb60fca715. The server now uses a new secret, but it can still validatethe Server Cookie provided by the client as the old secret has not expired yet.¶
The Timestamp field in the Server Cookie in the request has value1559741817, which, in the format of[RFC3339], is 2019-06-05 13:36:57+00:00.¶
;; Sending:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: 22681ab97d52c298010000005cf7c57926556bd0934c72f8;; QUESTION SECTION:;example.net. IN A;; QUERY SIZE: 52¶
The authoritative nameserver (server) replies with a freshly generated servercookie for this client with its new secret: 445536bcd2513298075a5d379663c962.¶
The Timestamp field in the returned new Server Cookie has value 1559741961,which, in the format of[RFC3339], is2019-06-05 13:39:21+00:00.¶
;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: 22681ab97d52c298010000005cf7c609a6bb79d16625507a (good);; QUESTION SECTION:;example.net. IN A;; ANSWER SECTION:example.net. 86400 IN A 192.0.2.34;; Query time: 6 msec;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53);; WHEN: Wed Jun 5 13:36:57 UTC 2019;; MSD SIZE rcvd: 84¶
At the time of writing, BIND from version 9.16 and Knot DNS from version 2.9.0create Server Cookies according to the recipe described in this document. Unboundand NSD have a Proof-of-Concept implementation that has been tested forinteroperability during the hackathon at IETF 104 in Prague. Constructionof privacy maintaining Client Cookies according to the directions in this documenthave been implemented in the getdns library and will be in the upcominggetdns-1.6.1 release and in Stubby version 0.3.1.¶
Thanks toWitold Krecicki andPieter Lexis for valuable input, suggestions, text, and aboveall for implementing a prototype of an interoperable DNS Cookie in Bind9, Knot,and PowerDNS during the hackathon at IETF 104 in Prague. Thanks for valuableinput and suggestions go toRalph Dolmans,Bob Harold,Daniel Salzman,Martin Hoffmann,Mukund Sivaraman,Petr Spacek,Loganaden Velvindron,Bob Harold,Philip Homburg,Tim Wicinski, andBrian Dickson.¶