Hacker News Reader

Comment by larrywright | Hacker News Reader

I’m in the process of building out a smallish home lab, with most things running in containers, and one of the things I wanted was dns for my internal things that Just Worked. It seems this is still harder than it needs to be. I started looking at Consul + Traefik, but the latest version of Traefik seems to have gotten significantly more complex for simple use cases. I’ve since started looking at Caddy, which seems far more straightforward. I will look at this, however, since it might be simpler still.

View on HN

+1 for Caddy.

I have been using it for years now for my personal stuff (almost all containers) and it's a breeze (the https part especially). I recently [0] added SSO for all my local stuff so I just have to login once and have access to everything.

[0] https://joshstrange.com/securing-your-self-hosted-apps-with-...

It makes my morning that this might be useful to someone aside from myself. I went down a similar path trying to find something mindless to route traffic to small projects I tend to run on raspberry pi's around the house, which resulted in this being made.

You can have the best of both worlds; since this project is written in Go, it can easily be made into a Caddy module that takes care of the mDNS part, without having to overlap other functionality. Docs: https://caddyserver.com/docs/extending-caddy

The simplest: shared `/etc/hosts`. And container hint: you can bind mount individual files as volumes.

Also cool is that you can bind mount the same sqlite backing db file into multiple containers.

That seems dangerous? How can it be so? Surely multiple instances of SQLite shouldn't read the same backing file..

The whole job of sqlite is to handle the locking to keep such accesses safe.

Ok, I see. I did some reading and it looks like this to me:

* the DB is supported by a backing file

* this backing file supports multiple read threads simultaneously but writes are locked via filesystem locks

* write performance with multiple writers is therefore dangerous

* read performance is good if no one is writing and consistent even if someone is

I spent the past weekend setting up a VPS for a personal project, and Caddy worked wonderfully well. All I needed was HTTPS for a server, and a two line Caddyfile gave me that:

reverse_proxy localhost:8000

I'm using dnscrypt proxy with as filtering and some local DNS config, configured with dnscrypt server running on my VPS. It is running on pi-zero (old $5 one without wireless), a bit slow (50ms query), but works fine, especially with caching

Caddy user here... definitely interesting to me.

+1 for Traefik. The problem was the documentation IMO. It works great including the integration with Docker.

BIND provides DNS that just works. :)

Agreed, but my point is that if I spin up a new container with something in it, I want to be able to have DNS registration occur automatically so that I’m not having to go update DNS entries somewhere.

A simple solution would be `dnsmasq` which provides DNS and DHCP, but it cannot be used on a public network. More complex setup would be ISC DHCP server that maintains a dynamic subdomain in BIND.

>ISC DHCP server that maintains a dynamic subdomain in BIND

This is what I do. I don't remember setting it up being particularly complex

PowerDNS lets you do that (if you run it against a SQL database), or CoreDNS/etcd for simple stuff.

Reply on news.ycombinator.com