I think there are two approaches to infrastructure as code (and even code in general):

• as steps (ansible, web UI like pihole…)
• declarative (nix, k8s, nomad, terraform…)

Both should scale (in my company we use templating a lot) but I find the latter easier to debug, because you can ‘see’ the expected end result. But it boils down to personal preference really.

As for your case, ideally you don’t write custom code to generate your template (I agree with you in that it’s tedious!), but you use the templating tool of your framework of choice. You can see this example, it’s on grimd (what I forked leng from) and Nomad, but it might be useful to you.

P.S also added to the docs on the signal reloading here

I 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)

Thank you for your PR! Keen to hear your feedback after you’ve used it a bit

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)

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

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 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…

If 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.com Leng will return a response with an A record with a google.com IP address when you visit mygoogle.lol

If 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 :)

What you described is correct! How to replicate this will depend heavily on your setup.

In my specific scenario, I make the containers of all my apps use leng as my DNS server. If you use plain docker see here, if you use docker compose you can do:

version: 2
services:
 application:
  dns: [10.10.0.0] # address of leng server here!

Personally, I use Nomad, so I specify that in the job file of each service.

Then I use wireguard as my VPN and (in my personal devices) I set the DNS field to the address of the leng server. If you would like more details I can document this approach better in leng’s docs :). But like I said, the best way to do this won’t be the same if you don’t use docker or wireguard.

If you are interested in Nomad and calling services by name instead of IP, you can see this tangentially related blog post of mine as well

Thanks! I didn’t know you could do that. I’ll see how it compares to my current solution

Including SRV records? I found that some servers (blocky as well) only support very basic CNAME or A records, without being able to specify parameters like TTL, etc.

I also appreciate being able to define this in a file rather than a web UI

Ouch, thanks for catching that! Should be good now. Link here for the curious

Like chiisana@lemmy.chiisana.net said - I want to be able to add my own records (SRV, A, CNAME…) so that I can point to the services hosted in my VPN. CoreDNS is good for this but it doesn’t also do adblocking. If PiHole can do this, I don’t know how.

I also don’t need a web UI, DHCP server, and so on: I just want a config file and some prometheus metrics

Yes (much simpler) and also allows you to specify custom DNS, which is very useful for more advanced self-hosted deployments - this is something PiHole is just not built to address

• Can you show the diff with your previous WG config?
• Is 10.11.12.0/24 also on enp3s0?

I am able to connect and can ping 10.11.12.77, the IP address of the server, but nothing else

Including the wider internet, if you set your phone’s AllowedIPs to 0.0.0.0/0? This makes me think it’s a problem with the NAT, not so much wireguard. Also make sure ipv4 forwarding is enabled:

sysctl -w net.ipv4.conf.default.forwarding=1
sysctl -w net.ipv4.conf.enp3s0.forwarding=1

Reading this article might help! I know this is not what you asked, but otherwise, my approach to accessing devices on my LAN is to also include them in the WG VPN - so that they all have an IP address on the VPN subnet (in your case 10.11.13.0/24). Bonus points for excluding your LAN guests from your selfhosted subnet.