Display blocked "Deep CNAME" domains in Pi-hole tail & query

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:
Screenshot at 2020-07-14 19-33-01

Concerning the other issue,

I guess they intended what @Coro said above :wink:

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

; EDNS: version: 0, flags:; udp: 1472
;fonts.gstatic.com.		IN	A

;; Query time: 4 msec
;; 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

;flurry.com.			IN	A

flurry.com.		2	IN	A

;; Query time: 3 msec
;; WHEN: Mon Jul 27 22:48:34 CEST 2020
;; MSG SIZE  rcvd: 44


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?

see here (and CNAME logging...)

1 Like

Closing this request as implemented with the release of FTL v5.2 (Pi-hole FTL v5.2 Released).

1 Like