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

Anne Bennett anne at encs.concordia.ca
Thu Oct 13 01:28:33 UTC 2016


>>   "... ignore DNSSEC.  The result of "BREAK-DNSSEC" at DNS
>>   clients using DNSSEC is functionally similar to an RPZ
>>   NXDOMAIN policy action;"
>>     I'm not at all sure I understand the above sentence
>>     correctly, but if I do, then I suggest:
>>   "... ignore DNSSEC for RPZ-modified queries even if otherwise
>>   configured to use DNSSEC; thus, the result of such a configuration
>>   is functionally similar to an RPZ NXDOMAIN policy action:"
>>     ... and if I don't understand correctly, perhaps some other
>>     clarification would be in order?
> The idea is that any changes by anything including RPZ break DNSSEC
> verification.  Connecting to web page using an A RRset that has DNSSEC
> records but that has been modified by RPZ seems likely to result in
> the browser showing something like
> "could not resolve www.example.com; try again?"
> Do you have a suggestion a better way to say that?

Possibly not without exposing to the world my woefully
inadequate understanding of DNSSEC.  :-/

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.

Am I mistaken?  Does the querying client receive the result
RRset *and* the DNSSEC signature, and *itself* check the
validity?  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?

Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
anne at encs.concordia.ca                                    +1 514 848-2424 x2285

More information about the DNSfirewalls mailing list