Two more NSEC++ proposals

[Samuel Weiler <weiler@tislabs.com>]

First, these are incomplete -- many details, like how to expose empty
non-terminals and details of hash parameterization, are not addressed.
These may also be very bad ideas for a number of reasons.  You've been
warned.

On Wed, 30 Mar 2005, Alex Bligh wrote:

> I think without hash truncation, "long" names just won't work.

This is true so long as one assumes that the hashes have to be
expressed as part of domain names (i.e. the owner names of NSEC++
RRs).  What if one instead moved both (lists of) hashes into the
NSEC++ RDATA and somehow encoded them as something other than domain
names (or using an alternate domain name encoding that avoids the
length limits, remembering that we have full control over the RDATA):

      ownername NSEC8 start-hash end-hash bitmap

This still tells a resolver that any name whose hash falls between the
values in this NSEC8 does not exist in this zone.  The question then
becomes: what does one use as an ownername?

Proposal 1:

   Anything.  Make up (truly) random names in the zone.

      bert.example.com  NSEC8  hash1  hash2  bitmap
      hates.example.com NSEC8  hash2  hash3  bitmap
      spam.example.com  NSEC8  hash3  hash1  bitmap

   There's still a potential recursion problem (the NSEC8s prove
   themselves not to exist), but the NSEC3 discussions have led us to
   think this won't have any real effect.  Also, the authoritative
   server needs to index the NSEC8s by hash values, not ownernames.

   One could also create a delegation within the zone to keep these
   names in one place:

      foo.nsec.example.com NSEC8  hash1  hash2  bitmap
      bar.nsec.example.com NSEC8  hash2  hash3  bitmap
      baz.nsec.example.com NSEC8  hash3  hash1  bitmap

Proposal 2:

   Since the ownernames of these NSEC8's don't matter, why not just
   stick them all at the same name?  Even the apex?  Having them be
   part of one big RRset with one RRSIG just won't scale.  Instead,
   treat each NSEC8 as a separate possible NSEC8 RRset for the apex.
   The authoritative server keeps a table of these and selects the
   right one, along with its RRSIG, whenever needed.  Even better,
   have each NSEC8 RRset also contain the NSEC8 RR proving that no
   wildcard exists.

   Using the example above, there would be three possible NSEC8 RRsets
   at the apex, and the server would select among them on demand.
   Assuming that the wildcard hashes between hash2 and hash3, these
   RRsets would be:

      example.com NSEC8  hash1  hash2  bitmap (proves no exact)
      example.com NSEC8  hash2  hash3  bitmap (proves no wildcard)

      example.com NSEC8  hash2  hash3  bitmap (proves both)

      example.com NSEC8  hash2  hash3  bitmap (proves no wildcard)
      example.com NSEC8  hash3  hash1  bitmap (proves no exact)

Running for cover,

-- Sam

--
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: <http://ops.ietf.org/lists/namedroppers/>