A few months ago I went on a quest for a DNS server and was dissatisfied with current maintained projects. They were either good at adblocking (Blocky, grimd…) or good at specifying custom DNS (CoreDNS…).
So I forked grimd and embarked on rewriting a good chunk of it for it to address my needs - the result is leng.
- it is fast
- it is small
- it is easy
- you can specify blocklists and it will fetch them for you
- you can specify custom DNS records with proper zone file syntax (SRV records, etc)
- it supports DNS-over-HTTPS so you can stay private
- it is well-documented
- can be deployed on systemd, docker, or Nix
I have been running it as my nameserver in a Nomad cluster since! I plan to keep maintaining and improving it, so feel free to give it a try if it also fulfils your needs
I think the answer is yes (as leng is recursive) but can you explain your use-case and expected behaviour a bit so I can get a better idea of what you want unbound to do that blocky is not doing?
I think it does caching because grimd does caching. I want a dns filter and dns resolver that’s selfhosted but still performant and low latency. Caching of course is big part of that because if you’re running recursive queries every time, your ping will be like 100-200ms.
Leng will cache each step of recursion, and it relies on upstream resolvers to do recursion for it as well (like grimd), so you should not be seeing 200ms resolution in any scenario.
I am keen for you to give it a shot - if you do please make an issue if it’s not behaving like you were hoping for
Ahh interesting. So do you have to manually set an upstream dns server?
Correct, and much like grimd you can specify several. But unlike grimd, leng will perform recursion when the upstream server is not capable of resolving queries completely (namely, because a CNAME resolved by upstream somewhere points to a domain that is part of your custom DNS records, or vice versa)