One advantage of the DNS01 approach is that you can also order certificates for standby instances behind a load balancer, all fronted by the same domain name. Since the standbys are not serving traffic, you can't get an HTTP01 challenge/response through, but you can still do so with DNS01 and get a certificate delivered to that machine, so that it's always ready to serve TLS in the event of a failover.

I own example.com and actually created NS records for internal.example.com, to manage that entire zone at an entirely different provider. I did that because the original provider had terrible API access for Caddy to use. The new one has better support, and a breach there does not pwn the root domain. I was happy with that setup, but wasn’t aware one could delegate to an entirely different domain using ACME primitives. Makes sense though, it’s like the NS approach but simpler, and allows using some throwaway domain. Thanks!

tls-alpn-01 woks really well as well. You don't have to mess with DNS at all, or have an HTTP port open; you just listen on HTTPS.

Yeah, except for the the internal-only server part where the hostname may not even be accessible to the public Internet (certainly not as an A(AAA) record).

And given the number of internal applications many large/r organizations have, giving all those internal dev teams update access to the main corporate domain is not something I'd really feel comfortable doing.

But being able to give API access to (e.g.) foo.dnsauth.example.com is something I have done: main domain needs to be touched once for the CNAME, and the sub-domain isn't critical for day-to-day operations of a company.

The post I was replying to used www.internal.example.com , which looked like a public name. Internal-only names should not look like subdomains of public DNS names.

But yes, if you want a certificate for a name that isn't accessible externally and can't be made accessible externally, dns-01 works.

> Internal-only names should not look like subdomains of public DNS names.

Since when? I, and many other people I know, have been doing that for decades.

If I (the company) own example.com, I can choose to have some sub-domains internal-only, some external-only, some DNS records resolve to the same IP value regardless of in/outside, and other DNS records resolve to different IP values depending on in/outside.

* https://en.wikipedia.org/wiki/Split-horizon_DNS

However, internal domains should have their top domain externally registered and controlled... so ultimately there's no difference because you're going to need at least a dummy zone file to satisfy registrar.

> However, internal domains should have their top domain externally registered and controlled

Not necessarily. `.internal` exists for that purpose, and people have historically used `.lan` for similar purposes. There's no particular reason internal names need to have resolvable DNS names of any kind, if they're not going to be externally accessible, unless you're trying to do something like dns-01.

> Not necessarily. `.internal` exists for that purpose …

.internal is being considered for that purpose:

> IANA has performed an evaluation to determine a suitable string to be reserved for the purpose of a top-level domain that may be used for internal or private use applications. The string “INTERNAL” has been identified as appropriate for this purpose.

> In accordance with the process described by ICANN, this assessment will be put for a public comment proceeding, followed by review and potential adoption by ICANN.

* https://itp.cdn.icann.org/en/files/root-system/identificatio...

* https://www.theregister.com/2024/01/29/icann_internal_tld/

There is now not (yet?), nor has there ever been, any label officially set aside for that purpose.

> … and people have historically used `.lan` for similar purposes.

People have also used .dev for their development environment, and we all saw how well that worked out:

* https://en.wikipedia.org/wiki/.dev

> There's no particular reason internal names need to have resolvable DNS names of any kind […]

Sure there are: for putting into a certificate which can be linked to a public certificate authority (CA) so that users don't have to install a custom/private CA just to use internal services. I'm at a place where the dumbass team before me used an internal-only TLD (lan/local/internal), and now we (the new team) can't issue certs for things internally.

I did specifically say "unless you're trying to do something like dns-01". If you want to issue public certificates for your internal domains, by all means use a public name for them.

In my experience, you can and will encounter a situation with conflicting resolvings of .internal unless the use is all properly scoped to broadcast and administrative zones (ha ha ha fat chance, though respect to anyone who really tries).

.lan, .home, and similar have the issue that they aren't actually reserved so they can conflict (see the land-grab of .dev that Google did after ICANN opened up TLDs).

The one way that has most stability (and is best recommendation I have seen) is to have a publicly reserved zone, which doesn't need to have anything other than NS records pointing to hostnames visible from your internal networks (I am always tempted to have essentially NS -> AAAA + PTR pointing at anycast internal v6 address).

Turns out it does not need to be separate domain from some other domain of yours, it can be let's say i.your-company-name.com. - I am partial to your-company-name.net. but that can be confusing for less computer crazy people.