McTim,

At 2017-04-11 12:52:58 -0400
McTim <[log in to unmask]> wrote:
> 
> On Tue, Apr 11, 2017 at 12:05 PM, Niels ten Oever
> <[log in to unmask]> wrote:
> > Hi Milton,
> >
> > Great you're following this. I think the design of a system can have
> > some properties that makes is harder or easier to infringe on rights. To
> > make the analogy to spam: when I receive spam in my spamfolder, I can
> > still read it. Spam that is blocked, I cannot read.
> >
> > With RPZ I think there is a risk that content get's blocked because
> > people don't like it, not because it's malware. And it does so without
> > the consent of the user, or even without informing them.
> >
> > Why could the system not be designed similar to the warnings with TLS in
> > the browser so there would be a red screen: THE LINK YOU'RE FOLLOWING IS
> > PROBABLY MALWARE (only continue if you verified the source) ?
> >  
> 
> Because RPZ is meant to limit cruft from hitting your recursive nameserver.

There were discussions along these lines in the dnsop working group,
IIRC.

The idea is to include information in the replies from your resolver
which the user's machine can then use to inform the user of modified or
blocked sites.

There are a lot of potential downsides to this approach, but also some
possible benefits. While vendors don't have a lot of motivation to do
this (especially in a world where people get most of their Internet
from phones given to them from their mobile provider), I can imagine a
world where the EU mandates that RPZ changes be published to end users
in the DNS protocol itself.

Cheers,

--
Shane