[RPZ] Answering my own RPZ question
vixie at isc.org
Thu Jan 5 19:20:32 UTC 2012
On 1/5/2012 4:14 PM, Vernon Schryver wrote:
>> From: Bill Owens <owens at nysernet.org>
>> And unlike the earlier versions it includes a reference to this situation:
>> 3 - Subscriber Behavior
>> RPZs must be primary or secondary zones. They can only be searched in a
>> recursive server's own storage. By default, policies are applied only on
>> DNS requests that ask for recursion (RD=1) and which either do not
>> request DNSSEC metadata (DO=0) or for which no DNSSEC metadata exists.
> Thanks. Either that document or the code needs to be changed.
the code is wrong. bcc'ing a member of the bind9 dev team, as promised.
>> So, there we have it. I have nowhere near enough coding ability to
>> tell which version of the spec is implemented in current BIND, though
>> a few minutes of staring at the stuff in lib/dns doesn't seem to turn
>> up any references to RPZ and DNSSEC near each other. ...
> All versions of RPZ in BIND have one or more statements like this:
> * Turn off DNSSEC because the results of a
> * response policy zone cannot verify.
> client->attributes &= ~NS_CLIENTATTR_WANTDNSSEC;
> That statement makes BIND act as if the client had not asked for
> DNSSEC. I think we need to change the document to match the code
> instead of the opposite so that domain name cannot decide whether
> their data is rewritten.
no. dnssec really is a get-out-of-jail-free card for malicious domain
names. we'll fix this some day, probably by adding a new EDNS option to
allow a stub to signal its desire for policy information, and the
recursive would return the truth, the dnssec metadata that validates the
truth, and a signed indication of what the policy based answer would be.
this will require SIG(0) signalling since servers do not otherwise have
signing keys. and it's a long term project that will have to involve
IETF. so, meanwhile, we'll use this "hole" in RPZ as an incentive to get
more dnssec signing to happen, even if the signing is by bad people
doing bad things with bad domains.
More information about the DNSfirewalls