Re: [DNSOP] RFC 5155 §7.2.8

2016-02-17 Thread Evan Hunt
On Wed, Feb 17, 2016 at 03:50:54PM -0500, Robert Edmonds wrote:
> Should the second condition on the RR type have an explicit "besides
> NSEC3" qualifier? Or am I missing something that implicitly excludes RR
> type NSEC3? Otherwise it seems to me that the second condition is always
> false.

Yes, it should have that qualifier.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] RFC 5155 §7.2.8

2016-02-17 Thread Robert Edmonds
Hi,

RFC 5155 says this:

7.2.8.  Responding to Queries for NSEC3 Owner Names

   The owner names of NSEC3 RRs are not represented in the NSEC3 RR
   chain like other owner names.  As a result, each NSEC3 owner name is
   covered by another NSEC3 RR, effectively negating the existence of
   the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
   can be proven by its RRSIG RRSet.

   If the following conditions are all true:

   o  the QNAME equals the owner name of an existing NSEC3 RR, and

   o  no RR types exist at the QNAME, nor at any descendant of QNAME,

   then the response MUST be constructed as a Name Error response
   (Section 7.2.2).  Or, in other words, the authoritative name server
   will act as if the owner name of the NSEC3 RR did not exist.

Should the second condition on the RR type have an explicit "besides
NSEC3" qualifier? Or am I missing something that implicitly excludes RR
type NSEC3? Otherwise it seems to me that the second condition is always
false.

-- 
Robert Edmonds

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop