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:
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.
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.
