Support OPT COOKIE option in client and server


  • Server: accept client COOKIE options and send back server cookies, cache the most recent server cookie returned by the server, if any. could try being strict with BADCOOKIE+cookie response when server cookie is missing from request?
  • Client: send client COOKIE options to servers, validate that returned client COOKIE in response is correct

Broken out from #1 since this involves additional client/server logic, whereas the other items in there are mainly just parsers

Assigned to
1 year, 18 days ago
3 months ago
Low Priority Security

~nickbp 1 year, 18 days ago

This should be easier under the current structure (especially now that flatbuffers are finally gone) but this probably isn't that critical in terms of how many clients actually use or enforce this.

~nickbp referenced this from #8 3 months ago

~nickbp 3 months ago

Thinking it'd make sense to get this off the list, there's been similar support added for EDNS PADDING recently in the DoT/DoH clients and this isn't too different from that. There's server and client halves that would behave a bit differently:


  • After testing some queries in dig, it looks like at least both UDP and TCP queries will include a client cookie, so we may as well implement server-side support for both of those.
  • sha256 of concatenated clientip+clientcookie+secretdata, then truncate the hash from 32 bytes to 8 bytes (ref https://www.rfc-editor.org/rfc/rfc7873.html#appendix-B)
  • The server randdata is tricky in HA situations. By default can generate a random secret on startup, then allow override with a secret provided via envvar. The same secret would be shared for both UDP and TCP endpoints.
  • When generating the server secret, could give an informational message if starting in a docker container and no secret is provided via env (using a hint envvar added to our Dockerfile)


  • I imagine it doesn't hurt to just include support in all of the clients (UDP/TCP/DoT/DoH), where each one would have its own cached client secret and server key pair
  • sha256 of concatenated clientip+serverip/serverhost+randdata then truncate the hash from 32 bytes to 8 bytes (ref https://www.rfc-editor.org/rfc/rfc7873.html#appendix-A)
  • The client randdata could be fully randomized and generated per client object

~nickbp 3 months ago

Can exercise via dig with the +cookie=value/+nocokie options, or maybe with +ednsopt=COOKIE[:value]

~nickbp referenced this from #37 3 months ago