IETF Logo Mail Archive

[dnsext] [Technical Errata Reported] RFC5155 (4622)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 18 February 2016 01:36 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 0777B1A06E9 for <dnsext@ietfa.amsl.com>; Wed, 17 Feb 2016 17:36:41 -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 rIlLrgPYmOXB for <dnsext@ietfa.amsl.com>; Wed, 17 Feb 2016 17:36:34 -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 7E3DC1A0235 for <dnsext@ietf.org>; Wed, 17 Feb 2016 17:36:34 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 0ABC6180209; Wed, 17 Feb 2016 17:36:20 -0800 (PST)
To: ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com, brian@innovationslab.net, terry.manderson@icann.org, ogud@ogud.com, ajs@anvilwalrusden.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20160218013620.0ABC6180209@rfc-editor.org>
Date: Wed, 17 Feb 2016 17:36:20 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/5zawlKD2KztKXaCTqUkDM2B9QGs>
X-Mailman-Approved-At: Thu, 18 Feb 2016 07:54:56 -0800
Cc: edmonds@mycre.ws, dnsext@ietf.org, rfc-editor@rfc-editor.org
Subject: [dnsext] [Technical Errata Reported] 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: Thu, 18 Feb 2016 01:36:41 -0000

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Robert Edmonds <edmonds@mycre.ws>

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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

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

v2.23.0 | Report a Bug | By Email