[EvanAnderson]

I feel like I did. >smile<

> Use DNS validation to allow these internal services to pull ACME certs...

The major ACME clients support DNS validation. If your DNS host doesn't have an API that your ACME client supports either get a new ACME client or a new DNS host.

[jve]

That's for the cert part, yeah, got it.

I thought you have a solution to overcome not having to do split DNS where I define public IP in public DNS and internal IP within some local hosted DNS.

Like how to make so that when connecting from inside local network the router recognize that by connecting to public IP, he has to route it back onto some local IP address?

[EvanAnderson]

Hairpin NAT (or "NAT hairpinning") is the term for "...connecting from inside local network the router recognize that by connecting to public IP, he has to route it back onto some local IP address", and the Linux NAT implementation supports it.

For a homelab situation split-horizon DNS is just fine. You're going to have minimal duplication of records from the public DNS into the private DNS.

The canonical frustrating "bad split-horizon DNS" world I've seen, time and again, is a corporate network with a MSFT Active Directory named the same as the company's public-facing web property (e.g. "example.com" rather than "ad.example.com"). This creates the need to duplicate all the public-hosted resources into the internal "example.com" zone (and keep them updated when records inevitably change on the public Internet). It's make-work for no practical upside in that example.

[jve]

Okay, thanks. I thought split-DNS is a hack even at home.

Totally agree on the AD part - luckily we had an option to migrate to different domain and name our AD correctly :)

[EvanAnderson]

Ha! AD domain renames in the mid-2000's made a decent chunk of money for me.