Re: [DNSOP] Adoption and Working Group Last Call for draft-ietf-dnsop-dns-terminology/

Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 22 April 2015 12:34 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872E61B357F for <dnsop@ietfa.amsl.com>; Wed, 22 Apr 2015 05:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.339
X-Spam-Level:
X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 FinDKU-p5-da for <dnsop@ietfa.amsl.com>; Wed, 22 Apr 2015 05:34:26 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 0F4A81B356F for <dnsop@ietf.org>; Wed, 22 Apr 2015 05:34:26 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 64B3528017B; Wed, 22 Apr 2015 14:34:24 +0200 (CEST)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 5F94E28015F; Wed, 22 Apr 2015 14:34:24 +0200 (CEST)
Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 5DAA0B3800C; Wed, 22 Apr 2015 14:33:54 +0200 (CEST)
Date: Wed, 22 Apr 2015 14:33:54 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <20150422123354.GA12528@nic.fr>
References: <5530E4FD.8080104@gmail.com> <20150420134335.GA14186@nic.fr> <FBFC9A2E-46EF-40CD-83F6-E158F5612862@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <FBFC9A2E-46EF-40CD-83F6-E158F5612862@vpnc.org>
X-Operating-System: Debian GNU/Linux 8.0
X-Kernel: Linux 3.16.0-4-686-pae i686
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/SkYMUMX2KMbRypE37WNyxfE-Bfc>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Adoption and Working Group Last Call for draft-ietf-dnsop-dns-terminology/
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 22 Apr 2015 12:34:32 -0000

On Mon, Apr 20, 2015 at 09:57:06AM -0700,
 Paul Hoffman <paul.hoffman@vpnc.org> wrote 
 a message of 98 lines which said:

> The definition in the draft includes ideas from RFC 5625, which
> seems to be the much more common definition of "forwarder" used
> today. However, the WG is free to define this however they want.

I disagree with "much more common". The two definitions can be
summarized as:

1) a forwarder is the machine which forwards
2) a forwarder is the machine which receives the forwarded request

I find 2) much more common, because it is the meaning it has in BIND.

> My proposal goes the other way: to use the more common definition of
> a forwarder being what we see in gazillions of SOHO devices.

And then we will have thousands of BIND configs to patch...

Anyway, _today_, in draft-ietf-dnsop-dns-terminology-00, the
definition of "forwarder" is not 1) or 2) but a strange mix of both.

> > Dangerous legal and political issues here. If Joe Sysadmin
> > configures the DHCP server to tell the users' machines to use
> > 192.0.2.53 and this resolver rewrites answers, can we honestly say
> > that the users "are expected to know"? Technically, there is no
> > difference between Consensual policy-implementing resolver and
> > Non-consensual policy-implementing resolver and I would merge the
> > definitions.
> 
> Please propose specific wording for the merge so the WG can see if
> they like it better.

Policy-implementing resolver -- A resolver that changes some answers
it returns based on policy criteria, such as to prevent access to
malware sites.  This is just a technical definition: such a
policy-implementing resolver can be installed by various actors, for
various reasons, and users may or may not be aware of its
policy. [Some people prefer to be direct and call it a lying
resolver.]

> >> Passive DNS -- A mechanism to collect large amounts of DNS data
> >> by storing queries and responses from recursive servers.
> > 
> > Most passive DNS servcies collect only the responses, which is good
> > for privacy.
> 
> Some passive DNS services collect the query too. Given the privacy
> issue you mention, we should make people aware of that.

Passive DNS -- A mechanism to collect large amounts of DNS data by
storing responses from servers. Some of these systems also collect
queries, which can raise privacy issues.