Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

[Warren Kumari <[e-mail]>]

On Fri, Jun 22, 2018 at 8:29 PM Evan Hunt <[e-mail]> wrote:

> On Thu, Jun 21, 2018 at 11:19:55AM -0400, Warren Kumari wrote:
> > There are a number of anycast clusters which run different
> > implementations on the same IP.
>
> Sure, but as long as the algorithm is settable for each server in the
> anycast so that all of them can match, then I don't think it matters
> if the different implementations have different defaults, does it?
>

​Yup, as long as they can be set to be the same algorithm, and same inputs,
you are correct. ​

​I was responding to Mark's response to Petr (?):
>> Besides this, BIND defaults to AES-based algorithm which is not
>> specified in the RFC and Knot DNS has its own because developers
>> considered the BIND's approch overkill.
>
> What does it matter what the default algorithm is.  Unless you are
> running a anycast cluster IT DOES NOT MATTER.  If you are running
> a anycast cluster you just needs to make sure all the server are set
> up the same way.
​

I have not tried configuring cookie on Knot, but looking
in alg_containers.c, I can configure:
{ 0, "FNV-64" },
{ 1, "HMAC-SHA256-64" }

Under BIND:
cookie-algorithm:
Set the algorithm to be used when generating the server cookie. One of
"aes", "sha1"
or "sha256". The default is "aes" if supported by the cryptographic library
or otherwise
"sha256".

So, if I set both to use their (non-default) of SHA256 (and set the same
secret:-)) do they actually generate compatible cookies?
I'd guess / assume so, but I haven't tested this...
W



>
> --
> Evan Hunt -- [e-mail]
> Internet Systems Consortium, Inc.
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf