[xurukefi]

Or...

- Don't use split DNS. Don't use any special internal or dev domain. Leave it to your infrastructure to route/NAT those public IPs to your internal network.

- Don't use the HTTP-01 challenge. Use DNS-01.

- Don't run your own internal CA. Use Let's Encrypt. If you care about name leakage (CT Logs), use wildcard certs. Use a central reverse proxy/load balancer for termination.

[Walf]

>Don't use split DNS

So what's your solution when you have a wholly private service that will never have a public v4 address, nor a publicly routable v6? How do clients get the address for a nice domain name without the addresses in public DNS?

I use acme.sh with DNS validation, and use common domains that have both public and private services on subdomains. I use split horizon so private.domain.example resolves only on LAN and VPN, and public.domain.example resolves everywhere, but the address changes depending on the network one is connected to.

[xurukefi]

> How do clients get the address for a nice domain name without the addresses in public DNS?

They don’t. You put the addresses in public DNS.

[Walf]

Yeah, nah. Won't be doing that.

[vaughnegut]

Why not? It's easy to set up and manage and it just points at an internal IP address

[Walf]

I consider that an unnecessary leak of private topology, it's not info that needs to be public. IPv6 addresses are not really ever internal, and an exploitable vulnerability in a firewall product leads to the possibility of a directly addressable target. Guessing a v6 address without a name pointing to it is impractical at best.

[master_crab]

Wait…what? You have a fully internal service and you dont have an internal DNS server? I guess those exist in theory, but not in practice. :)

If you have a heavy enough tech stack to run fully internal services, than you can also run an internal DNS service (even pihole is enough) and load internal only entries there.

Or add everything to your hosts file if you have a central config service.

[Walf]

What, indeed. Yes, I have internal DNS servers. They are what handle the split horizons. How would one do split horizon without an internal DNS service?

[master_crab]

You don’t. You avoid split horizon because of the silent (usually failure) mechanics it introduces.

[Walf]

I wasn't talking about your opinion of it, I was simply using a rhetorical question to point out the nonsensical premise of your response:

>Wait…what? You have a fully internal service and you dont have an internal DNS server?

You can't do split horizon without an internal DNS service. By definition it's a non-public service that gives separate results to public.

[master_crab]

Because I was responding to this comment you had made:

So what's your solution when you have a wholly private service that will never have a public v4 address, nor a publicly routable v6? How do clients get the address for a nice domain name without the addresses in public DNS?

Which, if you claim you use private DNS, you know you can indeed solve by only having the private records sit on your private DNS service that can only be hit by clients on the internal network. Without the architectural bad practice of implementing split horizon.

[jeroenhd]

Using wildcard certs and/or a central reverse proxy defeats the purpose of internal TLS.

Split-horizon DNS for a publicly usable domain is almost always a bad idea, but running your own ACME server is pretty easy (maybe 10 lines of Caddy config) and using an internal domain (an actual one, not a randomly picked TLD you don't think exists yet) solves the problem pretty easily. You'll want a safe backup for your root certificate private key, of course, but that's pretty much all you need to really worry about.

[preisschild]

> Use a central reverse proxy/load balancer for termination.

If you do that anyways, you could also use something like oidc authN/authZ on the reverse proxy level and just expose it to the internet.

You dont even need to self host the oidc idp, you can use Google/Github or even something like ATProto

[Plasmoid]

Let's encrypt is great but if you operate any kind of scale you can quickly hit their rate limit. AWS only recently started allowing you to pull the certificate out of ACM.