[DNSOP] draft-ietf-dnsop-refuse-any: points from Stephane Bortzmeyer

Joe Abley <jabley@hopcount.ca> Tue, 25 July 2017 20:53 UTC

Return-Path: <jabley@hopcount.ca>
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 E9E75131F2D for <dnsop@ietfa.amsl.com>; Tue, 25 Jul 2017 13:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (OpenSSL error: data too large for key size)" header.d=automagic.org
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 3EWJB7MC9CRV for <dnsop@ietfa.amsl.com>; Tue, 25 Jul 2017 13:53:15 -0700 (PDT)
Received: from mail.hopcount.ca (mail.hopcount.ca [IPv6:2001:4900:1:392::156]) (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 23EBA131F10 for <dnsop@ietf.org>; Tue, 25 Jul 2017 13:53:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=automagic.org ; s=hopcount; h=To:Cc:Date:Message-Id:Subject:Mime-Version: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CU/hF5ciVAw+XuJDzwEv6MoX1zA25NIDq2umxw2Chpw=; b=xoZdE6+cX2QyNLunn1bw/vSmpG Wy6lWZwaiCnzcRLM+srD0dmXRBbp/n8h02JFJT6Dg8aw+3uhqUK3tLf5exb995M7CgsRiHbJlIe2M 1vdIDV2CEVKyZ6Znv+oJMmyR8GXTnR8OFFfYv5jE+6basanOe0eyjSXBM1+sOyP/xYvfy3ubXW/yb +lkzBHJ9nG5ZLxRy4j4YxZ+QAzyokkwLBZQpf9ywRvAjdib64lUcTXz6yw+alXCO4mBAkl/ikOBvX MAsqXHIzahoEuHh7lEb92uWP9gFeYIA7Z0cCB8V9QCa2kDPwLGJno0eHKv22OU2O61h7A9RBbSRvx yJvhGwsw==;
Received: from [2607:f2c0:101:202:8013:ad3e:5316:1b92] (helo=node-131fee54bx1ng9lsb6.ipv6.teksavvy.com) by mail.hopcount.ca with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from <jabley@hopcount.ca>) id 1da6pC-000DZc-Tt; Tue, 25 Jul 2017 20:53:03 +0000
From: Joe Abley <jabley@hopcount.ca>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <B33DC19A-5F38-4982-92A3-1E56C368C2D8@hopcount.ca>
Date: Tue, 25 Jul 2017 16:53:02 -0400
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3273)
X-SA-Exim-Connect-IP: 2607:f2c0:101:202:8013:ad3e:5316:1b92
X-SA-Exim-Mail-From: jabley@hopcount.ca
X-SA-Exim-Scanned: No (on mail.hopcount.ca); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/e9YfU_e26l_hUnI06XeBXeRe6sw>
Subject: [DNSOP] draft-ietf-dnsop-refuse-any: points from Stephane Bortzmeyer
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 25 Jul 2017 20:53:17 -0000

Salut Stephane, tout le monde,

With reference to:

  https://mailarchive.ietf.org/arch/msg/dnsop/wwQV0yUMdx1mwO8ig9UyNbMMMWI

> My personal nits, only editorial:
> 
> > "ANY Query" refers to a DNS meta-query
> 
> meta-query is not defined in this document, in RFC 1034, 1035 or
> 7719. Opinion: just "query".
> 
> > Below are the three different modes of behaviour by DNS responders
> > for names that exists that are used, listed in the order of
> > preference
> 
> Is it obvious for everyone that it is the decreasing order (most
> preferred first)?

Thanks for those suggestions -- I will apply a gentle sponging action to the text and make it shinier in all three cases.

> > Implementers SHOULD provide an option for operators to specify
> > behavior over TCP.
> 
> If this is because, with TCP, you have some certainty about the client
> address, and therefore do not risk reflection attacks, then I suggest
> to replace TCP by "transports that provide some guarantee about the
> authenticity of the source IP address, such as TCP or DNS cookies".

I think mentioning other future transports is sensible. I also take fanf's point that ability to believe that a source address is legitimate is not the only reason for wanting this behaviour. Perhaps the middle ground is to acknowledge that the approach is applicable to multiple transports, but that implementors SHOULD provide individual controls for each transport to accommodate the full range of desired behaviours?


Joe