[DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-00.txt

[Vernon Schryver]

> To: Vernon Schryver <vjs at rhyolite.com>
> cc: dnsfirewalls at lists.redbarn.org
> From: Anne Bennett <anne at encs.concordia.ca>

> My understanding from the document was that RPZ is usually
> implemented by the recursive resolver, so if that name server is
> also configured to "BREAK-DNSSEC", it would return a modified
> RRset regardless of the fact that this result would not match
> the DNSSEC signature.  I had assumed that the querying client
> was *not* the entity doing DNSSEC validation, and that this
> client would therefore meekly accept the modified result sent
> by the resolving nameserver.

Given your assumption, that's right.  My assumption is that the
querying client is doing DNSSEC validation or at least expecting
the DO bit to be set.  Which assumption is right depends on the
client.

> Am I mistaken?  Does the querying client receive the result
> RRset *and* the DNSSEC signature, and *itself* check the
> validity?

That depends on the client.  There are also the DO and CD bits.  Please see
https://tools.ietf.org/html/rfc4035#section-3.2.1
https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Stub_resolvers

When rpz changes a response, BIND9 pretends that the DO bit was off
in the request including not copying it to the response.
(or is it the CD bit?--I forget).

In any case, RPZ is not affected as long as DNS clients don't do
their own validating, don't pay attention to the header bits, or
believe whatever the recursive server says, whether rewritten with
RPZ to block network abuse or adjusted to improve the user experience
with interesting offers or block things contrary to national interest,
civil harmony, or religious piety.
Or defend against attacks on DNS data by men in the middle.


>            If so, then perhaps:
>
>     Therefore, by default, DNS resolvers using RPZ avoid
>     modifying DNS results when DNSSEC signatures are available
>     and are requested by the DNS client.  However, when
>     the common "BREAK-DNSSEC" configuration setting is used,
>     RPZ-using resolvers do modify query results, even when this
>     renders them DNSSEC-invalid.  In such a case, a querying
>     client which checks DNSSEC will ignore the invalid result,
>     and will effectively be blocked from malefactor domains;
>     this behaviour is functionally similar to that caused by
>     an RPZ NXDOMAIN policy action.
>
> There may be a less wordy way to say it, but if I've understood
> correctly this time, perhaps that's more clear?

Those words are fine with me.
Does anyone have a supporting view or some other words?


thanks,

Vernon Schryver    vjs at rhyolite.com