I would like to ask what does pi-hole need from dns resolver?
Is there way to make this project work with kresd? Knot dns resolver?
This resolver is great. Cloudflare is using it and people could use DNS over HTTPS and TLS.
Compared to DNSMASQ it is faster, and more secure as well with better features.
I used to prefer dnsmasq but since kresd has support for DNS over HTTPS I am no longer able to support it the way I used to because it seems to be worse software lacking security features.
I think knot-resolver would be a great addition to pihole. As you mentioned, I'm not 100% certain what a dns resolver needs to be able to do support some of the statistics/etc. that pihole has. However, I know it can block dns queries (two different ways, one of which exposes an api to add/remove/etc), supports DNS over TLS/HTTPS out of the box, aggressive caching capabilities, and a slew of other things. It also has the capability to put hooks in (either after certain events occur or periodic) that could possibly support a lot of the new things FTLDNS is doing, but without modifying the upstream.
Obviously, there is a ton of work to switch something like this out in pihole, but if the pihole team were to do it, i think knot-resolver would be an excellent choice.
Any chance to get this implemented?
There is a lot of work to switch resolvers and/or implement native DoH. We already have integrated with Dnsmasq in FTLDNS, which is not fully released yet because of how much work it is to implement. We are working on more substantial improvements, and so for now there is little chance that this feature request will be implemented.
Actually, when we release version 4.0 (and now if you run the FTLDNS beta branch) you will be able to run cloudflared alongside pihole-FTL and use that as your upstream resolved. I've been doing this for a while now.
There have been a good few guides pop up on the internet since cloudflare's 1.1.1.1 launch on getting DoH working with pi-hole. For 4.0 (or FTLDNS) you only need to follow them partially. Once you have got cloudflared (or whatever alternative resolver you prefer) installed, you just need to add 127.0.0.1#[port] (where [port] is the port your alt resolver is listening on e.g 5053) and you're all set!
There are instructions in the guide for getting it to work on the current release version of Pi-hole, but they're more of a workaround and not officially supported.
The relevant parts from this guide are as follows:
cloudflared
The installation is fairly straightforward, however be aware of what architecture you are installing on (amd64 or arm).
Download the installer package, then use apt-get to install the package along with any dependencies. Proceed to run the binary with the -v flag to check it is all working.
wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.deb
sudo apt-get install ./cloudflared-stable-linux-amd64.deb
cloudflared -v
Here we are downloading the precompiled binary and copying it to the /usr/local/bin/ directory to allow execution by the cloudflared user. Proceed to run the binary with the -v flag to check it is all working.
wget https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz
tar -xvzf cloudflared-stable-linux-arm.tgz
cp ./cloudflared /usr/local/bin
chmod +x /usr/local/bin/cloudflared
cloudflared -v
Create a cloudflared user to run the daemon.
sudo useradd -s /usr/sbin/nologin -r -M cloudflared
It is good practice to have a configuration file to contain options. Proceed to create a configuration file by copying the following in to /etc/default/cloudflared. This contains the command-line options that get passed to cloudflared on startup.
# Commandline args for cloudflared
CLOUDFLARED_OPTS=--port 5053 --upstream https://1.1.1.1/dns-query
Update the permissions for the configuration file and cloudflared binary to allow access for the cloudflared user
sudo chown cloudflared:cloudflared /etc/default/cloudflared
sudo chown cloudflared:cloudflared /usr/local/bin/cloudflared
Then create the systemd script by copying the following in to /lib/systemd/system/cloudflared.service. This will control the running of the service and allow it to run on startup.
[Unit]
Description=cloudflared DNS over HTTPS proxy
After=syslog.target network-online.target
[Service]
Type=simple
User=cloudflared
EnvironmentFile=/etc/default/cloudflared
ExecStart=/usr/local/bin/cloudflared proxy-dns $CLOUDFLARED_OPTS
Restart=on-failure
RestartSec=10
KillMode=process
[Install]
WantedBy=multi-user.target
Enable the systemd service to run on startup, then start the service and check its status.
sudo systemctl enable cloudflared
sudo systemctl start cloudflared
sudo systemctl status cloudflared
Now test that it is working! Run the following dig command, a response should be returned similar to the one below
dig @127.0.0.1 -p 5053 google.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 -p 5053 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65181
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1536
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 299 IN A 243.65.127.221
;; Query time: 3 msec
;; SERVER: 127.0.0.1#5053(127.0.0.1)
;; MSG SIZE rcvd: 65
Haha. Very funy. I made such guide months ago for turris.
I see many flaws in this solutions (cloudflared instead of DOT) that is more like a workaround rather than solution.
The real solution is to use a local Unbound and just be your own upstream. Then there's no need for helper programs or overhead of TLS encryption, handshakes, keeping connections open and all that comes along with DoH.
adding different overhead to solve one makes no sense.
If there are other users that see this as valuable and vote for the idea then we can prioritize it. Right now there are other options that work and have many users implementing them.
Haha. Very funy.
I don't really get what's so funny. To be honest, there is no one "correct" solution to this "problem".
If you wish to implement DNS over HTTPs, or DNS over TLS, or run your own resolver using ubound or whatever solution you feel is the objective "best" way to resolve DNS queries on your network, there are plenty of options out there to do so.
In the real world, the overhead added by the current available solutions is so minimal the part of it that could be considered funny is just how much effort is put into proving that the current solution of using dnsmasq as a DNS proxy service (again, forwarding to whatever upstream you wish) is flawed/sub par. Yes, there are going to be overheads to using an additional layer, but to some, that is worth it for the perceived increase in privacy. (Who are we kidding, nothing is really private)
The source code for FTL is there for all to see and tinker with as they see fit. If someone wants to come up with a solution that improves things on all fronts, then they are more than welcome, and pull requests are gladly accepted on the code base.. we don't bite! As it is, we're all pushed for time as it is, and implementing an alternative resolver at this stage is not one that's on the priority list.
Hope you can understand that.
I must correct this slightly: I may actually bite* when PR are submitted against the contained dnsmasq, because we want to keep this as unmodified as possible to be able to easily merge in upgrades of dnsmasq itself. This is currently possible within a few minutes. However, if the code would get heavily modified (I already had PM discussions with users about implementing a "better" tree algorithm for cache management) then upgrades may cause tons of merge conflicts and it could be difficult to resolve them without introducing new bugs.
This is not a general No for any kind pull request, it just means that such PRs will only be accepted to individual feature branches, but not master or development. We are happy to assist with preparing a submission to dnsmasq's main repository if the feature you want to provide is nice.
*) bite as in close the pull request...
Furthermore, we've not even released FTLDNS to the general audience, so it seems wrong to already think about any possible successor. I quickly looked at the source code of the Knot DNS resolver and it seems like it doesn't offer DHCP services. So, as with unbound, we'd have to take yet another server into our binary to be able to offer DHCP. I'm just trying to say that dnsmasq is (and will likely be for a long time) the best option for the project Pi-hole as it allows you to use any kind of forward destination you want to use. May it be simply Google's 8.8.8.8, your own recursive resolver, some DNS over HTTPS/TLS implementation or whatever. We support all of this with Pi-hole v 4.0. We write guides and we provide one-click integrations into Pi-hole of whatever kind of DNS solution you prefer.