RPZ for reverse lookups ?

[m3047]

Yes. See below.

Another respondent expresses concerns about the danger of IP address 
blocking. The RPZ implementation (in BIND) includes options for setting 
triggers on the address returned with A and AAAA RRs (rpz-ip) and 
nameserver address (nsip). These kinds of actions are functionally 
distinct from triggers based on the query name.

On Sat, 24 Aug 2019, J Doe wrote:
> [...] Is it possible to re-write a response on a reverse lookup ?  For 
> instance, if I considered example.com a “bad domain”, can I write a RPZ 
> policy so that a reverse lookup of IP’s that map to example.com fails or 
> is blocked ?
>
> I know I can do this with a forward lookup to generate NXDOMAIN:
>
> ; Forward resolution of: example.com and subdomains generates: NXDOMAIN
>
> example.com        IN CNAME .
> *.example.com      IN CNAME .

I have to wonder what led us here and why it's so important to generate 
NXDOMAIN. There are plenty of ways to disrupt as well as out and out block 
access to an IP address which don't require resorting to DNS tricks, such 
as using a firewall, but let's see what we can do.

I suspect if you wanted to block an IP address, that rpz-ip is what you're 
looking for.

What you've got above prevents example.com from resolving to any address. 
So where did the address come from? Are you sure the evidence chain 
involves example.com and not something else (correctly or incorrectly) 
resolving to that address, or someone outright lying? Why would you assume 
that? (And as the other prior respondent points out, it has risks. Are the 
impacts of your proposed actions local in scope? Do you run a local 
passive DNS oracle?)

Let's say that example.com resolves to 10.9.8.7. In that case "dig -x 
10.9.8.7" will generate a query for 7.8.9.19.in-addr.arpa PTR records. A 
record like

     7.8.9.10.in-addr.arpa CNAME .

will generate NXDOMAIN in response to that query. You could be more 
explicit:

     7.8.9.10.in-addr.arpa PTR block.this.

If you were doing spam scoring based on the feature "does the FQDN the MTA 
declares as its identity match a reverse lookup on its address", either 
one of these would potentially fail. NXDOMAIN is generally an implied fail 
however, and could be due to infrastructure failures distinct and separate 
from imputed conduct; whereas the feature "anything that a reverse lookup 
resolves to block.this should be blocked" is explicit (and unambiguous 
until the .this TLD launches).

--

Fred Morris