Subject: Re: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms

From: David Blacka <[email-masked]>
Date: Tue, 6 Jun 2006 11:26:15 -0400

On Jun 6, 2006, at 10:00 AM, Scott Rose wrote:

> Personally, I think Approach 1 may be best.  It would be consistent in
> dealing with everything - name errors, no error/no data, wildcards and
> unsigned delegations.

I think approach 1 is best, too, although I disagree with how it is  
stated.

If a nameserver refuses to load a zone, why would it return RCODE=2  
in responses that would fall under that zone?  As far as responses  
go, it should behave the same for all zones that it isn't  
authoritative for.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

--
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: "Scott Rose" <[email-masked]>
Date: Tue, 6 Jun 2006 10:00:06 -0400

I'm not tied to this solution though, so if the consensus is 2, 3, or some
other choice, I won't object.

Scott
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy Arends
> Sent: Wednesday, May 31, 2006 11:33 AM
> To: [email-masked]
> Subject: NSEC3 Issue 20: Server behavior wrt unknown hash algorithms
>
>
> Issue:
>
> Server behavior with regards to unknown hash algorithms
>
> Discussion:
>
> An NSEC3 capable server might, on load or during a zone transfer,
> encounter an NSEC3 with an unknown hash algorithm. As it is unable to
> determine which NSEC3 to send back in a response, the server can't fully
> provide the service intended.
>
> Approach 1)
> Refuse to load/accept the zone. Return rcode 2 on requests
> related to this
> zone.
>
> Approach 2)
> load/accept the zone with a warning. Return rcode 2 where the responses
> normally would contain NSEC3 records. This allows the server to provide
> service for DO=0 requests, and for DO=1 where the responses do
> not contain
> NSEC3's
>
> Approach 3)
> Load/accept the zone with a warning. Return rcode 2 except for
> qtype=axfr/ixfr. This allows the server to provide service for
> secondaries.
>
> This is not an exhaustive list.
>
> Resolution:
> Default approach has yet to be set.
>
> Regards,
>
> Roy
>
> --

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 6 Jun 2006 11:49:15 -0400

> [mailto:[email-masked]]On Behalf Of David Blacka

> go, it should behave the same for all zones that it isn't

My guess that part was for ixfr/axfr.  How secondaries should act when
getting a zone with unknown hash algos in the NSEC3 RRs (after a hash algo
rollover I assume).  At least that was my understanding.

Scott

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 06 Jun 2006 12:14:26 -0400

<no-hat>
Solution #1 is the only sane solution, as it forces a zone owner to make
sure all server serving the zone support the new algorithm before it is used.

Here is what is scaring me about NSEC3: (more than just issue 20 but mainly
issue 20)

In order for authorative server to find the correct NSEC3 record to return
in negative answers, the server NEEDS to interpret the RDADA contents of
a "magic" random NSEC3 to parameterize its search algorithm.
Magic = the NSEC3 covering the apex.

Only in one other place does the RDATA of an RR dictate the behavior of
a server in processing a zone, this is the timer values in the SOA record.

A consequence of this
The first question: Do we want the contents of a new resource
record dictate the processing rules for a zone?

The second question: Do we want this Control plane information
stored in a random place in zone or at a fixed place?

If the answer is the second.
This can be accomplished either by
         special casing the NSEC3 covering the APEX to be stored at
         the APEX
or      create a new RR only allowed at the APEX that stores the
         control parameters for the NSEC3 processing in that zone.

If the current specification proposal stands:
any zone transfer agent now needs to parse the RDATA contents of all
NSEC3 records to check that the zone control plane parameters are still the
same.

         Olafur (no hats just a regular WG trouble maker)

---

From: Ben Laurie <[email-masked]>
Date: Wed, 07 Jun 2006 10:47:36 +0100

> NSEC3 records to check that the zone control plane parameters are still the

The only reason I didn't suggest creating a new RR for the data in the
first place is I suspected I'd get shot for proposing it. If the WG
thinks that's the way to go I'm certainly not opposed.

I'm not in favour of special-casing the apex record, seems to me that
adds complication all over the place in order to accomplish something
unrelated to that complication.

-- 
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