Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Tue, 18 September 2018 11:35 UTC

Return-Path: <ietf@kuehlewind.net>
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 63B771277D2 for <dnsop@ietfa.amsl.com>; Tue, 18 Sep 2018 04:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 Klyy-u6K3me2 for <dnsop@ietfa.amsl.com>; Tue, 18 Sep 2018 04:35:41 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93237130DC0 for <dnsop@ietf.org>; Tue, 18 Sep 2018 04:35:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=oirt7WoV36N04hhXkfHDi01kNByXaw4pCXp+honjpYj2Z6sd5jQ4QdS4RrQBxfiJrcCxKOooGBmZ5OstYqRkswk4XX4VN6r1MQ70E7QFlxJAGbuFwZr0lLYVAU4Xc7zdosMoSjjTQA1IUj68Q3KzApn+UdXtexOmlwy9OdwUEGw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 29792 invoked from network); 18 Sep 2018 13:28:57 +0200
Received: from i577bce80.versanet.de (HELO ?192.168.178.24?) (87.123.206.128) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Sep 2018 13:28:57 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <alpine.DEB.2.20.1809141216340.5965@grey.csi.cam.ac.uk>
Date: Tue, 18 Sep 2018 13:28:55 +0200
Cc: Tim Wicinski <tjw.ietf@gmail.com>, draft-ietf-dnsop-refuse-any@ietf.org, dnsop-chairs <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF9F3F9B-9E6D-4E25-8E34-0F1F6579EBF6@kuehlewind.net>
References: <153658244644.26649.463764101726763839.idtracker@ietfa.amsl.com> <CAN6NTqwTt5SZ=_69kAd31qEtFKnZsOu7sShy26uOoShZtyJkkQ@mail.gmail.com> <3EBC432D-6B59-4560-82B8-9CBA449068CA@kuehlewind.net> <CAJE_bqcnAhvQDg_KmoSGfBOeKJROkNUrxj=+===8A3EGcSHKvw@mail.gmail.com> <alpine.DEB.2.20.1809141216340.5965@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>, 神明達哉 <jinmei@wide.ad.jp>, Ólafur Guðmundsson <olafur@cloudflare.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180918112857.29781.12171@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F4bMSrTvafzq1HrTHg4oDWX2wYI>
Subject: Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)
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: Tue, 18 Sep 2018 11:35:42 -0000

Hi all,

please see below.

> Am 14.09.2018 um 13:26 schrieb Tony Finch <dot@dotat.at>:
> 
> 神明達哉 <jinmei@wide.ad.jp> wrote:
>> 
>> Whether we *SHOULD* (rather than MAY) allow the conventional response
>> in case of TCP is a different question, on which I don't have a strong
>> opinion.

That the question I had. Currently the doc only says 

"A DNS responder MAY behave differently when processing ANY queries
   received over different transport“

which kind of implicitly say, refuse-any is always the right default… I was wondering if for the case of TCP a SHOULD would actually be more appropriate. 

> 
> I think at the moment it is mostly harmless and sometimes helpful for
> debugging or inspection - e.g. `dig` switches to TCP by default for ANY
> queries to avoid confusing users with partial answers, so it makes use of
> this SHOULD.

There is no SHOULD right now...

> 
> If I look into my crystal ball at a future where resolvers query auth
> servers over TLS, then the balance might change. Maybe at that point it'll
> be better for resolvers to implement refuse-any rather than relying on
> auth servers to do it for them; or maybe it'll be better to do
> refuse-any over all transports. Dunno :-)

That’s also fine. If it is not clear which recommendation should be given for TCP then it does make sense to say anything more than what the doc currently says.

Mirja



> 
> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> North Fitzroy: Variable 3 or 4, becoming southerly or southeasterly 5 or 6 in
> west. Moderate. Occasional rain in west. Good, occasionally moderate in west.