How To Design Your UCS Domain To Use Public DNS Names
You consider using some apps (it Owncloud or Nextcloud) not only from your internal network but make them available through the Internet, too.
Thing to Consider
When accessing a server from different networks (ie your local network and public internet) your clients access the server withe their DNS names. Usually they use the full qualified domain name (FQDN, ie
Usually your internal domain name is not public visible. Your might think of choosing domain names like this:
Note: You should NOT use a domain ending with “
.local” as it is defined to be used for other purpose and is depreceated in Windows, too.
Common for all following scenarios:
- You have a static public IP address available
- The DNS name “
nextcloud.domain.com” is assigned to this IP address and public available
- Your Firewall forwards any requests to this public IP to your server in question (ie Nextcloud server)
- It is recommended to place this sever in a dedicated demilitarized zone (DMZ)
Scenario 1: Using domain
domain.lan with internal hostname for server
Now when accessing a server from your LAN the FQDN could be
nextcloud.domain.lan. Your clients match the servers SSL certificate to the name and can easily access the service.
As soon as the clients try to access the server from Internet they are unable to resolve “
nextcloud.domain.lan” and will not be able to connect. This is because the “
domain.lan” is not public.
Scenario 2: Using domain “
domain.lan” with external hostname for server
So you might consider telling your clients to use the external hostname
nextcloud.domain.com to connect to.
The hostname of the server is
nextcloud.company.lan and thus the SSL certificates will not match the hostname (
nextcloud.domain.com) used by the clients. Connection will fail.
domain.lan with external hostname and additional certificates
You installed official certificates matching your public FQDN. You clients are configured to use public DNS name.
Your reverse zone (matching from IP to DNS names) might point to the internal server name (with a different domain name) and depending on the service your clients might complain and refuse to connect.
Scenario 4: Use public domain
domain.com for internal purposes, too
With this scenario you will not have any issues as all DNS entries and SSL certificates match the correct name.
You will have to synchronize the internal and external domain.com manually. Any changes to public entries should be added to the internal domain, too. But internal names should not be visible to public.
Scenario 5: Use internally a subdomain of your public domain
internal.domain.com as internal domain name. Thus there is no need to match entries manually and you can you external hostname for your clients.
Still, you need to install SSL certificates with the public name of your server and there might be a mismatch in reverse zone.