Exclude certain LAN addresses from filtering

vamfoom · August 21, 2019, 8:52pm

This is the setup I'm using by having dnsmasq dhcp provide different DNS server to different hosts. I'm now adding a Windows Active Directory server. All the hosts that will be joining AD must point the DNS server at the AD DNS server or AD doesn't work. Now, Windows DNS must forward to somewhere and it can't do selective forwarding based on client.

Pihole needs to have the capability to exclude clients from filtering in order to integrate well with Windows AD -- to be able to exclude certain hosts from filtering.

jfb · August 21, 2019, 8:55pm

Can you use Pi-Hole as the upstream server for the Windows DNS? For all AD clients, since it appears that the only clients mapped to the Window DNS are not mapped to Pi-Hole.

DanSchaper · August 21, 2019, 9:02pm

Conditionally forward your AD clients from the Pi-hole to the AD DNS server.

borpin · August 21, 2019, 9:48pm

I would still like to see this feature added.

A simple 'whitelist' by local IP or MAC that allows DNS requests from those machines to bypass the PiHole filtering and just forward all requests / answer from cache.

I'm not using the DHCP of PiHole so the DHCP solution does not work for me.

theycallmetimmy · September 26, 2019, 12:15pm

If you have a MikroTik router, or any other router with the same capabilities, you could use a whitelisting rule for your IP addresses. I created some automated commands for my MikroTik which allows users to bypass filtering on the fly by visiting a specific URL.

I posted here Temporary bypass by IP address

DL6ER · September 26, 2019, 12:42pm

We are actively working on this feature:

github.com/pi-hole/FTL

Per-client blocking rules, intermediate CNAME path blocking and some more

pi-hole:development ← pi-hole:new/internal-blocking

opened 04:02PM - 18 Sep 19 UTC

DL6ER

+1355 -598

**By submitting this pull request, I confirm the following:** - [X] I have re…ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md). - [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. **How familiar are you with the codebase?:** ## 10 --- This pull request proposes extensive changes in the way FTL decides how and when to block queries. One result of our work is that we were able to **reduce overall memory requirements of the `pihole-FTL` process significantly** allowing for the size blocking lists solely being limited by the SD card and not anymore by RAM size. Another side effect is that our improved implementation now also allows for **client-dependent blocking** settings which became the tag of this pull request. Per-client blocking will allow you to independently tag - regex blacklist entries - exact blacklist entries - regex whitelist entries - exact whitelist entries, but also - entire adlists to groups and assign groups (also multiple) to individual clients. This allows you to, e.g., set up a group of blacklisted domains you only want to see blocked on Apple devices whereas you want to set up some whitelisted domains you need for properly working Windows devices. The same with adlists: You can specify that some of your adlists (maybe Windows telemetry blocking) to be used by a specific group of your clients in which you put your Windows computers whereas you don't add these adlists for Linux machines. Groups can also be used to enable or disable many domains as once, there is no need to remove entries from lists to disable them. In addition, clients can now be associated with these groups but will, obviously, only use enabled lists. Untagged (= no groups associated to them) clients are the default and use *all* enabled lists. In contrast, groups also provide an elegant way to disable (or reduce) blocking for individual clients. Just assign them to an "empty" group, that is a group not connected to any adlist or blacklist entry. Besides all the great advantages our new implementation brings, we do not want to hide the downsides. It was always of great importance for us to have Pi-hole being able to run on even the lowest-end devices such as the Raspberry Pi version 1. With our new implementation - and all the new logic that enables us to do much more now - performance restrictions seem to suggest that we slowly start to deviate from the lowest-end devices. Pi-hole will still run on such devices, however, many clients with complex per-client configurations or huge blocking lists or many regex filters (or any combination of these) will cause Pi-hole to maybe require a more beefy device to still meet your latency expectations. Having said all this, note that if you run Pi-hole in a normal household network (< 10 clients), use standard lists and no or only a few regex filters, there should be nothing to worry about for you. **Update 1** We were able to resolve the majority of the feared performance penalty with a clever vector implementation memorizing whether a specific client has queried a specific domain already before and what the result was. **Update 2** The traditional way to reload the information after changing the lists was to send a reload command (`SIGHUP`) to FTL. This had the (necessary) side-effect of clearing the entire DNS cache. ~~With this new version of FTL, the user can send `SIGUSR2` to only clear the domain-blocking cache.~~ The DNS cache itself stays intact and is **not flushed**. **Update 3** The signal for flushing only the domain-blocking cache (and reload the regex lists) has been changes to the unused `SIGRT0`. Use, e.g., `sudo kill -SIGRTMIN $(pidof pihole-FTL)`.

As this involves a large redesign of the DNS-level blocking algorithms, it will not make it into Pi-hole v5.0 where the beta testing phase is about to start soon.

Tntdruid · September 26, 2019, 2:51pm

@DL6ER any eta on beta?

DL6ER · September 26, 2019, 2:53pm

As you're asking in this thread: The v5.0 beta will not contain the mentioned feature. The code is still somewhat in motion and I don't expect it to converge until maybe the end of the year (this is no ETA).

We are basically ready for v5.0 and just waiting for the entire team to agree (this is no ETA, either).

Xdrinkn · September 26, 2019, 2:55pm

Oh wow this is huge keep up the good work. Was just wondering if it were possible to have this as some google.com requests, for example, should be block listed on some of my devices

Tntdruid · September 26, 2019, 2:55pm

Ah thanks, im ready to test

mypi · October 22, 2019, 9:30pm

Thank you for this thread. Please can I have some further info?

I am running Pi-hole version is v4.3.2 (FTL v4.3.1). I was wondering if the 04-bypass.conf still works with this version? I understand there is no dnsmasq service?

Basically, I have a device, and i just want to send it to an Google DNS, rather than using the PiHole. I am unable to manually configure the device (IPCam).

Therefore, in the config file, do i just need two lines:

dhcp-option=tag:googlesdns1,6,8.8.8.8
dhcp-host=F0:XX:XX:XX:XX,set:googlesdns1

Then run:
sudo service pihole-FTL restart

Thank you in advance

jfb · October 22, 2019, 9:41pm

Yes it does. Dnsmasq is embedded in pihole-FTL and all dnsmasq configurations work as before.

lucianor · October 29, 2019, 5:03pm

One issue I had with setting specific dnsmasq conf files is described over this thread: Bypassing / Excluding IP address from Pi-Hole not working - #6 by Bucking_Horn
Hope this feature fixes that.

However, I would like to point out an improvement to this feature, which is the ability to select specific blacklists - instead of a global, have different sets of blacklists that can be applied to a certain client.

Example (blacklists sets)
IT Person: spam, tracking, shopping
Grandpa: spam, tracking, suspicious
Kids: spam, tracking, suspicious, shopping, parental, social media

Since that the feature request in this thread is a dependency to such improvement, I could submit a new one? Either way, I believe the above can be taken into consideration during implementation.

Thanks and keep up with the good work.

jfb · October 29, 2019, 5:10pm

I believe this feature request has been submitted and evaluated. See below. If it is not the same as the feature you request, then please open a new feature request.

lucianor · October 29, 2019, 5:47pm

Thanks for the prompt response. Yes, it is the same, and I do see the evaluation.
If the HA feature is implemented, this could be possibly be achieved by having multiple servers with different sets of blacklists. Will see.

jfb · January 26, 2020, 12:45am

A post was split to a new topic: Identifying colors for group management

6illes · April 25, 2020, 12:26pm

Seems like lots of people are asking for a workaround and I didn't seem to find a proper solution so I'll post it here for those that don't want to switch to v5 beta yet. This only works if your Pi-Hole is the DHCP-server.

First of all there's no need to add custom files as said previously. We only need to edit one file:

sudo nano /etc/dnsmasq.d/04-pihole-static-dhcp.conf

dhcp-host=MAC,IP,NAME,set:DNS-NAME
dhcp-option=tag:DNS-NAME,6,DNS-IP

Where:

MAC = "xx:xx:xx:xx:xx:xx"
IP = "x.x.x.x" (Static assignment)
NAME = "hostname" or whatever name you prefer
DNS-NAME = "name of your DNS-server"
DNS-IP = "x.x.x.x"

Example:

dhcp-host=AA:AA:AA:AA:AA:AA,192.168.0.200,AppleTV,set:Quad9
dhcp-option=tag:Quad9,6,9.9.9.9

Restart Pi-Hole Service:
sudo service pihole-FTL restart

Check Logging for static assignment:
tail -f /var/log/pihole.log | grep DHCP

Bucking_Horn · April 25, 2020, 2:20pm

/etc/dnsmasq.d/04-pihole-static-dhcp.conf is a file under Pi-hole sovereignty

This may only work until you update, repair or reconfigure Pi-hole.
Changes may be overwritten without notice.

yubiuser · June 1, 2020, 11:20am

Implemented in pihole v5.0. via Group management.

jfb · June 1, 2020, 12:22pm