Implement Response Zone Policies (NXDOMAIN) for end-user performance increase

I saw this feature request and feel that it is worth my adding a comment here rather than a brand new one.

I have recently become interested in pi-hole - or something like it - as a possible delivery mechanism for RPZ in the SOHO user space (disclosure I work for a company - ThreatSTOP - that does DNS Firewalling and offers a commercial DNS service blocking malware ).

So let me start with a quick description of RPZ as it is implemented by Bind and other DNS servers. RPZ is a way to change the DNS response to a request for a domain that hits certain criteria. One of the responses can be NXDOMAIN (i.e. no answer) other options include an A record (which is more or less what pi-hole does), a CNAME redirect (redirect bad.domain to warning.page) and some others including (PASSTHRU - i.e. no action). RPZ is also a mechanism for transferring block/redirect data to remote DNS servers using zone transfers with an automatic update timer (the zone TTL).

Note that RPZ can have rules that act not just on the domain name, but also the IP address it resolves to (and on the domain's nameserver names/ip addresses).

It seems to me that pihole could usefully benefit from some of the features of RPZ not just the NXDOMAIN vs redirect thing.

Firstly a number of organizations make block data available as an RPZ. Some of these are free, some (e.g. ours) are paid products. It would be worth writing code to allow those sources to be imported into pihole (the code for retrieving and importing domain data is literally a few lines of shell/sed script plus the dig command).

Secondly it would be useful to have the "act on IP address" capability as well as domain capability. Since you are hacking dnsmasq you might want to consider adding this?

Thirdly and relatedly while the load of serving a default "blocked" webpage instead of nothing is not that great for a single user, at a larger, enterprise scale, it can be - especially if the page is being served to a bot that is trying unsuccessfully to call home.

As far as I recall, Domain Name Service Response Policy Zones (DNS RPZ) are just a method allowing us to provide alternate responses to queries. It's been officially called like this in BIND9.8+ and sometimes even referred to as "DNS firewall" (which I find a bit confusing, but tastes differ).

Being based on dnsmasq as our internal DNS resolver, we did not attack this feature request by implementing a new zone handling method. Instead, we use the existing machinery that loads HOSTS entries into the resolvers cache. For making them persistent, we set their TTL value to infinity as we don't expect them to expire while the DNS server is running.

If a user decides to chose the legacy way of blocking, we register for each domain A and AAAA records that will be served on any query of this domain. If a user instead set to use NXDOMAIN blocking, then we populate the cache not with A or AAAA records, but with negative records, such that dnsmasq can immediately reply to corresponding requests with NXDOMAIN (as if it would have tested it before and got told that the record does not exist).

I don't really get what you suggest to serve instead of A and AAAA or NXDOMAIN blocking? Right now, I don't see any real benefit a CNAME would bring.

I'm not sure how this could be any different to just a list of blocked domains. Can you provide an example for a free list?

This may or not be useful, what you you expect such an action could be? Running a script or sending out an alarm email? However, a new feature request seems mandatory for such a thing as many details seem to need clarification.

I don't really understand your suggestion here. Do you mean serve the blocking lists using A and AAAA such that (human) users see a blocking page while having a second list that blocks additional domains for which NXDOMAIN would be served?

1 Like

Great, this is what I want to use. How can I change my FTLDNS install to this one?

Forgot to quote...

You can find instructions here:

https://docs.pi-hole.net/ftldns/configfile/#blockingmode

Thx, but I don't want NXDOMAIN I want to use the simplelist to cut down memory used by my 3mil blocklist.

I'm already on
Pi-hole version is v3.3-181-ga7e7680 (Latest: v3.3.1)
AdminLTE version is v3.2.1-195-g4355bde2 (Latest: v3.3)
FTL version is vDev-fa0045e (Latest: v3.0)

The simple-list format is NXDOMAIN, DL explains the system at Simple list format for gravity.list and black.list by DL6ER ¡ Pull Request #259 ¡ pi-hole/FTL ¡ GitHub as noted above.

To avoid misunderstandings: The new simple list format does not prescribe which blocking mode you are using. With it, you can use all of the documented options Jacob already linked above. In fact, the inverse is true: Without the simple lists, you can only use IP blocking, but with the new format you have the increased flexibility to use whatever you prefer.

Note that there will be another blocking mode coming up soon which may be a bit better than NXDOMAIN.

1 Like

Thanks for the clarification, I was under the assumption that the NXDOMIAN would cut the gravity.list down by only having the domains listed once instead of twice (once for IPv4, once for IPv6).

Thank you for clarify this.
How could I use the simplify list now? I'm allready on FTLDNS branch. To use simple list must I set BLOCKINGMODE=NXDOMAIN in /etc/pihole/pihole-FTL.conf and then it works or musst I change the branch to FTLDNS-gravity-simplelists and when I need to change how I do that?

Sorry for lot of questions...

"Just use them". With the recent FTLDNS beta you won't need to set or change anything. pihole -g should already create /etc/pihole/gravity.list in simple lists format for you and FTLDNS should use it.

NXDOMAIN along with several other blocking modes will be introduced with v4.0.

1 Like