The feature for temporarily disabling pihole on certain devices would be awesome. I have to disable pihole for whole network now if i need a device to reach internet directly. (you cant change dns on some devices...)
jfb
July 14, 2019, 11:18am
3
anon55913113:
A client can then choose between filtered or un-filtered DNS.
How will a client do this if unable to change DNS on that client?
jfb
July 14, 2019, 12:00pm
5
Thus the feature request.
1 Like
Obviously this comes with no ETAs or such like, but it is something we are exploring:
pi-hole:development ← pi-hole:new/internal-blocking
opened 04:02PM - 18 Sep 19 UTC
**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)`.
JaneDoe
January 22, 2020, 12:29pm
8
This is possible in beta v5.0