Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

Evan Hunt <each@isc.org> Tue, 20 December 2016 06:12 UTC

Return-Path: <each@isc.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 3FB2C129434 for <dnsop@ietfa.amsl.com>; Mon, 19 Dec 2016 22:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 t8D0wu28EYcD for <dnsop@ietfa.amsl.com>; Mon, 19 Dec 2016 22:12:45 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 4F29812896F for <dnsop@ietf.org>; Mon, 19 Dec 2016 22:12:45 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 6EE7C3493BC; Tue, 20 Dec 2016 06:12:42 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 61714216C1C; Tue, 20 Dec 2016 06:12:42 +0000 (UTC)
Date: Tue, 20 Dec 2016 06:12:42 +0000
From: Evan Hunt <each@isc.org>
To: ac <ac@main.me>
Message-ID: <20161220061242.GC63084@isc.org>
References: <20161219.101111.41661466.sthaug@nethelp.no> <20161219092509.0DBA5129452@ietfa.amsl.com> <20161219093846.GA25654@server.ds9a.nl> <20161219095038.55A171295A9@ietfa.amsl.com> <32D6D9A0-17F2-4C86-A06B-55DF4D747159@rfc1035.com> <20161219115524.A9D31129795@ietfa.amsl.com> <20161220044238.C0307129473@ietfa.amsl.com> <20161220045606.GA63084@isc.org> <20161220053120.299FD349452@mx.pao1.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20161220053120.299FD349452@mx.pao1.isc.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XzGvnrvUvxKtNmCIoxa2SC76SJw>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Dec 2016 06:12:46 -0000

On Tue, Dec 20, 2016 at 07:30:43AM +0200, ac wrote:
> You are quite correct, but the minute you answer questions for other
> people the entire situation changes. 

Not if they've contracted with me to answer their questions in a way
that protects them from malware, it doesn't.

> To rip the dam from underneath the duck: You cannot legally resolve a
> non google IP number as "google.com" just because your t&c says you can
> do whatever you want.

If google.com is known to be sending malware or spam or other undesirable
content (which it isn't), then of course I can.  Or, instead of remapping
the answer, I can return NXDOMAIN.  This would not be theft; it would a
service provided to my malware-averse clientele.  If they don't want this
to happen then they should use some other resolver or run their own.

Now, if I remap google.com in order to *cause* my clients to receive
malware or spam, then yes, I agree that I am being evil, and I hope
everyone is using DNSSEC and SSL certificate validation and other such
mechanisms to detect and avoid this.

> in DNS, it is much more subtle, it is about honesty, morality and ethics.

I remember when I stood up at my first IETF meeting and asserted the
principle that the DNS should not lie.  I was 40 years old.  Just a
starry-eyed kid with a dream.

Even then, though, the context of my statement was that there were
technical considerations that made it regrettably necessary to lie
in certain operational environments - specifically, some networks at
the time were breaking when they received AAAA answers, so we'd added
an option to filter those. Such considerations take precedence over
absolute truthfulness.

"Not wanting to be recruited into a botnet" is another such consideration.
Paul and Vernon invented a useful tool to help address it, and I'm
in favor of documenting it.

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.