[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
- [DNSOP] RFC 5155 §7.2.8 Robert Edmonds
- Re: [DNSOP] RFC 5155 §7.2.8 Evan Hunt