> From: Paul Vixie <p...@redbarn.org> > some time before bad people get around to using dnssec to bypass rpz, > the spec will have to evolve to allow new signalling ("i want to hear > both the truth and the lie, and please sign the lie with our shared key > so i'll know it's from you").
I disagree. The last year has shown there there is limited appetite in the IETF for RPZ work A second issue concerns the use and purpose of the DNS. No applications that are not DNS debugging or forensic tools want both DNS truth and lies. All ordinary applications want an IP address and sometimes application protocol data such as in SRV, MX, TLSA, and TXT. They don't want and generally can't deal with multiple answers, as demonstrated by the very few applications that look past the first IP address from gethostbyname() (or modern replacements) even when the first IP address fails. Except for debugging or forensic tools, the application code itself should not and even if the IETF says it should, will not care about more than the first usable DNS result. Users of applications might want either truth or RPZ lies, but not both except for debugging and forensics. Those user preferences can vary depending on the application. A user of ssh might want the truth, because ssh has its own authentication system that is more secure than DNSSEC. The same user might choose RPZ filtering for smtp and http. To facilitate such user choices, it would be good if applications could tell stubs to use an alternate /etc/resolv.conf. 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. (Note that a single system can host both honest and RPZ resolvers. BIND with views can distiguish requests for truth from requests for lies with TSIG keys and answer appropriately. You can include TSIG keys in dig commands.) That kludge, dual-dig "signalling" would work with future RPZ installations with real "give me both" signaling, old RPZ installations, and covert DNS liars. Even if a future version of RPZ has real "give me both" signaling, you will always need and will reach first for dual digs. The SOA added by RPZ to the additional section is perfectly sufficient to signal the honest presence of an RPZ lie. Vernon Schryver v...@rhyolite.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop