[dns-operations] Check DNS-anycast-instances for same DNS Cookie

[Arsen STASIC]

* Mark Andrews <marka at isc.org> [2020-01-25 08:56 (+1100)]:
>> On 24 Jan 2020, at 21:36, Arsen STASIC <arsen.stasic at univie.ac.at> wrote:
>>
>> This software might be of interest for DNS anycast providers (or customers) which are running BIND.
>> With BIND 9.11 and newer DNS Cookies are enabled **automatically**.
>
>You seem surprised?  DNS COOKIE is a security feature and to be effective it needs to be enabled on both ends.  DNS COOKIE was introduced in a .0 release.  This is where feature changes are expected to occur.

True. I'm in favour of security features and would appreciate if more vendors implement DNS Cookies in their software! I recently came across ISC's knowledge base article [0] and dived into it and I thought it might not be on all TLD operator's radar. I just wanted to raise awareness and therefore did this small project [1].

>> While I was searching for software to check DNS Cookies and I didn't find anything.
>
>So “dig +cookie=<value>" was not enough?

Thanks, I must have missed that!

>> Therefore I wrote this small Perl script to check DNS anycast instances (over their mgmt-ip) for synchronized DNS Cookies:
>> https://github.com/stasic/dns-cookies
>
>Which assumes that all the queries are made in the same second as server cookies vary over time.  If you really want to test this you need to send the returned cookie option from the first response to all the other servers and check the rcode they return is not BADCOOKIE.  Exercise the cookie checking code in the server.

I know that cookies varies over time. I've tested it on a small 16-node anycast cluster and in my case I got the same cookie from all 16 nodes. 
But you are right on large anycast clusters cookies will vary over time due timing which could be addressed by sending asynchronous DNS queries.

>> If DNS Cookies are not the same between different DNS anycast instances it may cause warnings and intermittent query retries. Therefore I suggest either synchronize them or disable them.
>
>This is very alarmist.  DNS COOKIE secret key mismatches (includes algorithm mismatches) where expected to occur and DNS COOKIE clients are designed to handle them.  Unsynchronised secrets/algorithms are safer for the client that disabled cookies.  Additionally this really only becomes visible with local anycast clusters which don’t have source IP address affinity.  With globally distributed anycast you tend to hit the same node.

I just rephrased ISC's knowledge base article [0], which says: "Although the above scenario may cause warnings and intermittent query retries, it should not cause a service outage unless the client is not RFC-compliant or has been implemented particularly strictly." But TLD operators are very keen on performance, DNS security and on "correctness" of their DNS responses. Therefore right configuration is crucial for them.

You are right about globally distributed anycast tend to hit the same node, but in cases of maintenance you hit a different node. And TLD operators should take this into account and configure their BINDs properly to circumvent this issue.

If all TLD operators are aware of this issue my post would have been useless. Over this weekend my github project [1] was 9 times cloned, which probably means that it was helpful to some of this audience.

cheers
arsen

[0] https://kb.isc.org/docs/dns-cookies-on-servers-in-anycast-clusters
[1] https://github.com/stasic/dns-cookies