Subject: [DNSOP] Using NSEC authoritatively - cutting down on NXD requests...

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Oct 2015 13:53:51 -0400

Hi all,

I wanted to mention a document that Geoff and I wrote a few weeks back:

draft-wkumari-dnsop-cheese-shop-00 - "Believing NSEC records in the
DNS root" - https://datatracker.ietf.org/doc/draft-wkumari-dnsop-cheese-shop/

Basically this is a simplification of Kazunori Fujiwara's
I-D.fujiwara-dnsop-nsec-aggressiveuse, restricted in scope to only be
validated NSEC, and only for the root. Being simpler, we believe that
cheese-shop allows for simpler implementation and gaining experience.
We complement, not compete with nsec-aggressiveuse.

The root has some nice properties -- we understand a lot about the
structure of the zone (e.g no wildcards, no cname's), and it is known
to get a bunch of junk queries.
Using NSEC for negative caching is known to work well in this case; we
can expand the scope of the document sometime after discussions...

W

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

---

From: Shane Kerr <[email-masked]>
Date: Fri, 16 Oct 2015 19:52:19 +0200

Warren,

On Thu, 15 Oct 2015 13:53:51 -0400
> can expand the scope of the document sometime after discussions...

I like Fujiwara's idea, so I favor anything that helps move it along. I
tend to think that it would be nice to solve the general case, but I
understand your motivation here. 

I can see the issue with wildcards - a resolver has to do a separate
query to confirm that there are no wildcards for a zone, and then
presumably caching needs to take the minimum of the wildcard NSEC TTL
and any other NSEC TTL. There is a win in the root because as you point
out there is no wildcard.

I don't see the issue with CNAME though. What is that?

Cheers,

--
Shane

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 24 Oct 2015 21:17:55 +0200

On Thu, Oct 15, 2015 at 01:53:51PM -0400,
 Warren Kumari <[email-masked]> wrote 
 a message of 33 lines which said:

> I-D.fujiwara-dnsop-nsec-aggressiveuse,

For me, it has the same problem as fujiwara-dnsop-nsec-aggressiveuse:
it is a DNSSEC-specific solution, while we already have a generic
solution, described in section 3 of vixie-dnsext-resimprove (mentioned
by Shumon Huque in
<http://mailarchive.ietf.org/arch/msg/dnsop/Q3FpcQONPy2SApucDDUYXiXnVJc>)

---

From: Bob Harold <[email-masked]>
Date: Mon, 26 Oct 2015 09:36:10 -0400

On Sat, Oct 24, 2015 at 3:17 PM, Stephane Bortzmeyer <[email-masked]>
wrote:

> > DNS root" -
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-cheese-shop/
> >
> It looks to me like they address two separate cases:
vixie-dnsext-resimprove  addresses the case where a single name 'b.example'
and everything below it do not exist, found by a query for 'b.example'.
That's as much as we can determine without DNSSEC.  And it breaks if a DNS
server returns NXDOMAIN for ENT's.
fujiwara-dnsop-nsec-aggressiveuse addresses the case where 'a.example'
exists, but the range 'bxxxx.example' thru 'gyyyy.example' do not exist,
found by a single query for anything in the range.  But it only works with
DNSSEC signed zones.

-- 
Bob Harold

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 27 Oct 2015 09:16:26 +0100

On Mon, Oct 26, 2015 at 09:36:10AM -0400,
 Bob Harold <[email-masked]> wrote 
 a message of 80 lines which said:

> vixie-dnsext-resimprove addresses the case where a single name
> 'b.example' and everything below it do not exist, found by a query
> for 'b.example'.

Or a query for something.b.example, which received a NXDOMAIN reply,
together with a SOA of example, no?

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Oct 2015 02:09:48 -0700

> together with a SOA of example, no?

no. it's a nice idea, but not every label sits on a zone boundary. so if the 
qname is for a.b.example and the query was sent to the authority for example 
and an nxdomain comes back with an soa for example, you still don't know 
whether b.example exists. nxdomain is about the qname, or the name at the end 
of a cname chain reached through the qname.

-- 
P Vixie