RPZ for reverse lookups ?

J Doe general at nativemethods.com
Tue Aug 27 18:10:31 UTC 2019


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: someone at banned.example.com <mailto:someone at 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 <m3047 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190827/63995c82/attachment.html>


More information about the bind-users mailing list