Hi Noel and Fred, Thank you for your replies. I probably should have provided a bit of context about my situation.
I manage a small e-mail server for a client. While setting up support for the SpamHaus DNSBL, I read that SpamHaus prefers that people use a non-public (ie: not 8.8.8.8 / large cloud host DNS server) recursive resolver. I configured Bind 9.11.x to be a recursive resolver and got SpamHaus working with my MTA. I then learned about RPZ. I configured RPZ to block forward lookup of known bad domains - for instance, malware C2 servers and so forth, with the idea being that if the e-mail server was infected with malware it would fail forward resolution. I then wondered if I could configure RPZ to “work in reverse” - that is, to specify a DNS name that results after reverse lookup should result in functionality similar to NXDOMAIN. The idea behind this was that if a had a domain name or a TLD that I didn’t want to receive connections from, when the server performed the reverse lookup if it resulted in a domain with that TLD it would break, which would then cause my MTA to refuse delivery. Currently, my MTA will happily allow a connection if the reverse resolution to any name works. The reason I wanted this on the DNS name was that I then do not have to know all the IP addresses associated with that domain. So, if I receive a connection from: 1.2.3.4 when the MTA does a reverse lookup and it matches “example.org <http://example.org/>” the DNS server doesn’t complete the name lookup. In this case I am then specifying that anything that resolves to “example.org <http://example.org/>” should fail. With the example you provided with a PTR record, I would still have to know the IP addresses owned by a particular domain, which may change over time. I’ve been able to approach this in a different way. Instead of having everything break at the DNS level, I’ve configured a right-hand side block list (RHSBL), with the MTA. Now, when a reverse resolution is done if that domain name or TLD is found in the RHSBL, the connection is blocked. I have that applied to connections to the server as well as the envelope from address, so if someone connects from: banned.example.com <http://banned.example.com/> OR states the e-mail is from: some...@banned.example.com <mailto:some...@banned.example.com>, the e-mail is rejected. I think the major difficulty I was running into was trying to have DNS RPZ do everything. Thank you for the pointer to the RPZ mailing list - I will be joining that shortly Regards, - J > On Aug 25, 2019, at 12:54 PM, m3047 <m3...@m3047.net> wrote: > > Clarification on what DNS is... > > On Sun, 25 Aug 2019, m3047 wrote: >> 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 ? >>> [...] >> proposed actions local in scope? Do you run a local passive DNS oracle?) > > Strictly speaking, in DNS-speak the "reverse lookup of an IP..." is a PTR > lookup. The "reverse lookup of an IP mapping to example.com" is doing a PTR > lookup and matching it against example.com. I could be wrong generally, but > at least none of the RPZ features which I use generate additional DNS > traffic; an RPZ implementation which did would exceed my personal threshold > of least surprise. > > You might consider taking discussion of this to the RPZ interest list or > searching the archives: http://lists.redbarn.org/mailman/listinfo/dnsfirewalls > > -- > > 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
