Vernon Schryver wrote:
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
i think we have to keep trying until and unless the co-chair say to stop.
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. ...
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. the resolver is a dns-aware application.
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.
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. i predict that the getdnsapi team would offer such hooks if there were an underlying protocol with knobs like that. obviously "dig" will always just print both the truth and the lies, and let /dev/stdout sort out the meaning.
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. i've been hooked up to networks with policy at the IP layer causing 8.8.8.8 requests to be rerouted to a local DNS server with advertising (NXDOMAIN substitution) support. considering that google's original motive for creating the 8.8.8.8 service in the first place was that various rDNS services were giving locally-faked responses to "www.google.com/A", i think this shows the slipperiness of the slope, in neon glowing detail.
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.
-- P Vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
