Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

sthaug@nethelp.no Wed, 21 December 2016 16:59 UTC

Return-Path: <sthaug@nethelp.no>
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 3F999129667 for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 08:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.301
X-Spam-Level:
X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ifGC_wGEiyEw for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 08:59:05 -0800 (PST)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6182A129438 for <dnsop@ietf.org>; Wed, 21 Dec 2016 08:59:05 -0800 (PST)
Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id EEFC9E6065; Wed, 21 Dec 2016 17:59:03 +0100 (CET)
Date: Wed, 21 Dec 2016 17:59:03 +0100
Message-Id: <20161221.175903.41673765.sthaug@nethelp.no>
To: paul@nohats.ca
From: sthaug@nethelp.no
In-Reply-To: <alpine.LRH.2.20.1612211047200.13966@bofh.nohats.ca>
References: <CACfw2hj4VfuqsM-jRpxNc+bWNsUcSid+Y=r9U5jsA-0ZLbLRUg@mail.gmail.com> <20161221.163826.74705202.sthaug@nethelp.no> <alpine.LRH.2.20.1612211047200.13966@bofh.nohats.ca>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AcQKtQRcvIyoWTNR3yhVvn9EuT8>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
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: Wed, 21 Dec 2016 16:59:07 -0000

> > No, this draft simply specifies what operators are already doing. Not
> > because they are intent on destroying trust in the DNS or the Internet,
> > but because they are forced to do this by governments, they need to
> > protect their own network, they would like to protect their customers,
> > and lots of other reasons.
> 
> There are two things you mixed together:
> 
> 1) industry based filtering of DNS - a commercial opt-in service offering
> 
> 2) government mandated filtering of DNS - A misguided breakage of
>     protocol forced upon operators.

I "mixed them together" because we use the same mechanism in both
cases. This is where RPZ (which we don't use today) would be handy.

> And 1) should not need to break DNSSEC. IETF should come up with a
> better solution for signaling a DNS lookup might be unhealthy for
> the enduser.

As others have pointed out, we don't only want to signal back to the
user "don't do this DNS lookup" - we want to prevent the lookup from
reaching the authoritative servers. "unhealthy for the end user" is
just one of several reasons why a DNS lookup might be blocked.

> For 2) if it breaks DNSSEC, that is fine. Governments will learn that
> ISPs are not the right tools for censorship, and endnodes will simply
> bypass the ISP DNS resolver.

Government mandated DNS filtering has been in use here in Norway for
more than 8 years, and there is absolutely no sign that the government
will learn what you suggested. Endnodes have been able to bypass the
ISP DNS resolvers all these years, the information on how to do this
has been freely available - and yet a large majority of the endnodes
continue to use the ISP DNS resolvers.

Steinar Haug, AS2116