auth: more configurability for edns-cookie-secret #15941
Description
- Program: Authoritative
- Issue type: Feature request
Short description
EDNS Cookies, on the server side as an auth, can currently be configured explicitly with their full value. This is good for anycast clusters but slightly awkward for individual nodes that do not care whether their secret is identical to that of other machines.
Meanwhile, in an anycast cluster, sometimes the secret wants to be rolled on all machines, which never is an instantaneous event. NSD (via a cookie file), BIND and Knot (via "you can put multiple secrets in your config and while the first one generates new cookies, the others can still validate older cookies") support rolling. We do not.
Usecase (random)
For non-anycast users that do not need planned rolls, a new value like edns-cookie-secret=random generates a random key at startup. This key is not persisted anywhere.
Open question: should we refresh it periodically if the server runs for a long time?
Usecase (anycast)
For anycast users that do need planned rolls, we need to be able to recognise cookies generated with previous secrets.
Shape options
Simple, limited:
edns-cookie-secret=[current]
edns-previous-cookie-secret=[past]
Slightly awkward, powerful:
edns-cookie-secret=[current],[past1],[past2],[past3]
The first form could of course also take a list in -previous- but then we might as well pick the second shape right away.
References
https://bind9.readthedocs.io/en/v9.20.11/reference.html#namedconf-statement-cookie-secret
https://nsd.docs.nlnetlabs.nl/en/latest/manpages/nsd.conf.html#cookie~3