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.
- [DNSOP] Adoption and Working Group Last Call for … Tim WIcinski
- Re: [DNSOP] Adoption and Working Group Last Call … Stephane Bortzmeyer
- Re: [DNSOP] Adoption and Working Group Last Call … Paul Hoffman
- Re: [DNSOP] Adoption and Working Group Last Call … Ray Bellis
- Re: [DNSOP] Adoption and Working Group Last Call … Tony Finch
- Re: [DNSOP] Adoption and Working Group Last Call … Stephane Bortzmeyer
- Re: [DNSOP] Adoption and Working Group Last Call … Hugo Connery
- Re: [DNSOP] Adoption and Working Group Last Call … Robert Edmonds