Re: [DNSOP] draft-ietf-dnsop-dns-rpz

Petr Špaček <> Fri, 06 October 2017 13:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B1061349CC for <>; Fri, 6 Oct 2017 06:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 xWtckY0-DwXR for <>; Fri, 6 Oct 2017 06:56:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EF3C1349C8 for <>; Fri, 6 Oct 2017 06:56:23 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:bc7e:ccff:fea4:1d71] (unknown [IPv6:2001:1488:fffe:6:bc7e:ccff:fea4:1d71]) by (Postfix) with ESMTPSA id 0EDEE61109 for <>; Fri, 6 Oct 2017 15:56:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1507298181; bh=mjws3+d/HrZQ1nYOMsfev2rTfdgvrW5IKDsglcqR71k=; h=To:From:Date; b=X/cHYKgFEX3vTy+kmHyGwV4IPvuXVOuNzOQ58gIzTyjUoliz8LR38GE+mteOKRvpO gwdX0jqqOHmHTa/Ea0+q/XlWOk2cdy75VozGtDH4uvKiKN6XdeyuTG5epLyi0xW8wh Q1dFjnQGhRnA1VS0xCkrtNoFKELIMJj1R8Koj9EM=
References: <>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
Organization: CZ.NIC
Message-ID: <>
Date: Fri, 6 Oct 2017 15:56:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] draft-ietf-dnsop-dns-rpz
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Oct 2017 13:56:26 -0000

Hello dnsop,

draft-ietf-dnsop-dns-rpz expired on 2017-09-10, i.e. did not receive any
update from 2017-03-09.

Is there a real apetite for work on this document?

We are considering RPZ implementation for Knot Resolver next year but if
the document is not going to move forward I would rather close the
ticket and be done with it. I certainly do commit to implementing
ever-changing protocol without readily available description ...

Is there anyone interested in the document except me and the appointed

Thank you for replies.
Petr Špaček  @  CZ.NIC

On 18.7.2017 14:13, Suzanne Woolf wrote:
> Dear colleagues,
> As you might recall, we had a call for adoption for draft-vixie-dns-rpz
> just before IETF 98 in March. We had a lively discussion and decided to
> adopt the document for further work in the WG as an Informational RFC.
> However, the chairs then discovered we’d made a mistake in adopting the
> draft with the copyright that reserved rights in derivative works to the
> original authors. This isn’t allowed for a Working Group document (see
> RFC5378, Section 3.3).
> We’ve talked since then with the authors about how we might move forward
> with the draft. They had concerns, which had already been discussed on
> the list, about some of the views of the WG on the applicability of RPZ.
> We believe we’ve found a way forward that meets their concerns and the
> needs of the WG. We propose that:
> 1. The draft adopts the following language in the Introduction:
>     This document describes an existing and widely deployed method by
>     which a security policy can be applied to DNS responses, possibly
>     causing an end system to receive responses that do not correspond to
>     actual DNS zone content. Such policy-based responses might prevent
>     access to selected HTTP servers, or redirect users to "walled
>     gardens", or block objectionable email, or otherwise defend against
>     DNS content deemed malicious by the RDNS operator and the end-user.
>     This method describes its policy using a specially formatted DNS
>     Zone called a Response Policy Zone (RPZ), and is an instance of a
>     more general mechanism called a "DNS Firewall." Like other
>     mechanisms called "firewalls," response policy zones (RPZ) can be
>     used to block both wanted as well as unwanted data.  RPZ ought not
>     be used to interfere with data desired by recipients. In other
>     words, RPZ should be deployed only with the permission of every
>     affected RDNS end-users.
>     This document does not recommend the use of RPZ in any particular
>     situation or instead of other mechanisms including those more
>     commonly called "firewalls."  This document lacks an applicability
>     statement for that reason, and because it merely describes a
>     currently common practice, without recommending or criticising that
>     practice. By design and expectation, response policy zones (RPZ)
>     must be seen as a defensive and virtuous tool, or it will either not
>     be used, or will be bypassed by end-users.
> 2. We had already limited the the scope of the document to describing
> the current protocol, with any discussion of proposed changes left to a
> later document if people want to do that work. That limitation stands.
> The intended document status is Informational.
> 3. The copyright is changed to the standard boilerplate required for a
> WG draft.
> If this is acceptable to the WG, we’ll keep the new draft with these
> changes as a WG draft. 
> If not, the draft will be dropped as a WG item. The authors can seek
> publication of the document as an independent submission or outside of
> the RFC series.
> If you have a comment on this, please make it succinctly and soon.
> thanks,
> Suzanne & TIm