.*;querytype=PTR (regex whitelist) (required, !A is to restrictive)
on devices, such as a chromecast, PS4, IPv4 only desktop, ... (group allowAqueriesOnly), this to instruct pihole-FTL, NOT to forward unnecessary requests. (example: the apps and devices shouldn't be making the request, since they have no IPv6).
The reply however, on regex match is NOT configurable (reply depends on blocking mode):
an AAAA query on these device (.*;querytype=!A) always returns ::
an ANY query on all devices (.*;querytype=ANY - group Default) always returns 0.0.0.0
Request: Make the reply configurable, something like .*;querytype=ANY;nodata or .*;querytype=!A;nxdomain
It should likely be a property=value relation, so rather like
.;querytype=ANY;reply=NODATA
or
.;querytype=!A;reply=NXDOMAIN
I'll have to check how (and if) this can be implemented without making too many changes. The code being responsible for detecting (database + regex lookups) and actually performing (creating a suitable DNS reply packet) the blocking is pretty far from each other.
Okay, so NODATA works for you but you see an incorrect warning. I cannot reproduce this and, looking at the code I also don't know where this may come from.
I updated the branch with a version that is a bit more explicit when complaining about unknown reply types and should also fix the incorrectly displayed reply type in the Query Log.
edit The CI is lacking behind. The correct version will be vDev-d8c8df39 for your next tests.
the reported count is correct (Compiled 3 whitelist and 51 blacklist regex filters for 15 clients in 518.0 msec) , the database contains 54 entries (sum of type 2 and 3).
edit
Pi-hole version is v5.3.1 (Latest: v5.3.1)
AdminLTE version is v5.5 (Latest: v5.5)
FTL version is new/regex_replytype vDev-d8c8df3 (Latest: v5.8)
/edit
Ah, I see now where the warning came from. A simple logic error without consequences for the actual function. I pushed another update.
You can add DEBUG_REGEX=true in /etc/pihole/pihole-FTL.conf to get even more details about the compilation and execution of regex. Based on this data it'll be easier to see why one device is getting an unexpected reply.
Yes. Please also add DEBUG_QUERIES=true so we get more details in pihole-FTL.log and try again. The log will grow substantially. We only need the relevant lines from the query we're looking at here.
[2021-04-18 17:22:48.393 18613M] **** new UDP query[AAAA] query "mtalk.google.com" from eth0:192.168.2.240 (ID 20, FTL 10330, /root/project/src/dnsmasq/forward.c:1592)
[2021-04-18 17:22:48.393 18613M] mtalk.google.com is not known
[2021-04-18 17:22:48.394 18613M] Reply is 1
[2021-04-18 17:22:48.395 18613M] Set reply to NODATA (1)
[2021-04-18 17:22:48.395 18613M] Blocking mtalk.google.com as mtalk.google.com is regex blacklisted
[2021-04-18 17:22:48.395 18613M] Forcing next reply to 1
[2021-04-18 17:53:36.885 25796M] **** new UDP query[AAAA] query "mtalk.google.com" from eth0:192.168.2.240 (ID 22, FTL 11312, /root/project/src/dnsmasq/forward.c:1592)
[2021-04-18 17:53:36.885 25796M] mtalk.google.com is not known
[2021-04-18 17:53:36.886 25796M] Reply is 2
[2021-04-18 17:53:36.887 25796M] Set reply to NXDOMAIN (2)
[2021-04-18 17:53:36.887 25796M] Blocking mtalk.google.com as mtalk.google.com is regex blacklisted
[2021-04-18 17:53:36.888 25796M] Forcing next reply to 2
on the windows desktop , the DIG replies do actually register as NODATA, It is the device on 192.168.2.240, for witch the query log always displays N/A.
I tested this now, using dig and DEBUG_QUERIES=true, both the DIG command on the desktop and the device (192.168.2.240 - no access possible, black box, so queries are initiated automatically) use UDP. The output in the log is identical. Is the device asking something more / else, than a simple DIG command?
attached packet capture, filter port 53 and ip 192.168.2.240. You'll notice some DNS requests to 8.8.8.8, but the firewall redirects these to pihole.
Who knows. The capture is a good idea, could you generate the same from the Windows machine that behaves as expected? Comparing the two would make it a lot easier for me. Both the question and the reply look perfectly fine (and indeed NODATA).
When dig AAAA google.com from localhost it is not blocked (expected, it is not member of the group created for the regex above). If I query the same domain from 127.0.0.2 it is indeed blocked:
I'm so sorry, I recreated the regex to use NODATA (after the NX DOMAIN test, but forgot to assign it to the correct group, fixed that, AAAA queries are back to normal on that device (with IPv6), again, SORRY....
On the desktop with IPv4 only, client assigned to the regex (via group), with an OK result, started capture, executed dig, stopped capture.
FYI
Just noticed a typo in this regex completely kills DNS resolution, e.g. example .*;querytype=!!A, a typo, is accepted by the webinterface (success), FTL notices the problem and generates a WARNING message in the FTL log
My vote is dead end. It seems to be just too much. I can see adding additional selectors like querytype very useful but specifying the result in the regex itself seems just very wrong. Asking the regex experts @PromoFaux@DanSchaper about their opinion as well.
We should be cautious to not add more and more and more features when we want to have a still fast and easily to maintain Pi-hole ecosystem. Only this will ensure the project can live on in the future.
I wasn't aware that it is that bad. I know you are the badass SQL master so I presumptively extended this to other strange languages (like regex) as well-
