Subject: NSEC design question wrt synthesized RCODE 3 (NXDOMAIN)

From: Paul Vixie <[email-masked]>
Date: Sun, 29 Jun 2008 16:21:05 +0000

i was largely uninvolved in the discussions which led to the NXT RR, thus
my ignorance, and thus this question.  why are initiators prohibited from
using a cached NSEC to synthesize RCODE 3?  here's some context.

first, DLV.

in DLV, we treat the DLV initiator as a DNS application or consumer, not
as a DNS initiator in its own right.  therefore a cached NSEC is capable
of causing the DLV initiator to suppress certain queries, which in the case
of DLV actually means, suppressing most queries.  but no RCODE 3 is sent
on any wire, so we're within the letter of the prohibition against using
a cached NSEC to synthesize an RCODE 3.

second, root name service.

many responses sent by root name servers are negative, to questions having
more than one label (e.g., EXCHANGE.CORPORATE or WWW.INTERNAL.CORPORATE).
the resulting RCODE 3 is somehat ambiguous, since it refers to the question
name in its entirety, whereas the thing that doesn't exist is the TLD.  if
we had a way to signal that the TLD doesn't exist, and get that cached, we
might be able to avoid some number of future questions at/below that TLD.

third, DNSSEC motivation.

many have called DNSSEC "a solution searching for its problem" and it's often
said that the cost and complexity it demands are unwarranted by the risks it
protects against or the benefits it brings.  some of us feel that protecting
the infrastructure itself would be motive enough, others feel that making it
possible for new applications to depend on authenticity from DNS would also
be motive enough.

so:

how cool would it be if signing a zone, including the root zone, allowed
one to usefully express the nonexistence of a slice of the namespace larger
than the question name, and if turning on validation in a recursive DNS meant
a drop in upstream bandwidth due to cached NSEC, in spite of the rise in
upstream bandwidth due to all the new cryptoblobs you'd be receiving?

thus my question.  why do we prohibit the use of a cached NSEC RR for
synthesizing RCODE 3 responses?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Blacka, David" <[email-masked]>
Date: Sun, 29 Jun 2008 15:43:25 -0400

> using a cached NSEC to synthesize RCODE 3?  here's some context.
...
> synthesizing RCODE 3 responses?

I generally recall discussion of this in the 2002/2003 timeframe.  A  
little research (and I do mean little) yields this as the earliest  
thread on the subject that I could find:

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02127.html

but, at that point, the language prohibiting this sort of reuse of  
NSEC/NXT records was already in the dnssec-bis-protocols draft.  One  
of the dnssec-bis document editors might recall the origins of the  
language.

My personal recollection is that this language exists basically to  
satisfy the "principle of least surprise".  Surprise on the part of  
the zone operator when a new name added to the zone isn't immediately  
visible, and surprise on the part of the end user when a name doesn't  
resolve for them, but it works fine for their neighbor.

Also, I think the prohibition has the effect of simplifying the  
protocol.

--
David Blacka                          <[email-masked]>
Sr. Engineer                   Platform Product Development

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Jun 2008 08:50:49 +1000

> using a cached NSEC to synthesize RCODE 3?  here's some context.

	Conservitism.  There isn't a technical reason.  Just a fear
	that it would be badly implemented.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]