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

[Edward Lewis <[e-mail]>]

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, [e-mail] wrote:
>folks, i think florian's got a valid point here.
>
>>  From: Florian Weimer <[e-mail]>
>>  To: [e-mail]
>>  Date: Mon, 17 Apr 2006 11:16:26 +0200
>>  Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing
>>  	name
>>
>>  * 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, matching the
>>  draft-ietf-dnsext-wcard-clarify.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                [phone]
NeuStar

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

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