[RPZ] Answering my own RPZ question

Bill Owens owens at nysernet.org
Fri Jan 6 18:07:32 UTC 2012

On Fri, Jan 06, 2012 at 05:28:28PM +0000, Paul Vixie wrote:
> the fix is not to make policy enforceable in a paternalistic way, as in,
> add signalling for "this isn't the truth, but you can trust me". 

FWIW I agree completely, and am very happy to see that statement. But I don't think everyone will agree, and in fact I have a suspicion that what you're describing will be the direction OpenDNS goes. They have solidly established their dislike of DNSSEC but have said that they'll support it when it is established within the DNS community. I've always doubted that commitment because they face the same problem; if their users started to try to validate answers, the OpenDNS policy filtering would break down. 

Very recently they've introduced a new service they call DNSCrypt, based on Bernstein's dnscurve concept, that will allow their users to be reasonably assured of the authenticity of answers from the OpenDNS servers. But that isn't a problem that needs solving in the current world, which left a few people wondering why they'd gone to the effort.

My theory is that they'll build validation into the OpenDNS code on the outside face, push the answers through their policy filters, and rely on DNSCrypt to be able to say to their customers that the answers they're being provided are valid. That could work in their situation since all of their customers have already decided to trust OpenDNS exclusively for DNS services, and have specifically signed up for filtering.

I'm not as sure how that will fit with new services built on top of DNSSEC. If all of the DANE-enabled web browsers want to do their own validation, for example, it will clearly fail. But the DANE spec itself seems to be compatible with this sort of remote validation model, if I'm reading it correctly.

In principle, the same sort of thing could be done with BIND running RPZ, given a few behavior changes and presumably a standards-based solution between the resolver and the client, but I'm not sure that it would be worthwhile since the success of such a scheme, IMO, depends on a tight and exclusive relationship between the resolver and the client.

Personally I expect to use a DNSSEC-aware resolver and have my individual machines doing their own validation, so I don't anticipate getting any use out of RPZ - that's a shame, because it does have practical value, but so be it; I think that DNSSEC is the trump card. And I'm glad that RPZ is taking the high ground. . .


More information about the DNSfirewalls mailing list