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

[Vernon Schryver <[e-mail]>]

> From: Philip Homburg <[e-mail]>

> 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathrow

>4) DNS is not really private so Google may offer their DNS services over HTTPS
> 5) Governments may force Google to block popular sites, so users switch to
>    other DNS resolvers, again over HTTPS.

See https://developers.google.com/speed/public-dns/docs/dns-over-https
but I don't know how clients bootstrap that API without classic DNS.

Regardless of that, what if Heathrow Airport deploys HTTPS proxies to
block child porn, drug, terrorist, and malware web pages as well as
attempts by corrupted laptops and smart phones to bypass blocks on
port 53 and reach evil or merely unfiltered DNS/HTTPS servers including
those run by Google?


> In that sense I don't care that much about the more philosophical arguments
> arguments against rpz. If you care about DNS, run a local DNSSEC validating
> resolver that does roadblock avoidance and possibly falls back to 
> TLS or HTTPS to some trusted resolver.

Everyone should do that, if necessary without knowing they're doing
it, such as with the help of validating resolver code in broswers.
Something like that is required to stop the fraud that is commercial PKI.
(Google's two alternatives to DANE are great for the Alexa 500 and
maybe the Alexa 5000, but useless or worse for the Alexa 100,000,000.)

   ..............

] From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <[e-mail]>

] But I think the document itself is very useful, so it would be nice if
] it's made more publicly available in other form, e.g., some
] white-paper kind or at a popular blog site.

That will happen whether or not the text gets an RFC number.  (If it
doesn't get a number, of course I will remove the IETF mumbo-jumbo.)
The current de facto standard status of RPZ suggests finding sufficient
popular web sites for publication is not an issue.

Disclaimer: Many people including the other author want the draft to
get an RFC number.  But my considered reaction the threats to not
publish, the demands to not publish without what I see as ill conceived
or worse fixes, and various other sentiments is more like
"Please don't throw me in the briar patch."
https://www.youtube.com/watch?v=S7tyhpWiZyM


]                                 its not just ugly 

Yes, RPZ is a nasty, ugly, evil kludge that would not exist if I were
in charge of the Internet.

]                                                   but also has some
]   inherent flaws, such as that not all domain names can be represented
]   due to length limitation.

Yes, but do you know of a real life example cannot be rewritten because
the RPZ trigger name would be too long?


]                              In fact, not all existing implementations
]   of RPZ-like feature use this form as the primary way of rule
]   configuration (unbound is one example I happen to know of, and from
]   a quick look knot resolver also seems to adopt its own configuration
]   syntax).

Distributed blacklisting is one of or the most powerful aspect of RPZ.
I think (perhaps mistakenly) that the new blocking mechanism in
Unbound 1.6.0 lacks that aspect.

In addition, there is an RPZ patch for Unbound versions 1.5.4 through
1.6.0 that uses a separate daemon that acts like a slave master for
policy zones using AXFR/IXFR/NOTIFY.  However, I stopped maintaining
and deleted the patches for version 1.5.4 through 1.5.8 long ago.
Another caveat is that the work was for hire and so the daemon and its
interface .so are not open.  The patches to Unbound are open and have
been offered to NLnet Labs.


Vernon Schryver    [e-mail]