Hi,
It would be great if you could create Black Lists for individual devices or a device groups.
For example Group: Kids . --> block you tube etc.
Even better if you could schedule it.
Have a filtered Dashboard based on Groups.
Best regards
Stefan
DL6ER
May 10, 2018, 11:22am
2
This is technically not feasible. The DNS server is not able to respond individually to different clients. The required code changes would be way too extensive.
See also this
How cool would it be if you could direct a certain IP to another secondary DNS
So 1 ip goes to Norton
And ANOTHER goes to OPENDNS
so different DNS For different IP's
1 Like
DL6ER
November 19, 2019, 9:24pm
3
One year later, I feel like I should update this. Pi-hole has moved quite a bit in this time, even though much of the movement is in the interiors and mostly hidden from the end-user. However, parts of the changes enables us to redesign critical parts. I'm not yet saying that we are going to have it in the end, however, we already have a working variant of the FTL daemon which is actually able to do per-client black- and white listing. Even per-client blocking lists is already implemented.
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)`.
There are still technical details to clarify. While there are important benefits, such as a massively reduced memory footprint, there are also downsides, one being the notable degraded regex performance. This is caused by us not being able to apply some performance tricks we invented for our current universal (as in the opposite of per-client) implementation.
Stay tuned!
2 Likes
DL6ER
November 22, 2019, 9:58am
4
DL6ER:
[...], there are also downsides, one being the notable degraded regex performance. This is caused by us not being able to apply some performance tricks we invented for our current universal (as in the opposite of per-client) implementation.
Update: I was able to resolve the mentioned performance penalties this morning. First tests look very promising.
1 Like
Implemented in pihole v5.0. via Group management.