leng - a fast DNS server with adblocking, built for self-hosting
leng - a fast DNS server with adblocking, built for self-hosting
:zap: fast dns server, built to block advertisements and malware servers - GitHub - Cottand/leng: :zap: fast dns server, built to block advertisements and malware servers
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
How does this compare to AdGuard Home?
27I am working on adding a feature comparison to the docs. But in the meantime: leng has less features (like no web UI, no DHCP server) which means it is lighter (50MB RAM vs 150MB for adguard, 512MB for pihole), and easier to reproducibly configure because it is stateless (no web UI settings).
I believe blocky and coredns are better comparisons for leng than "tries to achieve it all" solutions like adguard, pihole...
12You can script this with nix quite easily without needing a UI. For many this is a big plus.
3
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System IP Internet Protocol LXC Linux Containers PiHole Network-wide ad-blocker (DNS sinkhole) VPN Virtual Private Network k8s Kubernetes container management package
6 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.
[Thread #282 for this sub, first seen 15th Nov 2023, 10:25] [FAQ] [Full list] [Contact] [Source code]
15This looks interesting.
So it's like PiHole, but written in Go, smaller and faster?
12Damn! In a previous comment somewhere else I had just recently shared my dispair at how I hadn't found an easy to follow self hosted DNS server.
I appreciate this immensely and hope to enjoy it once I figure out how to install!
Keep up any and all good work you feel passionate enough about to crank out helpful things in physical reality.
8If it's helpful to you it's helpful in reality!
If you are having trouble installing or the documentation is not clear, feel free to point it out here or in the issues on github. Personally I think it is simplest to use docker :)
3
Reads nice but your docs are 404'ing so I can't investigate much :D
EDIT. Found it. You've got a '.com' instead of a '.io'.
4Ouch, thanks for catching that! Should be good now. Link here for the curious
4
This is awesome. I've been looking into DNS servers with ad blocking and this seems to be a perfect fit. And it is packaged for Nix, so I'll definitely give it a go.
4So cool! I was looking for something really simple like this recently.
Tossed a PR in there BTW, the template config in Configuration.MD was causing me some issues.
3Thank you for your PR! Keen to hear your feedback after you've used it a bit
1
Does this just use an upstream dns server or can it do recursive resolution like unbound? Does it cache results?
2If you mean CNAME flattening I have an issue for it. If you mean recursively resolving CNAME until the end record is found, it does support it.
For example, if you set a custom record
mygoogle.lol IN CNAME google.comLeng will return a response with an A record with agoogle.comIP address when you visitmygoogle.lol1
Does this support DNS management with nsupdate? I'm currently automating DNS on pihole by changing a text file and reloading the service, which is just not very convenient not to mention slow.
2I have a similar use case where I also need my records to change dynamically.
Leng doesn't support nsupdate (feel free to make an issue!), but it supports changing the config file at runtime and having leng reread it by issuing a SIGUSR1 signal. I have not documented this yet (I'll get to it today), but you can see the code here
Alternatively, you can just reload the service like you do with pihole - I don't know how quick pihole is to start, but leng should be quick enough that you won't notice the interim period when it is restarting. This is what I used to do before I implemented signal reloading.
Edit: my personal recommendation is you use templating to render the config file with your new records, then reload via SIGUSR1 or restart the service. nsupdate would make leng stateful, which is not something I desire (I consider it an advantage that the config file specifies the server's behaviour exactly)
3Pihole reloading in my case is probably mostly slow because of the hardware. That signal functionality to reload is pretty neat, though I think I disagree with the config files being the only thing specifying the servers behaviour exactly being a big advantage. In an environment using infrastructure as code it would probably be better to define DNS over the generic nsupdate API (e.g. with ansible or other equivalent tools) than having to write custom code to reload some config files that have to be regenerated every time. But for smaller home setups both options are probably fine anyhow.
1