> > > I have proposed a method that would not change the RPZ response for a > > > non-DNSSEC client, but would add data for DNSSEC capable clients to be
I forgot to mention what I think is a completely upward compatible "fix" for RPZ+DNSSEC that requires no protocol or implementation changes anywhere and little installation work. In cartoon form, it is "If RPZ+DNSSEC hurts, then stop doing that." In other words, if your DNS clients verify and if they don't want to deny themselves answers when their resolver lies, then switch to a DNS resolver without RPZ on another IP address or port number. If your resolver uses BIND9, then it could switch selected clients to an honest view (not using RPZ) on port 53 and its current IP addresses based on client IP address or TSIG key. This is all yet another way of saying that if changes are required in the RPZ protocol before the current Informational draft is advanced, then it is months too early for a last call for any draft. Calls for RPZ protocol changes in the current draft even as small sounding as some sort of version signaling should be treated as calls to reject the draft. Perhaps ISPs and anothers running open or large scale DNS resolvers should be encouraged to provide resolvers without RPZ if they provide resolvers with RPZ. Because there are plenty of DNS resolver operators (not to mention policy zone vendors) who charge for their special policy zone recipes, this does not sound controversial. Vernon Schryver v...@rhyolite.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
