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, 06 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
- [DNSOP] I-D Action: draft-ietf-dnsop-no-response-… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-respo… Viktor Dukhovni
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-respo… Mark Andrews
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-respo… Matthew Pounsett
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-respo… Ray Bellis
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-respo… Matthew Pounsett