"whitelist always wins" has always been the primary rule of handeling domains, however...
Since one of the last versions ( 109.0.1518.49) of microsoft edge chromium, the browser does a lot of HTTPS queries. I'm blocking these request, have been doing this since this type was first mentioned here, since apple has been using these queries for a while now, never had any problems (even an OS upgrade, monterey over big sur, succeeds), blocking these queries. I'm using:
since the edge update, I noticed the massive amount of HTTPS queries, no negative impact on the browser experience so far, due to the block.
todays HTTPS count:
I looked into the data returned by these queries, noticed the returned data can contain a CNAME and / or IP address information.
The problem: I want to block all of the HTTPS queries, as long as there is no negative impact on the browser experience. I don't expect this to happen any time soon, since firefox (possibly other browsers) don't use HTTPS queries at all.
For my banking app (example), I need to whitelist some domains to be able to accept the initial cookie warning and login. Pi-hole sees the whitelist entry, thus forwards the queries for this domain, including the HTTPS queries, which results in the browser getting additional information, that I wanted to block, using the HTTPS query.
This is not a minor problem. To ensure that HTTPS queries do not get an answer, I applied a suricata rule, rejecting all HTTPS queries on the WAN. Despite the Pi-hole regex, I got a lot of reject alerts, I finally figured out this was due to the Pi-hole whitelist entries and had to suppress the alert in suricata (suppress means "applied" but no alert entry logged).
possible solution (@DL6ER feasable?):
a domainlist entry type that takes precedence over whitelist entries, e.g. evaluated before whitelist entries are checked? The solution, proposed by yubiuser looks like a better approach, would be great if
querytype= would allow specifying multiple query types.