In general I think it boils down to the title;
If you have a testing machine (vm) and give it the FQDN test.nstestdomain.local you have a hard time testing web related stuff if they rely on URLâs in their configuration. You like to be able to set an old fashioned external domain name.
Examples are the quoted threadâs:
Resolvable DNS record for acme-dns
clone url for gitea
To give all those apps a domain or vhost db-prop to overcome this does not feel like a nice solution.
Creating (a) server alias(es) gives no relive, at expansion of a configuration template you can not know which to choose: Server_FQDN, first alias, second alias �??..
Discussion:
Are this corner cases? -or-
move on your setup is old fashioned?
I really thought about using real domain names because of these problems, but
using an internal domain name may be old fashioned and may be wrong but is still used widely.
as soon as you installed some account provider changing domainname does not work without reinstalling.
for most apps it just doesnât matter but for apps using domains (like acme-dns) it may be necessary to use other domains or when we are using vhosts we need a possibility to not use the default domain. This is true even if you used an external (resolvable) domain name.
Iâm not sure I understand the question. In the case of acme-dns, itâs a public DNS server. It must run on a public domain name (it can be any domain you like, as long as you control it), and it must be publicly accessible. The only âweb appâ piece of it is the API for updates, and that (if you donât use HTTPS) can be reached by IP address or in any other way you want.
