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

Paul Wouters <> Tue, 20 December 2016 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49CB1129A41 for <>; Tue, 20 Dec 2016 08:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QWT7VRu4n-U8 for <>; Tue, 20 Dec 2016 08:01:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 767CC129B3E for <>; Tue, 20 Dec 2016 07:59:46 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3tjjCg0pLrzFrV for <>; Tue, 20 Dec 2016 16:59:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1482249583; bh=wfIAgZlvm3GuiwKu820gwu8CtKQd3NSmScVtjJMemiY=; h=Date:From:To:Subject:In-Reply-To:References; b=r/sEFJQBvfC0UxQL/nS6NO+F4P8RF2SxM6EJ6/q26FFElShPCCA1YBmgVAP4yBqy2 tsfSAEWa75wwBLjsN1tOwZp55wmXYIXvxJkTRjlxcAQjJKHO64XHYzL9Y5lXVmuEiL OBBj30DqIFwvHpNO9Wg85VSUKfyPX0eptiNalgYU=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LKi2AEJPf941 for <>; Tue, 20 Dec 2016 16:59:40 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS for <>; Tue, 20 Dec 2016 16:59:40 +0100 (CET)
Received: by (Postfix, from userid 1000) id 06156923; Tue, 20 Dec 2016 10:59:37 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.10.3 06156923
Received: from localhost (localhost []) by (Postfix) with ESMTP id E67A44095609 for <>; Tue, 20 Dec 2016 10:59:37 -0500 (EST)
Date: Tue, 20 Dec 2016 10:59:37 -0500
From: Paul Wouters <>
To: dnsop <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Dec 2016 16:01:10 -0000

On Tue, 20 Dec 2016, Suzanne Woolf wrote:

> The draft is being present as "Informational", and the point here is to document current working
> behavior in the DNS (for the past several years).   It is obvious that some feel this draft is a
> large mistake, but like edns-client-subnet, more operators are deploying this than one is aware
> of. 
> This starts a Call for Adoption for draft-vixie-dns-rpz


I think using the DNS to (re)distribute this kind of database is silly.
I think using CNAME's to point to keywords is a silly hack that shows
this solution is done with the wrong tools. I can see merit in people
using the same standard mechanisms to sync up their firewalls with
rulesets - even if a silly implementation is used. So while I think
it is an unwise choice, I don't think it will cause harm other then
the solution shooting itself in the foot, to which I do not object.


My biggest concern is not with the implementation of data synchronization,
but with the concept of introducing DNS lies. Any server implemting the
use of this draft document will be going to return DNS answers to me
that I am forced to drop as BOGUS. With DNSSEC validation moving to the
end node, this becomes indistinguishable from an attack. These end nodes
are likely not the best places to AXFR/IXFR this massive database to. So
I feel that part of a "dns firewall" solution is missing by only specifying
this backend document. What is missing is the part where a validating clients
can somehow receive these administratively blocked queries and validate that
the resolver's reply is somehow authenticated. Then the client can make
an independant decision on whether it has enough trust in the current
resolver being used (say Starbucks vs Google DNS vs a VPN supplied DNS)

And of course if such a companion document is created, how to prevent
nationstates from compelling operators to abuse it. I would hope that
anyone implementing such a query firewall would come up with a method
that would still _send_ the DNSSEC validatable data but with some kind
of marker saying "but you should not really use it", so that we are not
actually breaking DNSSEC and its security parameters. This marker could
be a simple BIT relying on transport security that comes as part of the
current efforts for DNS privacy, or it could as part of an RRTYPE from
some kind of online key on the resolver.

I do not object to working group adoption of this document, but I would
strongly prefer that it would only be aopted with a companion document on
how to use such RPZ zones in a way that does not compromise or withhold
DNSSEC results so that endusers will be able to make their own decision
without large scale DNS filtering affecting their legitimate use of DNS.