* Mark Andrews <[email protected]> [2020-01-25 08:56 (+1100)]:
On 24 Jan 2020, at 21:36, Arsen STASIC <[email protected]> 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
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
