Subject: Re: NSEC3-01 - more wildcard nits

From: Danny Mayer <[email-masked]>
Date: Wed, 30 Mar 2005 21:25:27 -0500

At 10:37 AM 3/30/2005, Alex Bligh wrote:
>I think this has been brought up before, but not made the draft.
>
>Imagine a zone
>
>$ORIGIN example.com.
>example.com.            IN      SOA     ...
>                         IN      NS      ...
>                         IN      NS      ...
>www                     IN      A       1.2.3.4
>*                       IN      MX      2.3.4.5
>H(www.example.com.)     IN      NSEC3 ... H(example.com.) A RRSIG
>H(example.com.) IN      NSEC3 ... H(*.example.com.) SOA NS RRSIG
>H(*.example.com)        IN      NSEC3 ... H(www.example.com.) MX RRSIG

I assume you were tired when you wrote this. I think you really meant to write:
$ORIGIN example.com.
example.com.            IN      SOA     ...
                         IN      NS      ...
                         IN      NS      ...
www                     IN      A       1.2.3.4
*                       IN      MX      10 mail
mail                    IN      A       2.3.4.5
H(www.example.com.)     IN      NSEC3 ... H(example.com.) A RRSIG
H(example.com.) IN      NSEC3 ... H(*.example.com.) SOA NS RRSIG
H(*.example.com)        IN      NSEC3 ... H(www.example.com.) MX RRSIG

Danny

--
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: Edward Lewis <[email-masked]>
Date: Thu, 31 Mar 2005 10:04:38 -0500

At 16:37 +0100 3/30/05, Alex Bligh wrote:

>That's because the draft should (but as far as I can see does not)
>modify the search algorithm such that NSEC3 records are ignored for
>all searches other than QTYPE=NSEC3.

Modifying the search algorithm has caught my attention.  This would 
be very significant.

This is an issue related to the "creation" of new names - the hashes 
- in the zone.  What I am thinking is that zone-obfuscating authentic 
denial approaches need to consider the process has taking place in 
the rendering of a negative answer reply and not taking place in the 
search process.

One principle of the search algorithm (referencing 1034/4.3.2) is 
that it first pays attention only to the names involved.  Once 
settling on a place from which to obtain an answer, the next phase is 
to match on type.  This makes me cringe when I think of treating 
names as special because they have been created as part of 
authenticated denial.  E.g., does a hash name "block" a wildcard?

I have been considering treating the hashes of names as functions of 
the data, not the data themselves.  I.e., the hash of a name would 
not be in the tree.  (Note, if the hash of one name is equivalent to 
another name, so what?  The other name is in the tree, the hash is 
still a hash.)  This would avoid having to alter the search algorithm 
up until a negative answer is rendered into a message.  This is not a 
change to the search algorithm but a change to the rendering of the 
answer, something I find less troubling.

Nonetheless, such a change is considerable.  It's a change in how it 
is said, not what is said.

The problem with treating the hashes as pre-computed non-tree 
entities is that we then need to transfer the hashes from the master 
to slaves.  Perhaps hashes will look like other names in AXFR and 
zone file format, but be treated differently upon the loading process.

An implementation might choose to place hashed in the same database 
as the zone data.  In this case, the implementation would have to 
treat hashes differently, modifying its implementation of the search 
algorithm.  Another implementation could choose to keep the hashes in 
a separate place, using the "normal" search algorithm and referring 
to the hash list only when employing hash-style authenticated denial. 
Either case, the concepts in 1034/4.3.2 are upheld - recall that the 
text there is just a "suggested" way of carrying out the search.

PS I still have my doubts about finding a successor to NSEC.  A flag 
day would be needed to erase existing NSEC from the DNS and be 
seamless.  Even if the thought is that "NSEC-era" verifiers will be 
upgraded to overcome this, that's the flag day.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 31 Mar 2005 20:40:50 -0500

At 0:35 +0100 4/1/05, Alex Bligh wrote:
>--On 31 March 2005 10:04 -0500 Edward Lewis <[email-masked]> wrote:
>
>>
>>  PS I still have my doubts about finding a successor to NSEC.  A flag day
>>  would be needed to erase existing NSEC from the DNS and be seamless.
>>  Even if the thought is that "NSEC-era" verifiers will be upgraded to
>>  overcome this, that's the flag day.
>
>Why does existing NSEC data need to be "erased from the DNS"? Why can
>it not continue living there? Surely if we do the rollover suggested
>several months ago, then we can leave NSEC data in, people may wish
>to publish zones with both in (to support old resolvers if they aren't
>worried about enumeration), and those new converts who adopt NSEC3
>only will appear to have insecure zones to "old" (i.e. DNSSECbis)
>resolvers.
>
>Sure, zone publishers will need to pick a day when they don't want to
>support old NSEC anymore. But why an internet wide flag day?

Fair 'nuf question.  This is what I'm thinking.

The problem I can't get over is that I presume that admins using 
NSEC* are the ones that don't want to use NSEC.  It's not like NSEC* 
adopters will be happy to also do NSEC.  Although the two do not 
interfere, the reason for NSEC* is that NSEC shouldn't exist.

Assuming there will be NSEC-era validators out there before NSEC* 
gets rolling, once there are NSEC* zones out there, these validators 
will see the NSEC* zones as broken because there are no NSEC records 
there.  All of the NSEC-era validators would have to be replaced - 
that's the flag day or event - because in the meantime, the "extra 
secure" NSEC* zones may just be cut off if these zones are judged to 
be broken.

Maybe its only negative answers that will be broken.  Questions remain.