Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt

Mark Andrews <marka@isc.org> Wed, 06 November 2019 02:21 UTC

Return-Path: <marka@isc.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 B8DA1120833 for <dnsop@ietfa.amsl.com>; Tue, 5 Nov 2019 18:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 MfgPplLfgFEW for <dnsop@ietfa.amsl.com>; Tue, 5 Nov 2019 18:21:18 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C39120826 for <dnsop@ietf.org>; Tue, 5 Nov 2019 18:20:57 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 80AFF3AB003 for <dnsop@ietf.org>; Wed, 6 Nov 2019 02:20:57 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 5CF82160047 for <dnsop@ietf.org>; Wed, 6 Nov 2019 02:20:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 311DD160072 for <dnsop@ietf.org>; Wed, 6 Nov 2019 02:20:57 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Rxs1SzHwAanp for <dnsop@ietf.org>; Wed, 6 Nov 2019 02:20:57 +0000 (UTC)
Received: from [172.30.42.68] (n1-40-244-161.bla1.nsw.optusnet.com.au [1.40.244.161]) by zmx1.isc.org (Postfix) with ESMTPSA id A9DF9160047 for <dnsop@ietf.org>; Wed, 6 Nov 2019 02:20:56 +0000 (UTC)
From: Mark Andrews <marka@isc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Wed, 6 Nov 2019 13:20:54 +1100
References: <157289952539.13851.12121504796430856747@ietfa.amsl.com> <3CDFA5D6-79A5-4156-AEEF-967FDCC94E47@dukhovni.org>
To: dnsop@ietf.org
In-Reply-To: <3CDFA5D6-79A5-4156-AEEF-967FDCC94E47@dukhovni.org>
Message-Id: <6F02C026-34B5-4A99-BE89-E6BAD3E8C189@isc.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4d8larykCo0qEjfZRfjObA_7d80>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Nov 2019 02:21:21 -0000

Under Response Code Selection we already have:

      <t>
        For unimplemented type codes, and in the absence of other
        errors, the only valid response is NoError if the qname
        exists, and NameError (NXDOMAIN) otherwise.  For Meta-RRs
        NOTIMP may be returned instead.
      </t>


> On 6 Nov 2019, at 13:03, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
>> On Nov 4, 2019, at 3:32 PM, internet-drafts@ietf.org wrote:
>> 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-14
> 
> Two comments:
> 
> -----------
> 
> Section 3.1.2 discusses non-response to unexpected qtypes, but there
> is a closely related case that I think warrants a mention.  For example,
> the nameservers for mail.protection.outlook.com (which don't support
> EDNS, returning FORMERR, hence "+noends") mishandle TLSA and other
> unexpected queries:
> 
> i. A TLSA (unexpected qtype) query elicits an incorrect "NOTIMP" response:
> 
>  $ dig +norecur +noedns -t tlsa _25._tcp.mail.protection.outlook.com @ns1-proddns.glbdns.o365filtering.com. 
>  ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 5167
>  ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
>  ;; QUESTION SECTION:
>  ;_25._tcp.mail.protection.outlook.com. IN TLSA
> 
> ii. An "A" query for the same qname correctly returns "NXDOMAIN":
> 
>  $ dig +norecur +noedns -t a _25._tcp.mail.protection.outlook.com @ns1-proddns.glbdns.o365filtering.com.
>  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23790
>  ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
>  ;; QUESTION SECTION:
>  ;_25._tcp.mail.protection.outlook.com. IN A
> 
> This demonstrates misuse of "NOTIMP" to signal an unknown qtype,
> where a simple NODATA or NXDOMAIN suffices. The NOTIMP rcode is only
> appropriate for unsupported opcodes as explained in section 3.1.4.
> While I got a response, it is a "bad" response, not substantively
> better than no response at all.
> 
> So I'd like to see text that makes it clear that unexpected qtypes
> MUST return the same RCODE as would be returned if the qtype were
> some expected value, for which no RRset is present in the zone at
> the requested qname.  If the zone is signed, and the EDNS "DO" bit
> is set in the request, any (untruncated) NODATA or NXDOMAIN response
> MUST of course include the requisite denial of existence proof.
> 
> -----------
> 
> In section 8.2.3, the correction from:
> 
>  OLD: Any unassigned EDNS option code could have be choose for this test.
> 
> to
> 
>  NEW: Any unassigned EDNS option code could have been choose for this test.
> 
> was incomplete, it needed to also s/choose/chosen/, to match an identical
> sentence in 8.2.6.
> 
> -- 
> 	Viktor.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org