[DNSOP] RFC 5155 §7.2.8

Robert Edmonds <edmonds@mycre.ws> Wed, 17 February 2016 20:50 UTC

Return-Path: <edmonds@mycre.ws>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C0B1A0115 for <dnsop@ietfa.amsl.com>; Wed, 17 Feb 2016 12:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.6
X-Spam-Level: **
X-Spam-Status: No, score=2.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, SUBJ_ALL_CAPS=1.506] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD_Qx-FSF25b for <dnsop@ietfa.amsl.com>; Wed, 17 Feb 2016 12:50:55 -0800 (PST)
Received: from chase.mycre.ws (chase.mycre.ws [70.89.251.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11D41A1A7C for <dnsop@ietf.org>; Wed, 17 Feb 2016 12:50:55 -0800 (PST)
Received: by chase.mycre.ws (Postfix, from userid 1000) id 03DB712C0E72; Wed, 17 Feb 2016 15:50:55 -0500 (EST)
Date: Wed, 17 Feb 2016 15:50:54 -0500
From: Robert Edmonds <edmonds@mycre.ws>
To: dnsop@ietf.org
Message-ID: <20160217205054.GA29947@mycre.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/0SRmEB95rlh5xu2Y7CO3NboNGb0>
Subject: [DNSOP] RFC 5155 §7.2.8
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Feb 2016 20:50:56 -0000

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