First of all, have you stacking the public and private subdomains on the same base domain? It’s what I do at the moment, I have external services on *.mydomain.com and internal services on *.home.mydomain.com.

You can get one wildcard cert for *.mydomain.com and one for *.local.mydomain.com so all your services are protected by TLS, both inside and outside your LAN. You also get to manage all of them identically in the same place (Traefik in your case).

You do NOT have to define any of these domains in DNS in order to pass the Let’s Encrypt DNS challenge. LE doesn’t care what you’ll put in DNS, just wants to verify the domain is yours. So just giving it an API token with access to mydomain.com is enough. (If your DNS provider doesn’t offer API check out this list of providers.)

It’s important to understand that the reverse proxy doesn’t actually care about DNS and whether those domains resolve, it just looks for the domain in the HTTP headers. So you can define those domains anywhere you want. You have several options:

1. For the public subdomains you need to define them in your public DNS, so you can resolve them from anywhere on the Internet. Let’s say your server IP is 1.2.3.4. You define an A record pointing mydomain.com to 1.2.3.4, and a wildcard CNAME that points *.mydomain.com to mydomain.com. Now all the subdomains directly under mydomain.com resolve to that IP.
2. For the private subdomains you have several options:
   • Best approach is to do the same as above for *.home.mydomain.com, but do in on the private DNS used on your LAN, and point to the LAN IP of your server instead of your public IP.
   • If for whatever reason your LAN DNS can’t do this (or you can’t control it) you can put the entries in the public DNS. It’s a bit unorthodox putting private LAN stuff in a public DNS but it works.
   • You can even define sub.home.mydomain.net names in the local hosts file on your PC, if you only need to access them from the PC. You only need to trick your browser into resolving them so it will put them in the HTTP headers, the reverse proxy doesn’t care.

An important note about security, because someone has already mentioned this in another comment. There are malware bots that keep scanning domains and IPs and ports looking for apps, and then they try exploits to try to break in. Having services exposed publicly without an extra authentication in front can make you vulnerable to these bots. It’s not a question of if they’ll find your app, it’s a question of when. You can mitigate the risk by blacklisting IPs in your router, for example you can blacklist anything that’s not coming from your country, but that only reduces the surface, does not completely eliminate the threat.

The bots also scan issued Let’s Encrypt certificates (which are a matter of public record) which is why it’s important to only get wildcard (*.mydomain.com) certificates, never explicit subdomains (sub.mydomain.com). It’s also important to never link to your services from web pages or share them with others.

Assuming you keep the subdomains for yourself, and you get a wildcard cert, and you use a reverse proxy, and you make the domain not easy to guess (don’t use something like “calendar.mydomain.com”) then you can very effectively prevent bots from getting to your services. That’s because the reverse proxy won’t honor requests if it doesn’t recognize the full domain name. So the subdomain can act as a sort of access key if you make it long enough (63 chars limit per subdomain, 255 max limit on the entire domain). That’s a pretty respectable key length… as long as you don’t publish it anywhere (only define it on the reverse proxy and your phone for example).