this post was submitted on 15 Nov 2023
156 points (95.9% liked)

Selfhosted

40006 readers
550 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 11 months ago (3 children)

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.

[–] [email protected] 3 points 11 months ago* (last edited 11 months ago) (2 children)

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)

[–] [email protected] 1 points 11 months ago (1 children)

Pihole 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.

[–] [email protected] 2 points 11 months ago* (last edited 11 months ago)

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