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 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.comIN 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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
