Hi Shane On Mon, Nov 28, 2016 at 02:53:49PM +0100, Shane Kerr wrote: > John, > > At 2016-11-27 15:18:18 -0000 > "John Levine" <jo...@taugh.com> wrote: > > > >What are the consequences of the authoritiative server returning > > >synthesized unsigned NSEC3 RRs upon being signalled by the resolver > > >using an EDNS option? > > > > A message to the world that there is no need to sign your zones, > > because we will solve your problems by magic. Please, let's not > > go there. > > Well, to be fair, such a bloom-filter based approach helps not only > people who have unsigned zones but also zones using NSEC3 opt-out and > people using minimally-covering NSEC records (RFC 4470) - which I think > CloudFlare is using some variant of. > > Perhaps the bloom-filter idea is something that should be explored > after all (although I admit I don't see the relation to the unsigned > NSEC3 approach)?
There is no relation between bloom filters and an unsigned NSEC3
approach, except that both are different ways of mitigating these water
torture attacks.
We have been putting in some knobs into the BIND resolver, but these
have limits of effectiveness. Nothing is as effective as a way for the
resolver to say that a name or <name,type> doesn't exist. From Warren's
presentations at the ICANN meeting and also during the IETF meeting, it
seemed that NSEC3 aggressive use was very effective for the root zone on
Google public DNS. Their entire query rate (including nonsense) to the
root zone dropped to below 100 qps IIRC.
Because NSEC3 aggressive use works well, and extending it to be used in
unsigned zones is similar in implementation, it seemed like an easy win
for unsigned zones too.
I was hoping for technical comments on the problems with using unsigned
NSEC3, but the discussion seems to have taken a philosophical course.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
