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

From: tjw ietf <[email-masked]>
Date: Tue, 20 Dec 2016 10:16:58 -0500

Why not just wade into this discussion...

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

The draft is available here:
https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

With the holiday period upon us, we'll make this a three week call for
adoption. This call for adoption ends on 10 January 2017

Thanks,
tim wicinski
DNSOP co-chair

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 20 Dec 2016 10:26:45 -0500

> On Dec 20, 2016, at 10:16 AM, tjw ietf <[email-masked]> 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. 
> 

As an additional observation: 

The discussion already on the mailing list has shown a number of views on the legal and ethical implications of using RPZ, or publishing an Informational RFC about it. 

In the past, where there has been controversy about similar issues, the WG has sometimes declined to adopt a draft. If the draft had been adopted as a WG work item, the WG may have asked that the draft be modified to reflect those concerns. Sometimes the consensus has been to regard them as out of scope. Sometimes there’s been no way to get to consensus on a draft, and the WG involved hasn’t advanced it for publication.

Ethical and legal issues, including those around DNS names and DNS operations, are complex and “the truth” varies widely with circumstance and jurisdiction, both of which tend to be determined outside of the IETF. 

If you feel you must comment on those aspects of RPZ, please keep it brief, avoid unsustainable generalizations,  and state clearly whether you support adoption, oppose adoption, or support adoption with changes you’re willing to work on. 

thanks,
Suzanne

---

From: Ray Bellis <[email-masked]>
Date: Tue, 20 Dec 2016 15:29:07 +0000

On 20/12/2016 15:16, tjw ietf wrote:

> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.

Yes, it's suitable, as an informational document describing current
implementations.

> Please also indicate if you are willing to contribute text, review, etc.

I am (and already did so prior to it coming to the WG).

kind regards,

Ray

---

From: Jim Reid <[email-masked]>
Date: Tue, 20 Dec 2016 15:37:45 +0000

> On 20 Dec 2016, at 15:29, Ray Bellis <[email-masked]> wrote:
> 

+1

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 20 Dec 2016 10:52:45 -0500

On 20 December 2016 at 10:37, Jim Reid <[email-masked]> wrote:

> Agreed.  I think it will be useful to have this documented.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Dec 2016 10:59:37 -0500 (EST)

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. 
> 

First,

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.

Second,

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.

Paul

---

From: "Allan Liska" <[email-masked]>
Date: Tue, 20 Dec 2016 11:23:11 -0500

On 12/20/2016 at 10:17 AM, "tjw ietf"  wrote:
The draft is available
here:https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/

Please review this draft to see if you think it is suitable for
adoption by DNSOP, and comments to the list, clearly stating your
view.
Please also indicate if you are willing to contribute text, review,
etc.

I support the adoption of this and would be willing to volunteer to
assist.
allan

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 20 Dec 2016 08:33:18 -0800

On 20 Dec 2016, at 7:16, tjw ietf wrote:

> adoption by

The draft itself is really not suitable for adoption by the WG. Just 
slapping "Informational" on the document is insufficient for preventing 
a lot of wasted effort by the WG in removing the parts of the document 
that promote the practices described.

If this is really just documenting current practice, then the document 
needs to be pared down significantly, and I strongly suspect the authors 
will not want to do that. They believe (as do many others) that the 
practices in this document are good for the Internet and good for the 
DNS. That's fine, and the fact that it has been implemented in a bunch 
of places shows that there is a community of active interest for 
promoting the idea.

Some here have argued that the protocol makes poor design choices, and 
some here have argued that the IETF publishing the protocol (even if it 
was stripped of suggesting it is a good idea) will give the wrong 
impression. As this WG has already seen, this is a recipe for lots of 
wasted time in the WG and a document at the end that makes no one happy.

Counter-question: of what value is documenting this current practice? 
Anyone who is already using it can find the documentation for it from 
their software vendor. There is nothing here that really affects the 
rest of the DNS other than "there will be lies".

--Paul Hoffman

---

From: Ray Bellis <[email-masked]>
Date: Tue, 20 Dec 2016 16:35:48 +0000

> rest of the DNS other than "there will be lies".

The document primarily covers BIND's behaviour.

It would be good if other implementations were completely compatible
with that, and this also forms the baseline for potential future
enhancements which could be under IETF change control.

Ray

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 20 Dec 2016 11:44:51 -0500

> enhancements which could be under IETF change control.

Additionally, the authors are looking at addressing addressing several 
additions, issues, etc with the followup  -bis draft which would be more 
likely standards track.  This is following the edns-client-subnet model 
for better or for worse

tim

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 20 Dec 2016 09:43:25 -0800

> The document primarily covers BIND's behaviour.

Noted. That seems like a good reason for ISC to document it.

> with that,

Is this so that different implementations use the same master file 
format, or something else?

> and this also forms the baseline for potential future

It is completely unnecessary for the future enhancements to be based on 
an RFC. The IETF has experience where trying to change a vendor-specific 
informational RFC to something better was harder than starting from 
"here's a way to do it; Appendix A shows the differences in how This Big 
Vendor did it earlier".

On 20 Dec 2016, at 8:44, Tim Wicinski wrote:

> additions, issues, etc with the followup  -bis draft which would be 
> more likely standards track.  This is following the edns-client-subnet 
> model for better or for worse

Worse. And there are other examples in other areas of the IETF where 
this turned out to be worse.

--Paul Hoffman

---

From: Ray Bellis <[email-masked]>
Date: Tue, 20 Dec 2016 17:46:56 +0000

> Noted. That seems like a good reason for ISC to document it.

ISC isn't the current custodian of the specification.  Vixie and VJS are.

> format, or something else?

Same zone structure (it's not the file format, but the contents thereof)
and same order-of-processing rules.

> "here's a way to do it; Appendix A shows the differences in how This Big

Not my call - I'm relaying what was said in Seoul.

Ray

---

From: bert hubert <[email-masked]>
Date: Tue, 20 Dec 2016 18:46:50 +0100

> Noted. That seems like a good reason for ISC to document it.

No it doesn't. It also documents the exact PowerDNS behaviour. RPZ is a
standard, even if it isn't an RFC yet. It interoperates extensively.

Unbound is also slated to have support for RPZ.

	Bert

---

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Dec 2016 13:12:06 -0500 (EST)

> Unbound is also slated to have support for RPZ.

One would hope it interops, as this document only describes an IXFR/AXFR
of a zone with existing RRTYPEs with some semantics associated to CNAME
records for other applications (such as DNS servers)

Did you mean "interoperate" as in how it uses this information for query
firewalling? If so, wouldn't that be out of scope of the current draft
and discussion? (unless: see my other email with concerns about this)

Paul

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 20 Dec 2016 10:46:40 -0800

On 20 Dec 2016, at 9:46, bert hubert wrote:

> No it doesn't. It also documents the exact PowerDNS behaviour.

PowerDNS can document it, or can point to the ISC documentation.

> RPZ is a
> standard, even if it isn't an RFC yet.

It is statements like this which show that this WG working on this as an 
"Informational RFC" is dishonest and is sure to lead to massive 
dissatisfaction with the result.

> It interoperates extensively.

Good!

> Unbound is also slated to have support for RPZ.

Unbound can document it or point to the ISC documentation.

--Paul Hoffman

---

From: Ray Bellis <[email-masked]>
Date: Tue, 20 Dec 2016 18:54:41 +0000

> dissatisfaction with the result.

AIUI, the authors *could* just request that it go AD Sponsored via the
Independent Submissions stream.

Having it here at least ensures that a variety of DNS folks can weigh in
on any bits that are unclear to them (albeit without any expectation
that the protocol itself would change as a result).  The result *should*
be a specification that's easier to read and implement.

Ray

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 20 Dec 2016 12:14:22 -0800

> Independent Submissions stream.

Those are two different methods. AD-sponsored means that it still would 
need IETF consensus, but no WG action. Independent Submission is 
completely separate, and has no IETF consensus; however, the ISE has to 
ask the IESG if there are any conflicts with IETF activities, and since 
there is a -bis planned, that might be a blocker.

> be a specification that's easier to read and implement.

Quite true, but that is has not been the case in the past.

If all people want is a technical specification that says "some software 
will react in this way when it sees zones specified this way", that can 
be done as a very short WG document that is quite different than 
draft-vixie-dns-rpz. However, I suspect that the differences would be so 
great that the authors of draft-vixie-dns-rpz, who have put a lot of 
work into promoting the use cases for RPZ, might not want to make the 
drastic changes.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Dec 2016 22:53:39 +0000

> by DNSOP, and comments to the list, clearly stating your view.

I believe that RPZ (and the DNS lies which it creates) is evil --
unfortunately we live in a world where this is a necessary evil.
I wish we lived in a world where RPZ was not necessary, but, well, we
don't, and so:

I support adoption of this draft. I believe that it solves an important use
case and that it needs to be publicly documented (it is already widely used
/ deployed and supported).
I suspect that the changes to the document should primarily be to increase
clarity / readability / fix nits, and that we should avoid the temptation
to make substantive changes.

I'm willing to contribute text, review, fold, spindle and mutilate,
whatever will be useful to get this out the door.

W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 21 Dec 2016 07:19:34 +0100

Moin!

On 20 Dec 2016, at 17:33, Paul Hoffman wrote:

> slapping "Informational" on the document is insufficient for 
> preventing a lot of wasted effort by the WG in removing the parts of 
> the document that promote the practices described.
Other then in section 1, I didn't see this. However your response is yet 
another
examples why we don't have operator participation in the IETF though we 
always
say that we want it.

I've talked to lots of operators of recursive DNS servers and nearly all 
of them
have some form of DNS blocking/redirection, yet whenever this comes up 
in the
IETF sometimes even from operators (draft-livingood-dns-redirect) we 
look the
other way and say this does/should not exist.

Well it does and if the IETF wants to be relevant to those operators it 
would be
good if we had documents describing this, so they could be used as 
guidelines.

And while I don't like yet another draft that encodes something in DNS 
data that
was not meant to be DNS data I have to agree that this draft is relevant 
to
this working group and given that we have already multiple 
implementations of
it I think that the draft is something the working group should adopt.

So long
-Ralf

---

From: bert hubert <[email-masked]>
Date: Wed, 21 Dec 2016 08:14:36 +0100

> Unbound can document it or point to the ISC documentation.

We might as well stop doing standards all together then. We have something
that works. It interoperates. There is an ecosystem of services around it.

And what do people say? "Not going to standardize it".

The thing is, RPZ is not actually something that was slapped together. It
makes sense. Vernon and Paul clearly were on to something when they wrote
it.

In other words, it is not "documenting a configuration file". It is a great
thing to be able to point to and say this is the standard, this is how we do
things.

But meanwhile I will now use TCP/IP to send this message, without having to
refer to some old BSD documentation.

	Bert

---

From: bert hubert <[email-masked]>
Date: Wed, 21 Dec 2016 08:17:25 +0100

> records for other applications (such as DNS servers)

The "some semantics" parts are what is standardized. The rest is indeed good
old DNS. The "some semantics" parts need to interoperate because otherwise
they don't mean the same thing here and there, and we can't create a hybrid
internet ecosystem.

It is important the 'some semantics', which by the way are real work to
implement correctly, are standardized.

	Bert

---

From: william manning <[email-masked]>
Date: Wed, 21 Dec 2016 06:36:16 -0800

the complaints about operator participation in the IETF go back decades.
 no news there.
in fact, there are operator driven fora for just such activities, DNS-OARC
comes to mind.
this draft actively destroys trust in the DNS, which reduces trust in the
Internet overall.
is that really what you want out of the IETF?

/Wm

On Tue, Dec 20, 2016 at 10:19 PM, Ralf Weber <[email-masked]> wrote:

>>> by
>> slapping "Informational" on the document is insufficient for preventing a
>> lot of wasted effort by the WG in removing the parts of the document that
>> promote the practices described.
>>
> have some form of DNS blocking/redirection, yet whenever this comes up in
> the
> IETF sometimes even from operators (draft-livingood-dns-redirect) we look
> the
> was not meant to be DNS data I have to agree that this draft is relevant to
> this working group and given that we have already multiple implementations
> of

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Dec 2016 09:55:02 -0500

On Dec 21, 2016, at 9:36 AM, william manning <[email-masked]> wrote:
> this draft actively destroys trust in the DNS, which reduces trust in the Internet overall.  

Why would we trust unsigned data from the DNS?   If we did, why would that be a good thing?

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 21 Dec 2016 10:04:38 -0500

Hi,

Just for clarity— no one is proposing standards track for this document; the intended status has been consistently discussed as “Informational”.

In discussing RPZ, as we’ve seen with other technology in the past, there’s a difference between “the consequences of having a controversial  technology in widespread use” and “given a controversial technology in widespread use, the consequences of having an RFC about it.”

As an IETF working group, DNSOP has a lot more to say about the latter than the former.

In the past, the WG has sometimes taken the position that there’s value in an informational document on a widely-used and interoperable protocol extension, even if the goal isn’t to make it part of the formal standard. RPZ seems to be such a technology, in that it’s widely deployed in the operational internet— an RFC is obviously neither necessary nor sufficient for that.

Users of such an informational RFC that’s separate from vendor documentation might include operators who want to deploy the feature responsibly, new implementers who need a reference on how to make new code interoperable, and operators who want to avoid use of a feature or simply understand its impact on their environment.

If the question is “Does the existence of an Informational RFC mean the IETF is endorsing or promoting a technology or practice?” the answer is “No."

If the question is “Does the existence of an Informational RFC mean people will think the IETF is endorsing or promoting a technology or practice, and are they more likely to use it as a result?” the answer is pretty subjective and tends to be “It depends”— on the technology, on whether the document includes warnings about shortcomings and side effects, and on the forces that got the technology invented and deployed in the first place.

Suzanne

> On Dec 21, 2016, at 2:14 AM, bert hubert <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Wed, 21 Dec 2016 16:38:26 +0100 (CET)

Since operator participation was mentioned,

<op hat on>

> this draft actively destroys trust in the DNS, which reduces trust in the

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.

It's possible that the ball will be dropped on this one like it was for
NAT. That would be stupid, IMHO.

Steinar Haug, AS2116

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 21 Dec 2016 07:43:32 -0800

On 21 Dec 2016, at 7:04, Suzanne Woolf wrote:

> Just for clarity— no one is proposing standards track for this 
> document; the intended status has been consistently discussed as 
> “Informational”.

That "consistently" doesn't seem to apply to many people who have said 
+1 to the adoption of this document.

A different document, one that helps implementers who want to do the 
same thing as the others but that has no encouraging rationale and that 
acknowledges that there will likely be later work on the same topic, 
would be a much better starting place for this work. A document that has 
just sections 2 through 5 of this document with the barest of 
introductions, would be a much better starting point for this WG.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Dec 2016 10:53:25 -0500 (EST)

> 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.

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.

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.

> NAT. That would be stupid, IMHO.

The NAT example is as much overused by those in favour and against it.
It has no relation to this issue whatsoever.

Paul

---

From: [email-masked]
Date: Wed, 21 Dec 2016 17:59:03 +0100 (CET)

>     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.

> better solution for signaling a DNS lookup might be unhealthy for

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.

> 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

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 21 Dec 2016 12:14:24 -0500

On 21 December 2016 at 10:53, Paul Wouters <[email-masked]> wrote:

> Other than returning an altered answer (pointing to an informational site)
or no answer at all, what would this look like in practice?

The signal probably needs to be in-band in the DNS response, and downstream
recursive/forwarding servers need to know to pass those data along with
certain responses. So there's a change to the protocol.

Libraries (glibc, etc.) need to be modified to receive and understand these
new data and pass them on as part of a gethostbyname() call, so there's a
change to all operating systems.

Applications that use the DNS need to understand this new signal and know
what to do with it, so there's a change to every application that uses the
DNS.

These are the things you need in place for an alternative to be effective.
I think that would be a fantastic way for things to work, but we haven't
even managed to get a majority of applications to implement DNSSEC yet.

If you think the above sounds silly, then please propose some other
alternative with a shorter path to deployment.  Taking it out of band of
the DNS probably makes things simpler, but then you still need to modify
every recursive server and every application.  In the intervening decades
while that is being designed and deployed, operators are going to continue
using RPZ or something like it, so why don't we document that, and how it
should work?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Dec 2016 12:29:29 -0500

Practically speaking, none of these changes are _required_.   The worse case scenario is that if someone looks up a malicious domain, you get back a bogus answer that doesn’t validate.   The resolver reports "no answer" because an answer that doesn’t validate is no answer.   The user sees that the page fails to load.   There is little they can do to bypass this, and they aren’t likely to have a sense of how to do it, so our job is pretty much done.

It would be _nice_ if the browser, for example, could get some kind of positive, signed assertion that some authority has claimed that the domain in question is malicious (or whatever).   This would be good mostly for the purpose of transparency, so it’s not clear that it makes any difference if it’s communicated to the user: people who care about transparency will be able to look it up, and, in particular, people who are interested in watching for censorship will have no problem at all noticing that it is happening.

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 21 Dec 2016 12:39:55 -0500

On 21 December 2016 at 12:29, Ted Lemon <[email-masked]> wrote:

> Practically speaking, none of these changes are _required_.   The worse
> case scenario is that if someone looks up a malicious domain, you get back
> a bogus answer that doesn’t validate.   The resolver reports "no answer"
> because an answer that doesn’t validate is no answer.   The user sees that
> the page fails to load.   There is little they can do to bypass this, and
> they aren’t likely to have a sense of how to do it, so our job is pretty
> much done.
>

None of those things are required by RPZ, but I believe they are required
by the hypothetical better alternative that a few people have suggested we
should work on instead.

>
> It would be _nice_ if the browser, for example, could get some kind of
> positive, signed assertion that some authority has claimed that the domain
> in question is malicious (or whatever).   This would be good mostly for the
> purpose of transparency, so it’s not clear that it makes any difference if
> it’s communicated to the user: people who care about transparency will be
> able to look it up, and, in particular, people who are interested in
> watching for censorship will have no problem at all noticing that it is
> happening.
>

If you want the browser to receive and understand a signal then that signal
needs to be invented, the DNS servers need to be modified to send it, and
the browsers (and all other applications you want to benefit) need to be
modified to receive and understand it.  This is the point I was making.

RPZ is not the ideal, but it works, and goes beyond being deployable–it is
deployed.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Dec 2016 12:47:47 -0500

On Dec 21, 2016, at 12:39 PM, Matthew Pounsett <[email-masked]> wrote:
> None of those things are required by RPZ, but I believe they are required by the hypothetical better alternative that a few people have suggested we should work on instead.  

To be clear, there is no real alternative to RPZ in terms of providing protection.   We could provide annotation in RPZ, and that might be useful in some cases.   But ultimately if a domain is malicious, you _have_ to block it by not providing an answer.   If you do not, only those devices that implement the new protocol will be protected, which is to say we will be failing broken, not failing safe.

> If you want the browser to receive and understand a signal then that signal needs to be invented, the DNS servers need to be modified to send it, and the browsers (and all other applications you want to benefit) need to be modified to receive and understand it.  This is the point I was making.

Yes, correct.   I proposed a draft in tls to do this after the redirect has happened, which I think is useful, but does not solve the problem of signaling when DNSSEC is available: https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00 <https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00>

If we wanted to account for DNSSEC and provide signaling, I think the signaling would have to take the form of a signed EDNS0 option that signaled similar information.

In the draft I’m referencing, it was my intention to provide a set of values that could be returned to indicate what has happened.   I think it’s a bad idea to provide anything more than that, because for example if you return a text string, that becomes an attack surface.   You can use it to trick the user into bypassing their security settings.

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 21 Dec 2016 12:52:22 -0500

On 21 December 2016 at 12:47, Ted Lemon <[email-masked]> wrote:

> To be clear, there is no real alternative to RPZ in terms of providing
> protection.   We could provide annotation in RPZ, and that might be useful
> in some cases.   But ultimately if a domain is malicious, you _have_ to
> block it by not providing an answer.   If you do not, only those devices
> that implement the new protocol will be protected, which is to say we will
> be failing broken, not failing safe.
>

You and I are in energetic agreement.

>
> If you want the browser to receive and understand a signal then that
> signal needs to be invented, the DNS servers need to be modified to send
> it, and the browsers (and all other applications you want to benefit) need
> to be modified to receive and understand it.  This is the point I was
> making.
>
>
> Yes, correct.   I proposed a draft in tls to do this after the redirect
> has happened, which I think is useful, but does not solve the problem of
> signaling when DNSSEC is available: https://tools.ietf.
> org/html/draft-lemon-tls-blocking-alert-00
>
> If we wanted to account for DNSSEC and provide signaling, I think the
> signaling would have to take the form of a signed EDNS0 option that
> signaled similar information.
>
> In the draft I’m referencing, it was my intention to provide a set of
> values that could be returned to indicate what has happened.   I think it’s
> a bad idea to provide anything more than that, because for example if you
> return a text string, that becomes an attack surface.   You can use it to
> trick the user into bypassing their security settings.
>
>
>

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 21 Dec 2016 18:29:18 GMT

> From: Ted Lemon <[email-masked]>

> It would be _nice_ if the browser, for example, could get some
> kind of positive, signed assertion that some authority has claimed
> that the domain in question is malicious (or whatever). 

As I wrote on Monday, the final paragraph of section 6 on page 18 of
https://tools.ietf.org/html/draft-vixie-dns-rpz-04
says:

  If a policy rule matches and results in a modified answer, then that
  modified answer will include in its additional section the SOA RR of
  the policy zone whose rule was used to generate the modified answer.
  This SOA RR includes the name of the DNS RPZ and the serial number of
  the policy data which was connected to the DNS control plane when the
  answer was modified.

It's not signed, but perhaps it could be with look-asside trust anchors,
although an ever growing forest of DLVs doesn't sound good to me.

Browsers and other interested applications would have to do more than
gethostbyname() or a modern equivalent to see those SOAs.  But if
browsers ever do any DANE, they'll need to do more than gethostbyname().

(perhaps that "will include" should be "MUST include")

Vernon Schryver    [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Dec 2016 14:01:23 -0500 (EST)

> (perhaps that "will include" should be "MUST include")

If the goal is to block the query, I think this is fine. I would prefer
a signed response of any kind as a marker we can keep to hold the
resolver operator accountable for their blocking actions.

If the goal is to block the answer, I think it would be much better to
move the original Answer RRTYPE into the Authority Section and use an
ENDS0 bit to signal RPZ was applied. That way, clients that understand
RPZ can see the censored results and do smart things - including ignoring
or accepting the censor - and clients that do not support understanding
RPZ will still be prevented from seeing the censored results for their
security.

Possibly an additional RRTYPE with a URL to a page explaining the
censorship would be useful to standarize as well. Having a "serial
number" of a policy is not very helpful for a user to hold an operator
responsible. It is important that we know the reason, as we've seen
many filter software doing things like filtering out the EFF or ACLU as
"porn site".

The important issue here is that DNS filtering is done for many valid
and invalid reasons. It is important that we give the consumers the
tools to see the difference. I'm fine with non-updated software/users
that cannot tell the difference to be blocked as-is for their
protection.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 21 Dec 2016 20:01:04 +0000

> RPZ is not the ideal, but it works, and goes beyond being deployable–it is

I am curious to understand how RPZ zone transfers are (intended to
be) secured.  It sounds like the reason for standardizing RPZ is
to allow interoperable sharing of policies via replication of zone
data, and so an appropriate security mechanism would seem to be
desirable here to authenticate the transfer of data from the RPZ
master zone.  Is there a related specification for that?

As a (long-ago) emigre from the then Soviet Union, I am loathe to
see the IETF standardizing scalable censorship mechanisms, however
well intentioned.  Let's hope that skepticism of such "progress"
can evolve without the personal experience of having lived under
a totalitarian regime.

Once the infrastructure that RPZ makes possible is deployed at
scale, it will surely become increasingly difficult to bypass.
This proposal is a major step towards building the Great Firewall
of <your CountryName>, and should I believe be resisted.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Dec 2016 07:36:40 +1100

In message <[email-masked]>, Viktor Dukhovni writes:
> > RPZ is not the ideal, but it works, and goes beyond being deployableit
> is
> > deployed.
>

The are just zones.  You secure them the way you secure any other
zone transfer.  Just because they contain RPZ data doesn't make
them any different.  You setup a account with a provider and use
TSIG.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 21 Dec 2016 15:37:34 -0500

> master zone.  Is there a related specification for that?

Are you looking for RFC 2845, "Secret Key Transaction Authentication for
DNS (TSIG)"? That authenticates the transaction but the contents of the
zone is transferred in the clear. (I don't think there are any servers
that implement DNS-over-TLS for zone transfers.)

-- 
Robert Edmonds

---

From: Nolan Berry <[email-masked]>
Date: Wed, 21 Dec 2016 20:44:59 +0000

Hello,

I will keep my feedback short and to the point.  We have implemented RPZ across our resolvers and it has been a fantastic tool to stop botnet C&Cs and outbound DDoS attacks.  I just wanted to say it has been an extremely valuable tool to us here at Rackspace and provide some positive feedback since this thread seems fairly negative.

Nolan Berry

Linux Systems Engineer

DNS Engineering

Rackspace Hosting

________________________________
From: DNSOP <[email-masked]> on behalf of Viktor Dukhovni <[email-masked]>
Sent: Wednesday, December 21, 2016 2:01 PM
To: dnsop
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Wed, Dec 21, 2016 at 12:39:55PM -0500, Matthew Pounsett wrote:

> RPZ is not the ideal, but it works, and goes beyond being deployable-it is
> deployed.

--
        Viktor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Dec 2016 21:45:50 +0100

On Tue, Dec 20, 2016 at 10:16:58AM -0500,
 tjw ietf <[email-masked]> wrote 

> document current working behavior in the DNS (for the past several years).
...
> This starts a Call for Adoption for draft-vixie-dns-rpz

Because there is a huge risk of misuse of this technique (for
censorship), and because the current draft has no warning about these
risks, I disagree with adoption by the WG. I know that adoption does
not mean that the document is perfect, and that warnings about the
risks could always be added during the WG work on the document but it
is too important to rely on possible future changes. I don't want this
document to be adopted before there are clear explanations of the
risks and consequences. The work we do at the IETF has consequences
(if not, we should shut down the working group and go fishing or
gardening.) We need to consider these consequences, not to wash our
hands saying "we just describe a technique, we are not responsible for
its use". [Speaking of this responsability, the draft
draft-irtf-hrpc-research is in Research Group Last Call in the HRPC
research group. Reviewe welcome.]

Regarding the "people are doing it anyway, better to publish a RFC
than to have proprietary variants" argument, I think we should also
consider the strategical risks for the DNS: lying resolvers train
people to distrust the DNS, to move to alternative systems which have
their own dangers and are not always well-designed.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Dec 2016 21:47:39 +0100

On Wed, Dec 21, 2016 at 08:01:04PM +0000,
 Viktor Dukhovni <[email-masked]> wrote 
 a message of 22 lines which said:

> be) secured.

It is covered in section 12.3 of the draft (and in several other
places). Basically, TSIG.

+1 for all the rest of your email.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 21 Dec 2016 22:12:52 +0100

On Wed, Dec 21, 2016 at 10:04:38AM -0500,
 Suzanne Woolf <[email-masked]> wrote 
 a message of 54 lines which said:

> If the question is “Does the existence of an Informational RFC mean
> people will think the IETF is endorsing or promoting a technology or
> practice, and are they more likely to use it as a result?” the
> answer is pretty subjective and tends to be “It depends”— on the
> technology, on whether the document includes warnings about
> shortcomings and side effects, [...]

OK but, precisely, there is no such warning in the current draft.

Publishing a document without warnings and saying "we did not endorse
it, we just published a description" seems to me on the verge of
hypocrisy.

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 22 Dec 2016 09:10:45 +0100

Moin!

> the complaints about operator participation in the IETF go back decades.
So you don't want operator participation in the IETF?

> in fact, there are operator driven fora for just such activities, DNS-OARC
DNS-OARC AFAIK isn't about producing documents

> this draft actively destroys trust in the DNS, which reduces trust in the
I fail to see that and remember to most people the Internet these days is
delivered by large operators, so if you want to get stuff deployed at scale
you have to work with them. DNSSEC adoption on the recursing side e.g was
non existent until Comcast and later Google decided to do validation. Now
it is double digit percentage of all clients sitting behind an validating
resolver.

> is that really what you want out of the IETF?
I want the IETF to be relevant and the stuff of documents we produce to
actually being deployed on the Internet.

So long
-Ralf

---

From: Patrik Wallstrom <[email-masked]>
Date: Thu, 22 Dec 2016 12:17:51 +0100

On 2016-12-21 21:44, Nolan Berry wrote:
> Hello,
> 
> 
> I will keep my feedback short and to the point.  We have implemented RPZ
> across our resolvers and it has been a fantastic tool to stop botnet
> C&Cs and outbound DDoS attacks.  I just wanted to say it has been an
> extremely valuable tool to us here at Rackspace and provide some
> positive feedback since this thread seems fairly negative.

<rewritten to greater effect in order to polarize the discussion even more>
I will keep my feedback short and to the point.  My non-democratic
country have implemented RPZ across our resolvers and it has been a
fantastic tool to stop free speech, improve national security and
minimize the distribution of disinformation.  I just wanted to say it
has been an extremely valuable tool to us here for our government and
provide some positive feedback since this thread seems fairly negative.
</>

Even shorter, RPZ might be a good tool, but definitely not something
that the IETF should promote in any way without a big enough warning
sign that there are dragons lying around.

---

From: "John Levine" <[email-masked]>
Date: 22 Dec 2016 15:32:12 -0000

>sign that there are dragons lying around.

Assuming we published such a warning, can you tell us whose behavior
that warning might change, how the behavior would change, and why?

I have to say I'm baffled at arguments that boil down to "someone
might do something bad with this, so we'll pretend it doesn't exist."
By that standard, we wouldn't have published DNS, TCP, or IP.

R's,
John

PS: I am reminded of the era of US prohibition when bottles of grape
juice and packets of yeast were sold with with a label WARNING: DO NOT
ADD YEAST TO JUICE AND PUT IN A WARM PLACE FOR SEVERAL DAYS BECAUSE AN
ALCOHOLIC BEVERAGE WILL RESULT.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Dec 2016 10:38:57 -0500

> By that standard, we wouldn't have published DNS, TCP, or IP.

Indeed, SMTP is frequently used by scam artists to sucker people into 419 scams.   AFAIK there is no warning about this in the security considerations for any of the recent updates to the protocol.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 26 Dec 2016 21:36:44 -0500

Hi,

I've read this thread up to date. Reading the draft, a few minor things
occurred to me which I think might be small improvements, but I could be
wrong as I'm sure others have studied this more than me. And perhaps some
more warning should be sprinkled into it. But, when I get to the bottom
line, I believe that something reasonably close to it should be published
as an Informational RFC. I think it should be adopted by the WG. If not, it
might be best submitted as Independent, in which case the IESG will ask the
DNSOP WG for its comments. Either way, there will be the same political
argument in the WG which - as far as I can see form the comments so far -
favors publication. I think a higher quality draft would result if the
draft was processed through the WG.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Tue, Dec 20, 2016 at 10:26 AM, Suzanne Woolf <[email-masked]>
wrote:

> The discussion already on the mailing list has shown a number of views on
> the legal and ethical implications of using RPZ, or publishing an
> Informational RFC about it.
>
> In the past, where there has been controversy about similar issues, the WG
> has sometimes declined to adopt a draft. If the draft had been adopted as a
> WG work item, the WG may have asked that the draft be modified to reflect
> those concerns. Sometimes the consensus has been to regard them as out of
> scope. Sometimes there’s been no way to get to consensus on a draft, and
> the WG involved hasn’t advanced it for publication.
>
> Ethical and legal issues, including those around DNS names and DNS
> operations, are complex and “the truth” varies widely with circumstance and
> jurisdiction, both of which tend to be determined outside of the IETF.
>
> If you feel you must comment on those aspects of RPZ, please keep it
> brief, avoid unsustainable generalizations,  and state clearly whether you
> support adoption, oppose adoption, or support adoption with changes you’re
> willing to work on.
>
>
> thanks,
> Suzanne
>
>

---

From: Scott Schmit <[email-masked]>
Date: Wed, 28 Dec 2016 23:06:37 -0500

On Tue, Dec 20, 2016 at 04:35:48PM +0000, Ray Bellis wrote:
> with that

Why?  How does this help the "good guys" (define that as you wish)?

I'm seeing how it really helps governments cheaply create and enforce
the creation of national internets -- especially with the walled garden
features.  Are those the good guys to you, or are there other benefits?

I'm also seeing how, if hijacked, the walled garden feature makes it
trivial to distribute malware to large numbers of users.

> enhancements which could be under IETF change control.

If this is being submitted to the WG, this document will already be
under IETF & WG change control.  If that's not the intent, then the
document should not be adopted.

-- 
Scott Schmit

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2016 05:45:59 -0000

>features.  Are those the good guys to you, or are there other benefits?

Please see the previous gazillion messages from people who are using
RPZ in production to keep malware away from their users.

Also see the previous gazillion messages noting that governments do
all sorts of DNS censorship now and don't need RPZ.

Could you explain in more detail why you don't believe operators will
continue to use RPZ to protect their users, and why you think hostile
actors will do things with RPZ that they couldn't do now?

R's,
John

---

From: Richard Clayton <[email-masked]>
Date: Thu, 29 Dec 2016 12:43:15 +0000

In message <[email-masked]>, John Levine
<[email-masked]> writes

>all sorts of DNS censorship now and don't need RPZ.

Much DNS censorship in the UK (regimes vary) is only implemented by the
largest ISPs because only they have been able to find the necessary
engineering time (when you operate at scale it's not just about setting
a config option...)

The UK Government (who pressurise the ISPs to block child sexual abuse
images, some file sharing sites and who have grandiose plans to have a
centralised list of malware URLs) tends to be happy because 5 ISPs
covers about 95% of the population...

Everyone involved understands that there isn't at present a turnkey
application that the other 5% (and indeed all the in-house corporate
systems) could deploy.... so this also makes the people who don't want
the Government messing with their DNS results happy as well because
anyone who rolls their own system pretty much opts out.

>actors will do things with RPZ that they couldn't do now?

I can foresee Governments taking IETF standardisation of RPZ (that will
be their words) as a way of pressurising those who have not yet deployed
it to do so -- using lists supplied by them.

So although deploying RPZ does a reasonable job of papering over the
cracks in our response to cybercrime I think that on balance it's too
dangerous a tool for the IETF to wish to bless in any way -- it's poor
social hygiene to standardise these types of tools.

I also note from reading the draft that this blessing will freeze in
some rather ugly design (with the authors arguing that the installed
base cannot adjust to something cleaner). If the IETF must do anything
in this space then documenting an interchange standard for DNS related
badness (with annotations to hint at how this badness might affect a
resolver) would seem better engineering and rather less dangerous.

- -- 
Dr Richard Clayton                               <[email-masked]>
Director, Cambridge Cybercrime Centre                mobile: +44 (0)7887 794090
Computer Laboratory, University of Cambridge, CB3 0FD   tel: +44 (0)1223 763570

---

From: Scott Schmit <[email-masked]>
Date: Thu, 29 Dec 2016 11:06:03 -0500

> actors will do things with RPZ that they couldn't do now?

I was specifically asking about the redirect/record replacement
behavior, not the nxdomain/blocking behavior.

-- 
Scott Schmit

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2016 16:38:26 -0000

>behavior, not the nxdomain/blocking behavior.

Providers routinely use sandboxing to quarantine infected users both
to protect their other users (malware can't contact C&C) and to force
them to do something about it, since they can't see anything other
than web sites with cleanup tools.  

I've talked to providers who tell me that this is the least bad way
they've found to get their users to clean up infected boxes.  Even if
a provider could afford to calli them on the phone, it doesn't work,
first because users not unreasonably think it's a scam, and second
because the malware doesn't bother them, only other people, so they
blow off advice to fix it.

So I reiterate the same two questions.

R's,
John

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 29 Dec 2016 18:15:39 GMT

> From: Richard Clayton <[email-masked]>

> systems) could deploy....

I do not understand that.
If the command `nslookup -q=txt -class=CHAOS version.bind` to a UNIX
shell or Windows command prompt on your desktop says anything about
BIND, then chances are good that you are already using one of the
turnkey applications that in-house corporate systems and others have
already deployed and could configure.  Even if there is no sign of
BIND9 from that `nslookup` command, the odds are good that the recursive
server you use has an RPZ taint or will have within months.

> social hygiene to standardise these types of tools.

While I understand how a reasonable person can hold that position,
I think the papered cracks are not only less bad, but the best that
can be hoped for in the real world.

> base cannot adjust to something cleaner). 

That is not the intended meaning of the draft.  Instead it tried to
acknowledge the extreme difficulty of changing an installed base.
Words that convey that intended meaning would be appreciated.

---

From: william manning <[email-masked]>
Date: Thu, 29 Dec 2016 13:51:48 -0800

"lets standardize this 'cause everyone does it"  sounds like the medical
community should have standardized on whiskey & leaches & coat hangers
because thats what everyone did.  if this work does proceed, i'd like to
insist that it carry a disclaimer that it is designed specifically for
closed networks and is not to be used in the Internet.
Indeed, thedraft is very clear this is for enclaves and not for open
Internet use.

/Wm

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Dec 2016 17:25:03 -0500

On Dec 29, 2016, at 4:51 PM, william manning <[email-masked]> wrote:
> i'd like to insist

Can you explain what you mean by this from a process perspective?

---

From: joel jaeggli <[email-masked]>
Date: Thu, 29 Dec 2016 18:30:06 -0800

> closed networks and is not to be used in the Internet.

this sounds like an aplicability statement to be included in the
introduction.

> On Thu, Dec 29, 2016 at 10:15 AM, Vernon Schryver <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > From: Richard Clayton <[email-masked]
>     <mailto:[email-masked]>>
> 
>     Vernon Schryver    [email-masked] <mailto:[email-masked]>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dnsop>
> 
> 
> 
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 31 Dec 2016 20:27:32 +0000

> actors will do things with RPZ that they couldn't do now?

If providers have been, are now, and are going to keep using
mechanisms like RPZ, for their own internal reasons, sans any
"standard", why is there a need to make it easier for outside forces
to pressure providers to use such mechanisms to exert control over
their users rather than protect them from harm?

This technology is not ethically neutral, and some care is I think
appropriate to avoid harms.  It is I think prudent to broaden the
analysis beyond "Once the rockets are up, who cares where they come
down? ..."[1]

Though the irony does not escape me; let a hundred flowers bloom...

-- 
	Viktor.

[1] http://www.songtexte.com/songtext/tom-lehrer/wernher-von-braun-3c72d1f.html

---

From: Ted Lemon <[email-masked]>
Date: Sat, 31 Dec 2016 17:00:39 -0500

On Dec 31, 2016, at 3:27 PM, Viktor Dukhovni <[email-masked]> wrote:
> why is there a need to make it easier for outside forces

There is no _way_ to make it easier for said outside forces to pressure providers.   They have the force of law on their side.   What we do makes no difference in that arena.   The arena in which it _does_ make a difference is protecting people from losing their homes because they got suckered by some malware that got into their personal records on their computer.

IOW, the argument you are presenting has nothing to do with the choice that faces us.   If you want to make the case for rpz being a bad thing, the argument you should be making would have to show why protecting people in this way is the wrong solution to the problem, and why some other solution to the problem (e.g., a blacklist in the browser) is less bad.

Can’t we have that conversation, instead of these repeated assertions about things over which we have no control?

---

From: Warren Kumari <[email-masked]>
Date: Sat, 31 Dec 2016 23:32:02 +0000

On Sat, Dec 31, 2016 at 5:00 PM Ted Lemon <[email-masked]> wrote:

> There is no _way_ to make it easier for said outside forces to pressure
> providers.   They have the force of law on their side.   What we do makes
> no difference in that arena.   The arena in which it _does_ make a
> difference is protecting people from losing their homes because they got
> suckered by some malware that got into their personal records on their
> computer.
>

Another arena in which we have some control is how well implemented and
interoperable the feature is -- if we document RPZ properly then,
regardless of why it is being deployed, at least it will behave
deterministically across implementations.

RPZ is already implemented in nameserver software -- if the feature exists,
I'd like it to work the same wherever it gets uses, and not cause
collateral damage...

W
P.S / full-disclosure: I happen to use RPZ, and have for a number of years
-- I run a number of (personal) mailing lists on my own mailserver, and use
a number of RPZ feeds (e.g Spamhaus' DBL) for spam mitigation.

>
> IOW, the argument you are presenting has nothing to do with the choice
> that faces us.   If you want to make the case for rpz being a bad thing,
> the argument you should be making would have to show why protecting people
> in this way is the wrong solution to the problem, and why some other
> solution to the problem (e.g., a blacklist in the browser) is less bad.
>
> Can’t we have that conversation, instead of these repeated assertions
> about things over which we have no control?
>

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 1 Jan 2017 05:36:36 +0530

> a number of RPZ feeds (e.g Spamhaus' DBL) for spam mitigation.

Are you thinking of DNSBL instead of RPZ?

		Mukund

---

From: Warren Kumari <[email-masked]>
Date: Sun, 01 Jan 2017 00:31:46 +0000

> Are you thinking of DNSBL instead of RPZ?

Nope.
This is an older page, but has more readable information:
https://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone-rpz
More info:
https://www.spamhaustech.com/protecting-networks/security-solutions/dns-rpz/rpz-zone-transfer/

root@vimes:/etc/namedb/rpz# wc -l ~/tmp/rpz.spamhaus.org.text
3316563 /home/wkumari/tmp/rpz.spamhaus.org.text

This contains things like:
smalbany.academy.rpz.spamhaus.org.            300 IN CNAME      .
*.smalbany.academy.rpz.spamhaus.org.          300 IN CNAME      .

My named.conf contains:
   response-policy {
       # Rewrite all responses to blackhole.ne-where.com, which is 127.0.0.2
       zone "rpz.spamhaus.org" policy CNAME blackhole.ne-where.com;
      };

and then I have a postfix access file:
root@vimes:/etc/postfix# more access
# REMEMBER: Run  postmap hash:/etc/postfix/access to rebuild this.
#
# THIS FILE MANAGED BY PUPPET!

192.0.2.1   REJECT This domain is listed in an RPZ zone.
127.0.0.200   REJECT This domain is listed in an RPZ zone.

(yup, the comments are wrong...)
This has been working nicely for me with (so far) no false positives.
Because I have the RPZ zone locally I'm not leaking private info by doing
DBL lookups, it is nice and fast, etc...
It cut down on my sysadmin work drastically, and I ended up disabling
spamassassin because it wasn't needed any more...

W