Provide a mechanism (build or runtime) to turn off server-side support for RFC7873
There is a corner case scenario that affects operators running anycast (or load-balanced) authoritative servers in a heterogenous environment with a mixture of levels of support for RFC7873.
The RFC does reasonably consider operating in an anycast environment, and points out:
For servers accessed via anycast, to successfully support DNS Cookies, either (1) the server clones must all use the same Server Secret or (2) the mechanism that distributes requests to the server clones must cause the requests from a particular client to go to a particular server for a sufficiently long period of time that extra requests due to changes in Server Cookies resulting from accessing different server machines are not unduly burdensome. (When such anycast-accessed servers act as recursive servers or otherwise act as clients, they normally use a different unique address to source their requests, to avoid confusion in the delivery of responses.)
The reason why this consideration is documented in the RFC is this:
A DNS client where DNS Cookies are implemented and enabled examines the response for DNS Cookies and MUST discard the response if it contains an illegal COOKIE option length or an incorrect Client Cookie value. If the client is expecting the response to contain a COOKIE option and it is missing, the response MUST be discarded. If the COOKIE option Client Cookie is correct, the client caches the Server Cookie provided, even if the response is an error response (RCODE non-zero).
This effectively means that there are 3 viable scenarios to prevent clients (whose behaviour is unknown) from dropping query responses when their queries go to a new server than the one they had been communicating with:
a) None of the servers offer server-side cookies b) All of the servers offer server-side cookies and in addition share the same server secret c) The mechanism that distributes request to the server clones ensure that clients only reach the same server for as long as possible
BIND 9.11.3 (the ESV version of BIND which replaces BIND 9.9's position as our current ESV) implements server-side RFC7873, enabled by default, with no mechanism for switching it off.
Operators of load-balanced/anycast clusters populated by servers from other DNS source code providers that don't offer server-side cookie support, or which do, but which can't be configured to share the server secret, are put in a difficult position, as they'll be required to do one of:
- Deploy option c)
- Remove other servers that don't support b) from their cluster/balanced environment
- Deploy alternative addressing schemes so that the servers supporting RFC7873 are on one set of IP addresses, and the others that don't (or which have different server secrets) are on another set of IP addresses.
This seems an unreasonable constraint to put on server operators who just want to upgrade the version of BIND that they're running.
Therefore I'm strongly suggesting that while it is good that by default BIND 9.11 supports and provides server-side support for RFC7873, that we also need a fallback option to disable it for server operators who need to be able to do this in the short term, until other DNS software providers have caught up and implemented RFC7873.