Replies: 3 comments 1 reply
-
Blocky follows (as far as possible) the KISS principle. It has simple text based configuration file, provides some external APIs and integrates with other tool (for example prometheus). Users who want to analyze which domain was blocked have only the log and query log. It is not really user-friendly, but this approach has some advantages (simpele backup, stateless, runs in k8s, ...). Some new APIs -> that sounds great, I am in favor of doing this. If there is a need for a web ui -> that should be an external application which can be deployed separately and communicates with "core" blocky. To be honest, I'm a backend guy and it would be difficult for me to create a good web ui. Adding some blacklist at runtime -> sounds difficult at the first glance, since blocky has no database and we can run multiple instances. But maybe there could be an another approach (for example: webui allows to define blacklists and blocky polls the blacklist from webui). There are just my thoughts, let's discuss it 👍 |
Beta Was this translation helpful? Give feedback.
-
UI is not needed - it should be built by systems that integrate Blocky. In the worst case, we could re-wire the PHP pages of Pihole web interface... What is essential is real-time transparency of what is happening (what was blocked and what rule/list triggered a block) and the easy ability to flip blocked or allowed entries to whitelists/blacklists. Second to that would be timers - disabling blacklist for a defined period of time and then re-enabling it back. To elevate Blocky from other DNS resolvers and DNSBL managers, it has to offer transparency and easy customization of lists. That's what other resolvers don't have by default. |
Beta Was this translation helpful? Give feedback.
-
I recently published https://github.com/shizunge/blocky-lists-updater letting yout to add and remove lists and domains to blocky easily. Hopefully you find it useful. |
Beta Was this translation helpful? Give feedback.
-
One of reasons why Pihole is so popular is its ability in displaying a real-time requests flow, finding a false-positive blocked request, whitelisting it on the spot and seeing it resolve in near-real time.
To build an UI like that for Blocky, we would need to strengthen some of apis: stream of real-time resolving logs, source/reason of blocking (when blocked), whitelisting/blacklisting lists read/write/update/delete.
Not to forget apis for a temporary (timed) killswitch for on item, a blocklist, a whitelist and a whole Blocky.
Beta Was this translation helpful? Give feedback.
All reactions