On 21 December 2016 at 12:29, Ted Lemon <[email protected]> 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.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
