[DNSOP] Interesting question

Edward Lewis <edward.lewis@icann.org> Sun, 02 October 2016 05:15 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AD612B13A for <dnsop@ietfa.amsl.com>; Sat, 1 Oct 2016 22:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.197
X-Spam-Level:
X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qIdgTnw5qabb for <dnsop@ietfa.amsl.com>; Sat, 1 Oct 2016 22:15:00 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C6112B136 for <dnsop@ietf.org>; Sat, 1 Oct 2016 22:15:00 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 1 Oct 2016 22:14:57 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Sat, 1 Oct 2016 22:14:57 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: Interesting question
Thread-Index: AQHSHGvqr+G8rEGVSkCapvpzfRebSw==
Date: Sun, 02 Oct 2016 05:14:57 +0000
Message-ID: <A9120F95-856F-412E-8972-6EA743E188CF@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.1.160916
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.236]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3558249895_2016234276"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2W4Ze6g8XcsuarvX1yYmzHg3jRA>
Subject: [DNSOP] Interesting question
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 02 Oct 2016 05:15:03 -0000

On the dns-operations list there is a thread of interest.

Someone as a set of name servers that all have a set up where the parent zone has no delegation to the child (no DS and no NS) but also the child zone is configured without DNSSEC records.

Looking at relevant text in DNSSEC Protocol Modifications [RFC 4035], I see this at the end of the intro to "Authenticating DNS Responses" [Section 5]:

... The absence of DNSSEC data in a response MUST NOT by
   itself be taken as an indication that no authentication information
   exists.

   A resolver SHOULD expect authentication information from signed
   zones.  A resolver SHOULD believe that a zone is signed if the
   resolver has been configured with public key information for the
   zone, or if the zone's parent is signed and the delegation from the
   parent contains a DS RRset.

In the case presented, when the validator, upon seeing no DNSSEC records in a query for the child's SOA, asks for the DS record for the child, the response is NOT "NoError, NoData" but "NXDOMAIN."  I can see how sloppy code might take they two to mean that security "stops" - no DS - but the two answers are very different.  For former means, security stops, the latter means, there ought to be nothing.

The above text might benefit from noting that if a zone is said to not exist, there should be no data there whether or not a response has unsigned records for it.

Or something like that - but I'm not convinced that this is errata or clarifications material.  I would think common coder sense would apply.

(This is similar to the comment I'd had on NXDOMAIN and data below it, similar but not the same.  In this case, it's clear that the recursive server should not cache or otherwise believe/accept the data claimed to exist below the denied name.)