Subject: Re: NSEC3 Issue 18: signalling complete NSEC3 chains

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 07 Jul 2006 10:27:46 -0400

At 13:33 24/06/2006, Ben Laurie wrote:
>David Blacka wrote:

<snip>

> > Note that solution #4 could be thought of as a special case of the NSEC3
> > hash calculation function rather than as a special NSEC3 RR.
> >
> > Solutions 2, 3, and 4 all have the property of having something that may
> > be directly looked up by the authoritative server (either primary or
> > secondary), which is known to be efficient.
>
>If we're going to change things, then I prefer 2.
>
>3 & 4 both complicate the logic for handling NSEC3 records, for no
>obvious reason (to save a type code? really?).

<No hat on>
I agree with Ben that 2 sounds as the cleanest solution,
but I'm partial to liking #4.

#1 (having zone parameters at a random name) is unacceptable from
both performance and consistency point of view.

There are two uses for this information:
Authorative server configuring its NSEC3 behavior, this is both to set
the NSEC3 lookup parameters. The case that I keep harping on are
nameservers that do not "load" the zone but look up in a database
for answers. For these servers it the location of NSEC3 parameters must
be known. The alternative is to FIX the parameters for each zone/all zones,
but that is counters the spirit of NSEC3 design.

Also keep in mind that a paranoid DNSSEC validator may want to check that
the NSEC3 record it received is from the CURRENT NSEC3 chain.
If this use is encouraged then zones should lower the TTL on the marker
record before switch to have them flush out of caches faster.

         Olafur

--
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: Ben Laurie <[email-masked]>
Date: Thu, 20 Jul 2006 10:59:29 +0100

> but I'm partial to liking #4.

If you want #4 rather than #2 then I suspect you're going to have to do
better than "partial to liking".

> the NSEC3 record it received is from the CURRENT NSEC3 chain.

And what if it isn't? How's it going to get a more recent one?

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff