Good resources for setting up a domain name to a local Caddy instance

Submitted ⁨⁨7⁩ ⁨hours⁩ ago⁩ by ⁨petrichornetrainfall@piefed.social⁩ to ⁨selfhosted@lemmy.world⁩

I’ve been using Linux for decades, I’ve worked as a software engineer/architect/sre for around a decade, but networking has always been my biggest gap in knowledge.

I have a local server, I have caddy spun up, a glinet router running their version of openwrt, and I have a domain name purchased through porkbun.

I am looking to setup “local.domain.com” to point to my local server, ideally without exposing it publicly, and enable devices on my home network to be able to access it from that url. Id also like to be able to access containers running on that server by something like “searxng.local.domain.com” or “local.domain.com/searxng” aka without using the port suffix. Id also like to enable https.

I have read so many guides that have fragments of what I need, but nothing that ties enough together to get it working. And with all the options around different domain registers, let’s encrypt, reverse proxies, etc, im struggling just a bit.

Are their any guides (prefer text over YouTube, but beggars cant be choosers) that people recommend that encompass the whole process, instead of just pieces? Id like to understand it instead of just fumble through it.

original

Comments

Sort:hotnew top

d13@programming.dev ⁨2⁩ ⁨hours⁩ ago
Lots of overcomplicated answers, imo.

Here’s what I did:

Set up a DNS server (I just used Pi Hole docker)

Tell router to use your DNS server

Register domain

Set up Caddy to use DNS challenge with registrars provider’s API key

Add DNS entries to the DNS server for each service. The records point to Caddy’s IP (e.g. jellyfin.<domain>.com)

Add each container to Caddy’s list

Now every device can hit all services.

Bonus: Set up split DNS and subnet routing with Tailscale so that it uses the DNS server for that domain. Now any device connecting to the tailnet can connect to the services just like at home. No need to reconfigure apps, etc.

Simple and it works like magic.
original
un_ax@lemmy.today ⁨2⁩ ⁨hours⁩ ago
The other answers covered options on hooking up the internal DNS, so here is the https part for the sake of completeness.

One option is running an internal CA, but that’s for crazy people. And you have to distribute your root CA to every device using it, which can be annoying if you don’t have centralized configuration management in place.

If you want https with caddy and don’t want it exposed you can use a DNS challenge with your external DNS provider. Check the list here for your provider.

Assuming docker and your dns isn’t built in you build a custom docker image with the plugins you need. This is a Dockerfile for route53 based on here:

FROM caddy:builder AS builder RUN xcaddy build \ --with github.com/caddy-dns/route53 FROM caddy:alpine COPY --from=builder /usr/bin/caddy /usr/bin/caddy

And then a docker-compose.yml in the same dir to use it:

services: caddy: build: . restart: unless-stopped ports: - 80:80 - 443:443 - 443:443/udp volumes: - ./caddy_data:/data - ./caddy_config:/config - ./conf:/etc/caddy

With this mount setup you write conf/Caddyfile and include the DNS provider specific configuration relevant to your plugin, probably documented in its repo.
original
elvith@feddit.org ⁨3⁩ ⁨hours⁩ ago
My current setup for this:

I own a domain - say homelab.com - and use it exclusively in my internal network.

The public DNS records do only resolve to 127.0.0.1 (as my domain holster doesn’t want me to have no A record).

In my home network I have a pihole running that resolves this domain and it’s subdomains locally (say pihole.homelab.com, proxmox.homelab.com and so on).

For HTTPs: As this server is not publicly reachable, I use the DNS API of my domain host to get a let’s encrypt certificate with the DNS-01 challenge. That way, the internal systems do not need to be exposed to the internet.

original

BlueEther@no.lastname.nz ⁨5⁩ ⁨hours⁩ ago

I have AdGuard Home running on OPNSense as a local DNS with a wild card for for the ‘local domain’ pointing to Caddy

in Caddy I have this section:

*.<domain>.net {
#header X-Frame-Options "SAMEORIGIN"
        tls internal
        encode gzip
        import sec-headers
        @sub1 host pve.<domain>.net
        @sub2 host kasm.<domain>.net
       ...
       handle @sub1 {
                import sec-headers
                reverse_proxy * https://10.1.1.11:8006/ {
                        transport http {
                                tls_insecure_skip_verify
                        }
                #       header_up Host {host}
                       header_up X-Real-IP {remote}
                       header_up X-Forwarded-For {remote}
                       header_up X-Forwarded-Port {server_port}
                       header_up X-Forwarded-Proto {scheme}
                }
        }
        handle @sub2 {
                import sec-headers
                reverse_proxy  https://10.1.1.119/ {
                        transport http {
                                tls_insecure_skip_verify
                        }
                #       header_up Host {host}
                       header_up X-Real-IP {remote}
                       header_up X-Forwarded-For {remote}
                       header_up X-Forwarded-Port {server_port}
                       header_up X-Forwarded-Proto {scheme}
                }
        }
...

original

konem@lemmy.today ⁨5⁩ ⁨hours⁩ ago
You pretty much have four options, ranging from fully local to network level to VPN to public.

1.) Good old hosts file. Pro: Easy on linux. Cons: Doesn’t automatically update, needs to be installed manually on each device, some devices (phones) are harder to setup.

2.) Set DNS records using your router to your local ip, or if it does not support adding DNS records, then use a service like pi hole as your DNS server. Even external DNS providers like Adguard or Cloudflare should work, if you register with an account. You should be able to set up a DNS record for each subdomain, or do something like *.myhost.internal to catch all subdomains. Using the .internal TLD is highly recommended in this setup. Pros: Simple to set up, the router should inform all devices about the changes in DNS. Cons: To get rid of SSL warnings you will need to install the Caddy Root Certificate as a trusted agent on each device.

3.) Use a service like tailscale or netbird that offers automatic DNS and allows you to bind services (ports) to domain names. Pro: Allows access from anywhere. Cons: Needs to be installed on every device accessing it.

4.) Setting up a public DNS with a private IP address. Makes things a lot more complicated if you want to use let’s encrypt. Will need to do something like split dns and has to expose the port for the ACME challenge.

Instead of using let’s encrypt, you may again install the Root Certificates like in step 2 on every device to reduce the complexity by a good amount. Beware that binding public DNS to local IPs is considered bad practice, as it allows for DNS rebinding attacks. Some browsers and devices will complain (unless you use a .internal domain, but these can’t be registered publicly). Pro: If done properly, then, in principle, it should work on any device without setup. Cons: The hardest way of setting things up. Need to open up the network to allow automatic SSL certification. Some devices see this as a security threat.

If you decide on one of these paths, it is easier to recommend a guide for a specific setup. I feel like your question is mixing up some of these options. I’d also be happy to answer questions on anything but 4.

original
- petrichornetrainfall@piefed.social ⁨4⁩ ⁨hours⁩ ago
  So right now im kind of doing option 1, but .local (I’ll switch to .internal) and not using * ( which I will change and see if it let’s me use the subdomains I configured in caddy that werent working before)
  
  Option 2 it what I considered switching too, I have adguard running on my router, but was testing option 1 when I decided that I might want to skip ahead to something more advanced. I really dont want to have to install certs on each device to get past the warning for https.
  
  Option 3 is on my backlog, I have a vps I planned on setting up pangolin on later down the road after I got some of my services spun up, but maybe I should take care of that now instead.
  
  Option 4 is something I briefly looked into before realizing its way over my head, and im also pretty risk adverse.
  
  Sumarry: so maybe option 3, and possible option 2 if its still needed when on my local network without having a client running.
  
  original
the_q@piefed.social ⁨5⁩ ⁨hours⁩ ago
Have you looked into nginix proxy manager? You set a DNS record from your domain to point to your public facing ipv4 address and in nginix you create a profile for each local service with its local IP. The options within each profile can do things like getting a let’s encrypt cert and other security settings. You’ll have to open ports on your router as well, but I can remember which ones from memory and I’m not at my PC to look for you.

original
Reannlegge@lemmy.ca ⁨4⁩ ⁨hours⁩ ago
I have a flint 2 (glinet) as my firewall as well, I had read somewhere that I should install vanilla OpenWRT so I did (I have added stuff to it so I like coming up with different flavours when talking to people like rocky road). I have Caddy running in docker on a pi in my LAN I have a password file of some sort that Caddyfile references at the top. Don’t ask me how I formatted it because I do not remember that part but take my secondary pihole as an example of using a domain that cannot be reached, touched from outside of my lan.

‘pihole52.mydomain.ca { @allowed { remote_ip 10.0.0.0/8 } handle @allowed { redir / /admin{uri} reverse_proxy 10.0.69.52:31415 } handle { respond “Not available from this network” 403 } import easydns_tls log { output file /var/log/caddy/pihole52.log format json } }’

While other places on my domain can be reach outside of my vLANs. I have to secure some things up as I found that my SearXNG is open to the WAN.

original
MarauderIIC@lemmy.zip ⁨6⁩ ⁨hours⁩ ago
I am not an expert but I’ve dabbled on this before some years ago.

If you don’t need it exposed publicly, you just need a local DNS server like bind or dnsmasq set up somewhere on the local network, or edit the hosts files on your individual machines to hard code your local network service IPs for those machines. You don’t need a purchased domain name to advertise domains locally. It’s probably also possible for each machine to advertise its DNS without a central server, but it’s outside of my expertise.

Exposing port services with a domain name is a lot trickier but it’s doable in various ways. A cursory search says SRV records or setting up a proxy on your local network. It’s been a long time since I’ve attempted this. Optimally your host and client will just be configured to use the correct ports already, like port 80 for http and port 443 for https and whatever the default port is for your other services, so that you can use the same hostname per IP.

Since it’s all on your local network I wouldn’t bother with encryption/self signed certs, unless your risk profile includes randos on your network sniffing your services.

I don’t have guides handy but maybe some of those keywords will help. If you’re not staunchly anti-ai, it’s a common enough scenario for something like chatgpt to guide you through.

original