[DNSfirewalls] Of RPZ, PTR, and NXDOMAIN

[Anne Bennett]

Vernon Schryver <vjs at rhyolite.com> responds to my questions:

>> Yes, I'm verbose this week, as I try to set up this new function!
>> Google is surprisingly unhelpful, which leads me to wonder how many
>> people out there are using RPZs...
> 
> Because RPZ is no longer an experimental or even new feature of BIND,
> I suspect that you would reach a larger fraction of RPZ users through
> one of the main BIND mailing lists such as bind-users.  Please see
> https://lists.isc.org/mailman/listinfo

I will do so; thank you for pointing me in the right direction.

>> (1) What do I do about queries for PTR records from a
>>     "quarantined" client (one matched by rpz-client-ip)?
[...]
>>     Hmm, can I pass through based on a QNAME match
>>     on in-addr.arpa or ip6.arpa?  I'll try that when I get
>>     back from my Christmas vacation.

> Why treat PTR records differently?  If you have reason to distrust
> the DNS clients at an IP address and so serve them false answers
> for record types other than PTR such as A, AAAA, MX, CNAME, TXT,
> and SRV, isn't prudent to do the same for PTR records?

I'm feeding them false answers in order to send them (when they're
using a browser, of course) to a web page where they can be informed
that they are in quarantine, and what to do to solve the problem that
led us to quarantine them.

Lying to them about PTR records seemed to serve no purpose, but...

> I think PTR records could be used in a DNS tunnel.

True.

> (Please note that I'm saying nothing about the added complexity in
> the RPZ code itself of adding qtype to the RPZ rules. )

Of course.  Please understand that I'm asking questions,
not criticizing.  I'm trying to understand how all this works
and is intended to be used, and to find out how much of what
I want to do is possible.

> More to the point, would the complexity for BIND users of including
> the original response record type in the trigger be worthwhile?

While I don't feel all that qualified to have an opinion on
that, I suspect probably not - mind you, if it were considered
useful, then I imagine that a syntax could be designed with
a suitable default to that people would indicate the original
response record type only if it mattered.

But be that as it may, for my purposes, if whitelisting
queries on in-addr.arpa or ip6.arpa works as expected, that
will be quite sufficient.  (Or, based on your reminding me
that DNS tunnels to C&C hosts are possible, I should whitelist
queries only for my own network's sections of in-addr.arpa
and ip6.arpa.)

As I said, my concern here is to clearly inform users of
quarantined hosts of what's going on, with a minimum of
unnecessary disruption to their functioning within our network
until they can be fixed.

> A synthetic, quarantine CNAME response to a PTR request might not
> be very useful, but a valid response PTR that does not match whatever
> the quarantining CNAME ultimately resolves into seems worse.

I'm not sure I can agree with you there, but I'll play with
my in-addr.arpa/ip6.arpa whitelisting idea, and see what
the result is.  If I do the whitelisting correctly, then
my in-addr.arpa/ip6.arpa whitelists will match my forward
whitelists, and the situation you describe would not arise.

> By the way, instead of quarantining with only a CNAME RPZ record,
> why not use a full set of A, AAAA, and PTR records?  Using RPZ to
> rewrite all matching responses to a CNAME is only the easiest to
> use tactic, and I think generally least desirable tactic.

I'll give that some thought and re-read the "format 3" document.

>> (2) When I quarantine a client such that all of its queries
>>     (except those for whitelisted sites) get a CNAME to a
>>     server under my control, then an NXDOMAIN (real) answer also
>>     gets translated to the CNAME.  I suppose this is logically
>>     consistent, preventing a quarantined client from learning
>>     anything at all, even the non-existence of a name.  But in
>>     practice, I think it could lead to unnecessary confusion.
>>     As far as I know, though, there's no way to match an
>>     NXDOMAIN response and pass it through.  Or is there?
> 
> As an end user or someone doing technical support, I think I'd be more
> confused by having only responses with some codes written.

Different people are confused by different, things, I guess. ;-)

> What would
> be the costs and benefits of the added complication of including the
> response status value in the rules?  (I'm assuming the proposal is not
> special for NXDOMAIN but would include all of the DNS response codes.)

Certainly if something were to be implemented, it would make sense to
include all of the DNS response codes, and I agree with your
implication that the slight benefit of possibly reduced confusion in
some cases is unlikely to be worth the cost of the added complexity.

Again, though, I was simply wondering whether I missed something (or
misconfigured something).  Apparently not, in this case.

> Please also note that while it is good to hear that RPZ is, as I
> hoped, at least potentially useful for quarantining "owned" end
> users, the motives for RPZ ran in the other direction.  The idea
> was to filter outside bad guys.

Of course, and I would like to convert my current scheme for
that (where my resolvers declare themselves to be masters for
the bad-guy zones and return an A record to my special web
server) to RPZ, which is much more elegant.  But as long as
I'm implementing RPZ, I can get the "quarantine information"
for free, and it happens to be easier for me right now to test
with the quarantining.  If I can get RPZ working reliably as I
expect it to work (or according to my modified expectations as
I learn to understand it better!), then it will be trivial for
me to convert my existing "protect my clients from bad guys"
code to populate an RPZ instead of reconfiguring named to add
and remove zones.

Thanks very much for taking the time to respond!


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