Subject: Re: NSEC3-01 - more wildcard nits

From: Alex Bligh <[email-masked]>
Date: Fri, 01 Apr 2005 00:35:41 +0100

--On 31 March 2005 22:09 +0000 Paul Vixie <[email-masked]> wrote:

>> Modifying the search algorithm has caught my attention.  This would be
>> very significant.
>
> i missed this when i reviewed NSEC3.  it would be very significant, and
> must not be done this way.  if you want a new namespace for dnssec
> metadata, ask michael graff or myself about slabs, but don't add new
> search rules that are based on rrtypes or any other in-band protocol
> element.

If you can 'guarantee' the owner RR would not be queried for anyway
(i.e. other than as a hash), you don't have a problem, because it
only affects (AFAICS) queries for the hash of an ownername where
there is a wildcard.

So if noone ever queried for records beginning (say) __NSEC3__ you'd be OK
if you prepended all the hashed owner names with that. I (mostly) jokingly
suggested a while back suggested appending ".*" to each NSEC3 hash to form
the RR on the basis that noone's going to query for that as the behaviour
is currently undefined :-)

I too would like to avoid changing the search algorithm. I think it
would probably be preferable to pick a suffix or prefix and say "if you
make your zone using NSEC3 then you can't use this prefix/suffix" unless
there is some cleverer method.

Alex

--
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: Jim Reid <[email-masked]>
Date: Fri, 01 Apr 2005 11:24:38 +0100

>>>>> "Alex" == Alex Bligh <[email-masked]> writes:

    Alex> Nit: Some NSEC* adopters may be happy to do NSEC
    Alex> initially.
    Alex> ...... but the common theme here is they'll all want
    Alex> to get rid of NSEC support eventually.

They may *want* to. Whether they can is another matter.

Our DNS zoo has many strange beasts. Some of those are dinosaurs that
query for long deprecated RR types, can't do negative cacheing, don't
understand ENDS0, misbehave when they see an unknown (to them) RRtype,
etc, etc. Getting those beasties upgraded or killed off isn't always
possible even if there was a protocol police that had the power and
resources to do that. Once NSEC is in use it will be very hard to get
that particular genie back in its bottle.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 01 Apr 2005 11:29:32 +0100

> that particular genie back in its bottle.

Agree, but those who start using (i.e. publishing) NSEC then, then
add NSEC*, then at some stage stop using NSEC, are in no worse position
than those who who never used NSEC and went straight to NSEC*.

Alex

---

From: [email-masked] (Geoffrey Sisson)
Date: Fri, 1 Apr 2005 11:52:18 +0100 (BST)

Alex Bligh <[email-masked]> writes:

> NSEC3 with an identity hash algorithm would fulfil that goal. We already
> have other reasons to do that (see my post re long names). (that doesn't
> mean they *can't* coexist of course, I'm just not yet sure they need to).

I should have qualified that as "NSEC3 as per the current draft".

NSEC has other advantages: better transparency (easier to troubleshoot)
and (probably) more compact replies.  But I agree that the main
advantage goes away if something like the identity hash algorithm can
be made to work with a hash-based NSEC*.

Regards

Geoff