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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 06 November 2019 02:03 UTC

Return-Path: <ietf-dane@dukhovni.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 0F705120274 for <dnsop@ietfa.amsl.com>; Tue, 5 Nov 2019 18:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 B_vB7Gn2PA73 for <dnsop@ietfa.amsl.com>; Tue, 5 Nov 2019 18:03:30 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93845120154 for <dnsop@ietf.org>; Tue, 5 Nov 2019 18:03:29 -0800 (PST)
Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id DB8F831BCEB for <dnsop@ietf.org>; Tue, 5 Nov 2019 21:03:28 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <157289952539.13851.12121504796430856747@ietfa.amsl.com>
Date: Tue, 05 Nov 2019 21:03:28 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: dnsop@ietf.org
Message-Id: <3CDFA5D6-79A5-4156-AEEF-967FDCC94E47@dukhovni.org>
References: <157289952539.13851.12121504796430856747@ietfa.amsl.com>
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oPOD9p3xKeEko0v0Mc85ygKfJ4Q>
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:03:33 -0000

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