> From: Paul Vixie <p...@redbarn.org> > well, yes, but a directive in /etc/resolv.conf saying what lies to > trust, or whether to trust all of them, or whether to trust none of > them, would be a way for a system operator or owner to set response > policy for all applications.
> if an application wants a different kind of lies than is the default in > /etc/resolv.conf, it will need API hooks to say so. That's what I meant. It could be done today with small, upward compatible changes to libresolv to allow the application to specify resolver IP addresses, port numbers, and TSIG keys. (and equivalently in Windows) (Note that TSIG keys in resolv.conf would help provide a trustworthy path to your trusted resolver for reasons unrelated to RPZ.) (well, getting libresolv to sign and check TSIG might not be that small.) > > On the other hand, there is already signaling that provides both DNS > > truth and lies. A UNIX shell command like `alias honest "dig @8.8.8.8"` > > implements kludge "signaling" to get the DNS truth, while straight > > `dig` gets the possible lie. > > alas, this is unreliable. A network that routes requests to 8.8.8.8 to inject DNS lies will also arrange to ignore or pervert any DNS-in-band tell-the-truth signaling. Without access to a trustworthy resolver, tell-the-truth signaling is useless because you can't trust it. If you have a trustworthy path to a trustworthy verifying resolver, then by definition you trust that resolver to do the things you want with RPZ and everything else, and so none of your applications need both answers. With a trustworthy resolver, you don't need in-band trugh signaling except for debugging, and all of the many people who have debugged RPZ installations have not needed more than log files and `dig` to different resolvers and resolver views so far. > > The SOA added by RPZ to the additional section is perfectly sufficient > > to signal the honest presence of an RPZ lie. > > well, yes. but it may be the law of the land in some countries that > citizens accept DNS lies, whereas foreign visitors can accept DNS truth. > so i'd like the protocol to carry both (lies and truth), with > policy-level digital signatures on the lies, to be sure they are coming > from the place we're expecting our lies to come from. No jurisdiction will allow foreign visitors to bypass local filters forever, because foreign visitors blab both the banned data and the banned tools. We've a very long history of this in print media. Recall that the Iron Curtain borders took an extremely dim view of smuggling subversive literature. And didn't Tailand recently sanction some foreigners for lese magesty in forgien on-line media? Isn't there talk about China blocking all tunnels including those of foreigners? Even with the acquiescence of regimes, there are insurmountable practical technical and non-technical issues in providing both RPZ filtered and raw DNS answers, configuring applications, and ensuring that citizens don't get foreign, uncensored versions of applications. It's one thing for a regime to allow foreigners to use foreign services (which I claim never lasts), and quite another thing for in-country operators to expect government censors to understand and believe that citizens can't use the truthful results in DNS responses. If you were a DNS operator in China, would you ever allow your resolver to give truthful answers about some domains in any form or in response to any signaling?--of course not! We're seeing something like this happen with the European demands that the "rights to be forgotten" apply accross borders. Vernon Schryver v...@rhyolite.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop