I would like to make my Pi-hole a little more intuitive about newly registered domains.
What I was thinking was to have the DNS query (assuming it's not whitelisted/blacklisted) be forwarded off to a local script. This script could be a Python/bash/other bit of code that when executed, would return a True/False/0/1 response which Pi-hole could interpret as a serve/block the response to the endpoint requesting the DNS query.
In my particular use case, I would have my script perform a whois on the domain and if the creation date is less than days, return a True/False/0/1 value which Pi-Hole could interpret accordingly.
I've only described one particular use case, but perhaps there could be additional features incorporated to have scripts do other tasks from an analysis point of view and based on the analysis allow the response to be served or not.
As an alternative way rather than executing a script every time a query is performed, could have Pi-hole forward the request to a localhost service listening on the device. The localhost service would then return an appropriate response from which the Pi-hole could take the necessary action. The localhost service would be a custom program, not necessarily managed by the Pi-hole ecosystem.
If this were to be a feature, there would need to be some visual way see in the Pi-hole dashboard that the request was forwarded to the script, the script returned a response, and if the script returns an error, it should be displayed. Perhaps also include a measurement of the time taken for the script to respond? There would also need to be a "fail-open"/"fail-closed" response if the the script stops working for whatever reason such that you can define your security posture accordingly. There would probably have to be a defined cached-response such that responses from the script are cached for amount of time to improve performance.
The suggestion to block domains newer than n days old has come up now and again. It is considered out of scope as a Pi-hole problem. It does have some merit outside of Pi-hole, and is more commonly seen in the security policy on corporate networks, but even there it can cause friction, eg newly registered campaign domains.
That said, if this matters to you, if you can find a way to take domain names, check their creation date and create a list of domains that are newer than n days old, and periodically update it, you can use this list as an adlist in Pi-hole. There are also third-party services offering this, albeit at the cost of either a subscription fee or at the cost of handing over your DNS data to gain access to it.
I think my request was perhaps lost in my particular and specific use case.
Ideally I would like to Pi-hole to forward the request (after validation against whitelist/blacklist) to a script/service (hosted locally on the device) in which this script/service can validate if the request needs to be served to the endpoint or not.
If my request is still deemed to be out of scope, do you have some other areas I could explore to try and get Pi-hole to do what I want?
Let me go a little bit more into the details of why this is out of scope:
When FTL calls a foreign script that does some obscure magic, it'll have to wait until this script came to a decision before it can handle further requests. Because FTL is so fast and can handle thousands of queries per second easily, it is not parallelized (well, it is for TCP but not for UDP queries because of architectural decisions). This was never an issue. Now image your script has to do lookups for every domains and even when they manage to finish in 100 msec, your Pi-hole will not be able to handle more than 10 queries per second.
You were talking about interpreted languages such as python or bash and I'd like to remind you that the simply launching the interpreter will often consume much more time than running the script itself. I would more see this using, e.g. lua which is completely embedded in FTL and has much less overhead than comparable interpreters.
Furthermore, there is the possibility for severe security implications here. Any process called by FTL will inherit its permissions and (most of) its capabilities, including access to the port 53, etc. Sure, this all can be dealt with, however, it creates another point in the code we have to carefully check when any new features are added anywhere else.
Overall, referring to external scripts makes things rather difficult and, when done wrong, adds unnecessary slowness and even potential security issues.
I could maybe imagine a different realization where FTL sends the domain over some socket (or whatever else) and then wait until a given timeout if someone replies with 1 or 0. However, we typically want to avoid adding complex features that won't be useful for a sufficient number of users to avoid the code from growing and growing and maintenance getting impossible over time. When we can somehow generalize this entire idea towards something that really adds value outside of a niche, the chances for this feature to materialize would significantly be increased.