[dnsext] [Errata Verified] RFC5155 (4622)
RFC Errata System <rfc-editor@rfc-editor.org> Fri, 19 February 2016 16:49 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1031B3269; Fri, 19 Feb 2016 08:49:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.908
X-Spam-Level:
X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 Rgk_Uj6sKCId; Fri, 19 Feb 2016 08:49:00 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632761B3267; Fri, 19 Feb 2016 08:48:56 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 0535118046E; Fri, 19 Feb 2016 08:48:37 -0800 (PST)
To: edmonds@mycre.ws, ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20160219164837.0535118046E@rfc-editor.org>
Date: Fri, 19 Feb 2016 08:48:37 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/VtRLRzxFtDJ9wHfPozKae-z_Qr8>
Cc: brian@innovationslab.net, rfc-editor@rfc-editor.org, iesg@ietf.org, dnsext@ietf.org
Subject: [dnsext] [Errata Verified] RFC5155 (4622)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2016 16:49:01 -0000
The following errata report has been verified for RFC5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=4622 -------------------------------------- Status: Verified Type: Technical Reported by: Robert Edmonds <edmonds@mycre.ws> Date Reported: 2016-02-18 Verified by: Brian Haberman (IESG) Section: 7.2.8 Original Text ------------- 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. Corrected Text -------------- 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 besides NSEC3, 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. Notes ----- If the QNAME is equal to the owner name of an existing NSEC3 RR, then the NSEC3 RR type itself will exist at the QNAME, and the second condition will always be false. -------------------------------------- RFC5155 (draft-ietf-dnsext-nsec3-13) -------------------------------------- Title : DNS Security (DNSSEC) Hashed Authenticated Denial of Existence Publication Date : March 2008 Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG
- [dnsext] [Technical Errata Reported] RFC5155 (462… RFC Errata System
- Re: [dnsext] [Technical Errata Reported] RFC5155 … Brian Haberman
- Re: [dnsext] [Technical Errata Reported] RFC5155 … Blacka, David
- [dnsext] [Errata Verified] RFC5155 (4622) RFC Errata System
- Re: [dnsext] [Technical Errata Reported] RFC5155 … Paul Hoffman
- Re: [dnsext] [Technical Errata Reported] RFC5155 … Ben Laurie