> On 21 Jun 2018, at 12:25 am, Petr Špaček <petr.spa...@nic.cz> wrote: > > On 20.6.2018 16:10, Paul Wouters wrote: >> On Wed, 20 Jun 2018, Petr Špaček wrote: >> >>> it seems that current specification of DNS cookies in RFC 7873 is not >>> detailed enough to allow deployment of DNS cookies in multi-vendor >>> anycast setup, i.e. a setup where one IP address is backed by multiple >>> DNS servers. >>> >>> The problem is lack of standardized algorithm to generate server >>> cookie from a shared secret. In practice, even if users manually >>> configure the same shared secret, Knot DNS and BIND will use diffrent >>> algorithm to generate server cookie and as consequence these two >>> cannot reliably back the same IP address and have DNS cookies enabled. >>> >>> One of root server operators told me that they are not going to enable >>> DNS cookies until it can work with multi-vendor anycast, and I think >>> this is very reasonable position. >>> >>> So, vendors, would you be willing to standardize on small number of >>> server cookie algorithms to enable multi-vendor deployments? >> >> I think this is a good idea but there are already two examples in RFC >> 7873 for cookie generation. Is there a problem with those examples, or >> is there only a lack of options in the implementation to configure >> these? If the latter, than no new IETF work would be needed. > > These are mere examples and not specifications with all the details > necessary for reliable interoperability. > E.g. when a cookie is "old" according to B.2.?
I really depends on the algorithm being used. > E.g. are there privacy considerations with plain HMAC vs. encryption? Not the way AES is being used. > 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. > If we decide to standardize we need to find a reasonable algorihm and > standardize all its variables to make it work without run-time > synchronization (posssibly except key rotation but it can be done > avoided as well). BIND implemented 3 algorithms. All three were similar. The only difference was how the hash is generated. The hmac-sha1 and hmac-sha256-8 take identical inputs. AES is slightly different because it is AES. > This message is for other DNS vendors to see if there is an interest in > standardizing something we can all share and operators use in practice. > > -- > Petr Špaček @ CZ.NIC > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
