Hello Mark, On 06/20/2018 11:01 PM, Mark Andrews wrote: > >> 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. > > The server cookie examples have all the details required to build a > interoperable > implementation. i.e. with the same inputs you will get the same outputs. >
So how should the DNS cookies be implemented? IMHO if one server uses https://tools.ietf.org/html/rfc7873#appendix-B.1 and another server uses https://tools.ietf.org/html/rfc7873#appendix-B.2, then it's not interoperable. Actually the upcoming Knot DNS 2.7 implemented "B.1" using Siphash instead of FNV. Bind probably implemented B.2. Are both implementations correct? Thanks, Daniel >> E.g. when a cookie is "old" according to B.2.? >> E.g. are there privacy considerations with plain HMAC vs. encryption? > > >> 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. >> >> 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). >> >> 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 > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
