> On 22 Jun 2018, at 1:19 am, Warren Kumari <[email protected]> wrote: > > > > On Thu, Jun 21, 2018 at 10:36 AM Mark Andrews <[email protected]> wrote: > > > On 21 Jun 2018, at 12:25 am, Petr Špaček <[email protected]> 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. > > > There are a number of anycast clusters which run different implementations > on the same IP. > > As an example: https://www.ripe.net/analyse/dns/k-root > "A K-root node consists of one or more servers running BIND, Knot or NSD." > > Unless I'm missing something obvious, it would be good having cookies be > valid when you e.g happen to hit a node in Lyon then a node in Geneva > (because of routing changes). > > W
Having different cookies return was a EXPECTED failure mode and the client has code to handle that if they have followed RFC 7873. These servers all handle TCP clients. They should be stable enough to not trigger the fallback to TCP. If the extended RCODE in the reply is BADCOOKIE and the Client Cookie in the reply matches what was sent, it means that the server was unwilling to process the request because it did not have the correct Server Cookie in it. The client SHOULD retry the request using the new Server Cookie from the response. Repeated BADCOOKIE responses to requests that use the Server Cookie provided in the previous response may be an indication that either the shared secrets or the method for generating secrets in an anycast cluster of servers is inconsistent. If the reply to a retried request with a fresh Server Cookie is BADCOOKIE, the client SHOULD retry using TCP as the transport, since the server will likely process the request normally based on the security provided by TCP (see Section 5.2.3). > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > > > -- > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
