At Tue, 16 Aug 2005 16:18:25 -0400, David Blacka wrote:
> On Aug 16, 2005, at 3:46 PM, Rob Austein wrote:
>
> > ... That is, can we just state that wildcards, if present, must be
> > signed, and that an opt-foo NSEC3 means by definition that there
> > is no wildcard in that range?
>
> It already says that. (Discounting wildcard NS records

4.1.1 says SHOULD, not MUST.

> This is not because the wildcard RR set is not signed or not in the
> NSEC{3} chain -- it is. This is because you cannot quite prove
> rcode=3 when the covering NSEC is opt-in, so why bother *also*
> proving that there is no wildcard (which, I repeat, you can do)?
>
> Maybe *I'm* missing something obvious, but what is this "wildcard
> interaction problem", really?

It's a consistancy thing, I dunno how much it matters. As I think I
understand it, the opt-foo model is signed records rather than signed
zones. One way of looking at this is that it's the same model as
DNSSECbis but certain portions of a zone are flagged as dropping out,
leaving a signed subset of the zone. So a "no such name in zone"
proof turns into a "no such signed name in zone" proof, which (to my
mind, anyway) includes "no signed covering wildcard in zone."

> And, honestly, section 4.1.3 could be changed to require that rcode=3
> responses include the NSEC record that proves no wildcard exists
> without hurting anything. I'm just not sure that it buys you
> anything, so why should the validator have to do the work? OTOH, I
> think I can be easily convinced to make this change.

I'm not sure it buys anything either, and will admit that there's a
case to be made here either way. On the one hand, I think that
including the NSEC/NSEC3 is more consistant (and DNSSEC in general is
already umpty-three levels deep in baroque fixes to our previous
cleverness, opt-foo brings it to umpty-four, so retaining what little
consistancy remains in this house of cards seems good to me...); on
the other hand, omitting the NSEC/NSEC3 saves some bandwidth. Dunno.

In any case: upon further analysis (or, if you prefer, upon swapping
in foggy memories), the answer to my original question is that my
proposal above doesn't suffice, because it doesn't handle an unsigned
positive answer that masks a signed wildcard. Only fix I see for that
would be changing SHOULD in 4.1.1 to MUST.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: