> From: Philip Homburg <pch-dnso...@u-1.phicoh.com> > 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?= <jin...@wide.ad.jp> ] 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 v...@rhyolite.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
