DNS is a service for converting human-readable strings (panel.example.com ) to the IP address ( As a rule, the entries in it change quite slowly (up to several days). They are added much faster (up to hours).


DDNS – dynamic DNS – is designed for the case when the record changes frequently, maybe several times a day. In practice, it is necessary for home servers, because the provider can issue “dynamic IP addresses” that can change at any time. Many routers contain simplified settings for such servers.

The main problem is that now most providers have stopped issuing real dynamic IP addresses (because there are no free IPv4 addresses anymore), but they issue “gray ip”. It is shared with several other subscribers, and therefore you will not get much access from the outside. In this case, you need to order a “permanent IP address” service, and then DDNS is not needed. So it’s more of an outdated technology.

It is a separate story that providers can block certain ports for all types of IP addresses or for certain types. For example, port 25 is usually blocked. So it’s impossible to raise your email server at home. It is motivated by the fact that many users have viruses and they send spam, and for this the entire network gets blacklisted.

Crossing DNS CNAME and DDNS

DDNS often provide a rather ugly domain (something.no-ip.org ) on a free tariff. If you have your own domain, you can make a link in DNS (using a CNAME record):

cloud.example.com СNAME something.no-ip.org

It’s interesting enough, but due to the dying of DDNS, it’s not really necessary.


mDNS – multicast DNS – technology for local area networks. Each computer sends out what name it wants to respond to and what services it provides. As a rule, the domain “.local” is used.

This is how, for example, network printer auto-detection works. Or NAS devices.

It’s a very convenient thing.

What does this mean for the home cloud?

If external access is needed, then:

  • it is necessary to clarify with the provider which IP address is issued (gray or full-fledged dynamic). Probably gray. Then order a permanent IP address service. Set up port forwarding on the router (most likely 80 and 443) to the desired home server.
  • use some kind of service that the server/router joins, and it redirects traffic to you. There are Keenetic routers (only for their admin panel), Tailscale, [ngrok](https://ngrok.com /), maybe some others.
  • Use a VPN on your router to log into your home network.

It is recommended to use the .lan domain by default at home. For example, a computer named cloud will have the full name `cloud.lan’. This requires some kind of configuration on the router (at least specify the local domain).

It is also recommended to use mDNS. Then the computer named cloud will also have the full name `cloud.local’. This is configured on the cloud computer itself and does not require centralized settings.

Let’s imagine that we have a Nextcloud application running to the container and it is available on port 30002. We also have a web server running on ports 80 and 443 as a load balancer (LB): it takes over encryption and access to different applications using different domain names, not different ports (ports are easier than IP addresses, but people still don’t like them).

Then, within the network, this application can be accessed in the following ways:

  1. https://nextclout.example.com (via LB using a public domain, https certificate from Let’s Encrypt)
  2. https://nextclout.example.com:9443 (using a public domain via LB, an https certificate from Let’s Encrypt; the port differs from the default so that traffic from the router is sent to it and not everything looks out, but only what should)
  3. https://nextcloud.local (via LB using mDNS, a self-signed https certificate)
  4. https://nextcloud.lan (via LB using internal DNS, self-signed https certificate)
  5. https://nextcloud.lan.mydomain.com (via LB using internal and/or external DNS, https certificate from Let’s Encrypt)
  6. http://nextcloud.local:30002 (directly using mDNS, without encryption)
  7. http://nextcloud.lan:30002 (directly using the internal DNS, without encryption)
  8. http://cloud.local:30002 (directly using the mDNS server name, without encryption)
  9. http://cloud.lan:30002 (directly using the internal DNS name of the server, without encryption)
  10. (directly using the server’s IP address, without encryption)

In general, it is better to use encryption options. Access without encryption can be restricted either in the application itself (browser headers are added) or at the firewall level (on the server or on a network device).

It is also possible for each application in the home network to allocate its own IP address so as not to communicate with ports like 30002, but there is no special point in this: it adds time for settings, but there are still few advantages - few people will eventually use the IP address, configure the https certificate separately for each application, etc.

To avoid using self-signed https certificates, you can get a wildcard certificate (*.lan.example.com or *.example.com ) from Let’s Encypt (free). wildcard certificate certificates are needed so that it is not visible which services are running (because the list of all certificates is public information). This is somewhat more difficult, because it requires DNS verification (either manually done once every 3 months (my option), or integrated with your DNS provider’s API, if it has one), but it still looks attractive. So far, I’ve set it up manually.