Hi Paul, Cookies are a problem for when there are several servers. Those servers have to coordinate the cookie responses, and there are configuration options for that. But the default on was causing the trouble by default, instead of a more cautious default off, that does not cause the problem all of a sudden after an upgrade. Best regards, Wouter On 07/10/2021 14:16, Paul Wouters via nsd-users wrote:> On Thu, 7 Oct 2021, Wouter Wijngaards via nsd-users wrote: > >> The RC2 is here to update the default for DNS Cookies. It is now off to >> stop wrong behaviour in mixed server deployments. > > Wrong? What was wrong? Isn't it RFC compliant? Does this only affect > anycast setups? > > Paul > > _______________________________________________ > nsd-users mailing list > nsd-users at lists.nlnetlabs.nl > https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users
On Thu, 7 Oct 2021, Wouter Wijngaards via nsd-users wrote:> Cookies are a problem for when there are several servers.You mean anycast?> Those servers > have to coordinate the cookie responses, and there are configuration > options for that. But the default on was causing the trouble by default, > instead of a more cautious default off, that does not cause the problem > all of a sudden after an upgrade.understood. But of course now we keep having the problem of needing to answer to spoofed requests and being part of DDoS attacks :) So I am trying balance the issues with the option. I'm more tempted to leave it enabled to add DDoS protection, and assume server operators of anycast clouds have their process in place for doing proper upgrades of all their servers at the same time, and not run OS default configs. So to me, it still seems better to enable this per default. Paul