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

[Mukund Sivaraman <[e-mail]>]

On Fri, Jun 22, 2018 at 10:26:55PM -0400, Warren Kumari wrote:
> 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...

BTW, speaking of secret, section 7.1 (Client and Server Secret Rollover)
of RFC 7873 says this:

   The longer a secret is used, the higher the probability that it has
   been compromised.  Thus, clients and servers are configured with a
   lifetime setting for their secret, and they roll over to a new secret
   when that lifetime expires, or earlier due to deliberate jitter as
   described below.  The default lifetime is one day, and the maximum
   permitted is one month.

I don't think BIND has any support for automatic secret
rollovers. Re-configuring the secret manually per-day is not realistic
for a nameserver cluster.. at least it would be inconvenient and require
external tooling.

There should be a specification of KDF usage for this to work across
implementations.

		Mukund