Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name

From: [email-masked]
Date: Mon, 17 Apr 2006 14:11:28 +0000

folks, i think florian's got a valid point here.

(i'm not cross-posting, i'm changing mailing lists for this thread.  i'll post
a summary back to dns-operations@ when namedroppers@ is done chewing on this.)

re:

> From: Florian Weimer <[email-masked]>
> To: [email-masked]
> Date: Mon, 17 Apr 2006 11:16:26 +0200
> Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing
> 	name
> Sender: [email-masked]
> 
> * Paul Vixie:
> 
> > to me, b.example.net exists because that's what we decided for dnssec,
> 
> Post-RFC-4035, I assume?  Because RFC 4035 says, in section 3.1.32:
> 
> | Note that this form of response includes cases in which SNAME
> | corresponds to an empty non-terminal name within the zone (a name
> | that is not the owner name for any RRset but that is the parent name
> | of one or more RRsets).
> 
> This also follows from the prohibition of NSEC generation for empty
> non-terminals (section 2.3, "An NSEC record (and its associated RRSIG
> RRset) MUST NOT be the only RRset at any particular owner name."), as
> you would need such an NSEC RR for responding with NODATA.  This means
> that the draft-ietf-dnsext-wcard-clarify (thanks Peter and Edward!) is
> in conflict with DNSSEC (as a simple update of the DNSSEC spec is not
> possible).
> 
> Ah, draft-ietf-dnsext-nsec3 handles this case differently, maching the
> draft-ietf-dnsext-wcard-clarify.
> _______________________________________________
> dns-operations mailing list
> [email-masked]
> http://lists.oarci.net/mailman/listinfo/dns-operations

--
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: Edward Lewis <[email-masked]>
Date: Mon, 17 Apr 2006 10:47:46 -0400

I don't get the point.  (I need clarification.)

I will say I don't understand the last paragraph of 3.1.3.2 in 4035 
(as quoted by Florian).  When it comes to name errors, empty 
non-terminals need not apply.

NSEC3 breaks rules.  It has to.  The reason is that when the design 
choices were make for NSEC (nee NXT), a set of rules were included 
assuming NXT and making NXR more reasonable.  Deviating from NSEC 
into NSEC3 means upending design decisions and rules set forth.

I don't see the conflict between DNSSEC and the wild card document. 
Maybe this is the missed point:

You don't need an NSEC at a name to prove it has no RRsets.

example.     NSEC a.example. soa ns nsec dnskey rrsig
a.example.   NSEC a.b.example. a txt nsec rrsig
a.b.example. NSEC c.example. a txt nsec rrsig
c.example.   NSEC example. ns nsed rrsig

These records indicate that there are 5 names in the zone, 4 of which 
have records. "b.example." does not have any records, not even an 
NSEC.  A query for "b.example. A" would get 0 answer records, and 
"a.example.   NSEC a.b.example. a txt nsec rrsig" in the authority 
section.  The verifier can infer that b.example exists (since 
a.b.example exists) and that by "pointing" past b.example, the NSEC 
says there is nothing to see at b.example.

At 14:11 +0000 4/17/06, [email-masked] wrote:
>>  Ah, draft-ietf-dnsext-nsec3 handles this case differently, matching the

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Rob Austein <[email-masked]>
Date: Mon, 17 Apr 2006 13:38:45 -0400

> non-terminals need not apply.

The text in question:

   Note that this form of response includes cases in which SNAME
   corresponds to an empty non-terminal name within the zone (a name
   that is not the owner name for any RRset but that is the parent name
   of one or more RRsets).

DNSSECbis talks about existance and non-existance of -RRsets-; it does
-not- talk about existance or nonexistance of -names-.  The first
paragraph of 3.1.3.2 describe the case covered by this kind of
response: "the zone does not contain any RRsets matching <SNAME,
SCLASS> either exactly or via wildcard name expansion".

Ie, for the purposes described in 3.1.3.2, an empty node is an empty
node ("name error") whether it's terminal or not.  The proof described
in 3.1.3.2 applies regardless of the RCODE.  DNSSECbis does not cover
the RCODE, that'd have to be covered by a channel security mechanism.

This bugaboo about whether a name exists when there are no RRsets
attached to it has been a source of confusion for twenty years.
DNSSECbis takes pains to avoid it.  Please don't reintroduce it. :)

---

From: Roy Arends <[email-masked]>
Date: Mon, 17 Apr 2006 20:30:15 +0200

> > draft-ietf-dnsext-wcard-clarify.

Yes. During the Dallas IETF dnsext wg meeting I gave a presentation 
(rfc4035 omissions) on this exact point.

I noted that rfc4035's statement (3.1.3.2) is wrong. 

One example why this is wrong is that a resolver implementing negative 
caching will cease to resolve a.b.example if it previously received and 
cached a name error for the empty non-terminal b.example.

regards,

Roy

---

From: Roy Arends <[email-masked]>
Date: Mon, 17 Apr 2006 20:37:46 +0200

> SCLASS> either exactly or via wildcard name expansion".

If we're about to re-issue the term NAME ERROR to mean 'non-existance of 
RRsets" we should introduce a new rcode. Otherwise this is just confusing. 

> DNSSECbis takes pains to avoid it.  Please don't reintroduce it. :)

This confuses even more. 

So, what do you suggest the rcode (yeah yeah unsigned) is on the specific 
response that is covered by rfc 4035 3.1.3.2 ?

Roy

---

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Apr 2006 14:46:04 -0400

>the RCODE, that'd have to be covered by a channel security mechanism.

My confusion is from the title of the section:
     "3.1.3.2.  Including NSEC RRs: Name Error Response"

When I read that I assume the section is all about situations with a 
return code of "name error."  That's why I say that the quoted 
paragraph is oddly placed.

>The quoted paragraph:

---

From: Rob Austein <[email-masked]>
Date: Mon, 17 Apr 2006 15:11:42 -0400

> RRsets" we should introduce a new rcode. Otherwise this is just confusing. 

None of the other three cases in 3.1.3 exactly corresponds to an
RCODE.  Why do you expect that this one will?

People, please -read- the entire section (3.1.3 and its children).
The cases (all four of them) are spelled out, and nowhere does it say
that -any- of this corresponds to any particular RCODE.

I guess some text about this (that these cases do not correspond to
RCODEs) needs to go into the bis clarification doc, since apparently
people are reading this as isolated paragraphs without checking the
immediately preceding definitions.

> response that is covered by rfc 4035 3.1.3.2 ?

RCODE zero or three, depending on whether the name is an empty
nonterminal or not, not that a validating resolver should care.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Apr 2006 15:35:30 -0400

>that -any- of this corresponds to any particular RCODE.

After doing that, I would conclude the 3.1.3 needs more work.  Not in 
content, but in language.  At least make "Name Error" mean the same 
thing in RFC 1035/1034 as in RFC 4035.

---

From: Roy Arends <[email-masked]>
Date: Mon, 17 Apr 2006 21:48:33 +0200

> RCODE.  Why do you expect that this one will?

Because NAME ERROR (in the 3.1.3.2 section title) is an explicit rcode. 

> that -any- of this corresponds to any particular RCODE.

Confusion happens when a document redefines (or re-uses) the term NAME 
ERROR, but apparently not talking about the rcode.....
 
> immediately preceding definitions.

This is a wrong assumption.

Wrt including NSEC in a response I expect that the sections under 3.1.3 
would cover all different response types including the NOERROR/NODATA 
response for an empty non-terminal. This NOERROR/NODATA response type is 
under the section that deals with (some definition of) NAME ERROR.

> nonterminal or not, not that a validating resolver should care.

The validating resolver might not care. But something talking to it might 
care. 

Roy

---

From: Rob Austein <[email-masked]>
Date: Mon, 17 Apr 2006 16:15:25 -0400

> thing in RFC 1035/1034 as in RFC 4035.

Well, the conditions in 3.1.3 don't exactly map to anything from RFC
1035.  As Roy may recall, at one point the DNSSECbis drafts had made
up terms for all of these, for precisely this reason.  We changed to
the current wording because the made up terms were unreadable.

So, while accepting your criticism, I'd phrase it a bit differently.
Serious question: what would you suggest as names for the four
DNSSECbis-specific conditions described in 3.1.3 and its children?

---

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Apr 2006 16:47:23 -0400

>DNSSECbis-specific conditions described in 3.1.3 and its children?

I understand that desire to divorce the notion of names existence 
from RRset existence because of how negative answers work in DNSSEC, 
but I think you can't.  Well, completely divorce them, that is.

My personal way to classify the cases is:

1) For return code of "name error" - NSECs are needed proving that 
neither the sought name nor a source of synthesis exists.

2) For an answer count of 0 - NSECs are needed proving that either 
the sought name exists without a matching set or the triple of the 
sought name does not exist, a source of synthesis does, and there is 
no matching set (from which to synthesize).

3) For synthesized answers - NSECs are needed proving that the sought 
name does not exist but that there is a source of synthesis with a 
matching set (from which to synthesize).

I have three cases because the "answer count of 0" includes two of 
the original four cases.  (Mind you, this is all textual, the 
underlying content is okay.)

As DNSSEC is an extension to the base protocol, if we can show the 
extensions as building upon the response messages, we'll likely have 
a cleaner description.  (Granted, that's a hypothetical statement.) 
Likely - because we may discover hidden inconsistencies in the base 
specification as in the conflict of an NS RRset at a source of 
synthesis.

Of course, this is one way to answer this.  Maybe tomorrow I'd have 
answered differently.  The perspective I've adopted is from the 
protocol's architecture.  It might be better to describe this from 
the protocol server's state machine.  But that might be too obtuse as 
none of the rest of the documents use that perspective.

---

From: Rob Austein <[email-masked]>
Date: Mon, 17 Apr 2006 17:10:27 -0400

The organization we used in RFC 4035 is based on grouping the cases
that return identical NSEC attestations together.  I may be missing
something, but Ed's three case grouping doesn't appear to do that,
thus to my mind is at least as confusing as the current text.  Note
that even before DNSSEC we were well down the path of protocol that
had to be deduced from the packet rather than just being read off
cleanly (see, for example, the gyrations that Mark had to go through
in classifying RCODE 3 responses in RFC 2308).

That said, Roy's recent work on null-hash NSEC3 suggests that we may
want to rethink the explanation of the attestations we're supplying
anyway.  If I understand Roy's work correctly, his claim is that, in
one or more of the cases where RFC 4035 says there are two things we
have to prove, there are really three things we have to prove, and
it's just an accident of ordering that always lets us prove all three
things with at most two NSEC RRs.  Might be worth thinking through how
we'd like to explain all this for the bis-updates document.