Status codes in FTL database for whitelisted entries

Feature Requests
#1

Everybody does it, you run into a blocked web site, search for the domain that causes the problem and whitelist it (hopefully with a comment for future reference). Once whitelisted, you never look back. I was recently made aware of some domains that no longer need whitelisting. but found it to be hard to determine which whitelist entries are actually effective, mainly due to the fact there are no dedicated status entries, indicating a query was forwarded (whitelist always wins) due to a whitelist entry. There are currently 17 status IDs (0-16), the missing entries in the documentation are already addressed by this PR.

Request:
add status types:

  • ID 17: forwarded, exact whitelist entry
  • ID 18: forwarde, regex whitelist.

If at all possible, the additional info field should contain the ID of the entry.

This would allow a user to identify the whitelist entries, used (thus usefull), but also the entries that are never used (will require some sqlite3 queries to identify, but certainly not impossible).

Currently, I'm using a grafana dashboard to identify specific queries.

image
image1649×1342 136 KB

The possibility to identify whitelist entries would allow me to identify obsolete entries (disable for a period of time, remove later).

image
image2020×1114 124 KB

#2

Whitelist entries are always effective. If something is on your whitelist, it can never be blocked by either gravity or a domain entry.

You could run pihole -q for any domain to see what lists contain it (blacklist, whitelist, gravity, regex).

#3

pihole -q is very usefull for solving specific problems, it is not intended to use for automation.

whitelist entries are added as response to specific problems, most users never look back, once the problem is solved. When a whitelist entry is no longer required, there is no easy way to detect this.

I want to sqlite3 query the database for allowed domain queries, due to whitelist entries. This can't be done in an efficient way, hence the request for status 17 and 18.

Already discussed this with a developer, his answer:

/quote
I don't see anything that speaks against adding this right now, however, I'd first have to take a closer look at the source code before I can say this with certainty. Something for another day but go ahead and raise the request.
/quote