Subject: [DNSOP] NSEC3 aggressive use for unsigned zones

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 27 Nov 2016 16:25:21 +0530

draft-ietf-dnsop-nsec-aggressiveuse works for stopping random sub-domain
attacks for signed zones.

The problem exists for unsigned zones and different approaches have been
proposed:

- Bloom filtering queries (e.g. https://github.com/hdais/unbound-bloomfilter)
- Bloom filter bitfield in RRs (e.g. https://tools.ietf.org/html/draft-bellovin-dnsext-bloomfilt-00)

What are the consequences of the authoritiative server returning
synthesized unsigned NSEC3 RRs upon being signalled by the resolver
using an EDNS option? This could be spoofed by a man-in-the-middle, but
so can every unsigned answer.

		Mukund

---

From: "John Levine" <[email-masked]>
Date: 27 Nov 2016 15:18:18 -0000

>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.

R's,
John

---

From: Shane Kerr <[email-masked]>
Date: Mon, 28 Nov 2016 14:53:49 +0100

John,

At 2016-11-27 15:18:18 -0000

> because we will solve your problems by magic.  Please, let's not

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)?

Cheers,

--
Shane

---

From: "John R Levine" <[email-masked]>
Date: 28 Nov 2016 09:29:06 -0500

> after all (although I admit I don't see the relation to the unsigned

I agree they might be interesting, but I'd like to keep them far away from 
pseudo-DNSSEC.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 29 Nov 2016 22:56:06 +0530

Hi Shane

> after all (although I admit I don't see the relation to the unsigned

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