This is now done as well.
No offense here, appreciating all the great work the developers are doing, just trying to draw the complete picture...
Another reason why having the info available in pihole -q:
The deep CNAME inspection info is Not available when looking at the Long Term Data / query Log.
It will be, though, which makes the pihole -q addition moot. As @DL6ER mentioned above, there's no real performant way to add this to pihole -q, and adding dig-like functionality begins to creep away from the scope of the script... which is, quite simply, to determine whether or not a domain is included on one of the blocklists, or is affected by regex rules. We would have to check each time pihole -q is run "is this domain a CNAME for some other domain that may or may not be on the blocklists?"
But like I said, this information will be available already on the query log (yes, I know it isn't right now after a restart)
Linking for reference, as it is related to CNAME
This issue ticket should be transferred to the FTL repo. I looked through the CNAME code and tried to find the bug but couldn't.
I think the ticket is fine in AdminLTE.
The problem is that the actual domains blocked by deep CNAME inspection were reported in the dashboard "Top Blocked Domains" and on click the query log is empty. This was (so far) due to the query string (containing the actual domain) didn't match any domain.
Edit: more accuracy about which domain is shown on dashboard.
No. The dashboard shows 1:1 what it receives through the API from FTL. Wrong display on the dashboard means wrong data given by FTL.
The dashboard is fine. It reports the actual blocked domain. The link to the query log (query sting) does not return any result (so far) for this domain.
Yes, and my point is that this is wrong. Pi-hole should not show the actually blocked domain (because the user never tried to access this page directly) but rather the originally requested CNAME. Hence, in my world, showing this domain is wrong and the CNAME should be shown instead.
So, instead of settingsfd-geo.trafficmanager.net as top entry, there should be settings.data.microsoft.com
The link will then also work as expected and this is honestly how I think it would be best and likely how the devs wanted to have it (but then some bug came in their way).
1 Like
Thanks for your more detailed explanation. I get your point now.
I'm not sure if I prefer 'What you see is what you meant' over 'What you see is what really happend' but (most?) users might be irritated by the latter. Fixing the query link would be one solution to reduce the confusion - the other would be changing the domain displayed at the dashboard as you suggest.
Let's see what the devs intended.
I added storing the regex ID responsible for a regex-block in the additional_info column when it is available (in the case of regex CNAME blocking, the domain is stored instead). So a restart will now also preserve regex links:
Concerning the other issue,
I guess they intended what @Coro said above 
The CNAME inspection routine was a bit confusing with all the CNAME path terminology, I pushed a refactor which makes it clear which domain records are parents and which are children of any degree of relationship.
I gonna be honest, the topic was kinda done for me since jfb told me that the CNAME blocking is done at Pi-hole level while the log is at dnsmasq level, now i see 2 months later which dimensions the FR became.. help.
@DL6ER ´s description of why an implementation in pihole -q or pihole -t is either not possible or would end up modifing even more on dnsmasq looks reasonable. After all, the current wave of CNAME related questions probably comes from the release from Deep CNAME Inspection inside Pi-hole v5.0 and it unlikely to hit anyone at all, especially after that first wave is over. Probably not worth to sacrifice the integrity of the code when adding the FR would create a mess in dnsmasq, or if adding the feature would add confusion to the script scope that @PromoFaux mentioned before.
I am honestly sorry that PromoFaux got missleaded half way in, that the initial FR was to keep the CNAME blocked domains stored after FTL Restart. That was not the intention of the FR, through probably can't hurt to have included if it doesn't cause any issues with database/SD Card Writes or similar.
additional_info as column name could probably add confusion at some point, but i didn't came up with something better myself so far...
The developers have found a way how to do it. Meanwhile they optimized (bugfixed) some edge case in the CNAME routine (note: I'm guessing from the commit messages) and added restoring of some status-specific quantities like the really blocked domain and the regex ID in this new additional_info field.
Overall, this was all very useful in the end, pihole -t got the information, the long-term interface is going to get it added (@DL6ER will do this?) and pihole -q is out-of-scope right now. I think this is the correct summary.
Well, yes and no. Yes as in there are no full human-readable sentences in there, but you don't usually expect this in a database, do you? So if people don't know what to do with this extra field, then they can simply ignore it and nothing bad will happen.
Added now in
pihole checkout web new/cname_inspection_logging
What is the expected answer of a domain blocked by deep cname inspection? My default is NULL, for CNAME I get this (NODATA ?)
chrko@ThinkPad-X230:~$ dig fonts.gstatic.com
; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> fonts.gstatic.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5949
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;fonts.gstatic.com. IN A
;; Query time: 4 msec
;; SERVER: 10.0.1.5#53(10.0.1.5)
;; WHEN: Mon Jul 27 22:48:26 CEST 2020
;; MSG SIZE rcvd: 46
chrko@ThinkPad-X230:~$ dig flurry.com
; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> flurry.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55328
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;flurry.com. IN A
;; ANSWER SECTION:
flurry.com. 2 IN A 0.0.0.0
;; Query time: 3 msec
;; SERVER: 10.0.1.5#53(10.0.1.5)
;; WHEN: Mon Jul 27 22:48:34 CEST 2020
;; MSG SIZE rcvd: 44
chrko@ThinkPad-X230:~$
Yes, this is expected and due to technical limitations with how we can generate a specific reply within building an ordinary (originally non-blocked) query. It is on our ToDo list to improve on this, however, it is technically challenging to do this without rewriting too much of dnsmasq's code which is something we generally try to avoid for compatibility with future dnsmasq updates.
Will this someday find its way into the master branch? Am I right that we can see deep cname blocking in the dnsmasq log now?
Closing this request as implemented with the release of FTL v5.2 (Pi-hole FTL v5.2 Released).
1 Like