Why Dynamic DNS is essential for homelab setups with a public IPv4
People running self-hosted services like game servers, file shares, or mail often face the challenge of connecting reliably from outside their home network. This is where DDNS (Dynamic Domain Name System, or DynDNS) becomes a key tool - especially for those with public IPv4 addresses. However, DDNS does not work the same for everyone, and Carrier-Grade NATs (CGNAT) often create limitations and get in the way.
What is DDNS?
DDNS allows you to automatically update DNS records with your dynamic external IPv4 address, so you can access your services easily using a domain name instead of memorizing IPs. If your home ISP gives you a non-static (dynamic) IP and you want to access your server at server.example.hexname.com, DDNS providers keep this domain pointed to your current public IP.
For example, by creating an A record for home.example.hexname.com at a service like HexName, and by periodically running a simple script on your home network, anyone connecting to this hostname will reach your actual home server - even if your IP changes every day.
This script could look something like this:
#!/bin/bash
IP=$(curl -s http://ipv4.icanhazip.com)
curl -X PUT https://hexname.com/api/v1/ddns/ipv4/[YOUR_TOKEN_HERE]/$IPHow CGNATs prevents DDNS from working
Many ISPs now use Carrier-Grade NATs to conserve limited IPv4 space. Instead of assigning a unique public address to each customer, ISPs put many users behind a single external IP. Your router gets a local address (like 100.64.0.15), and only the ISP’s shared gateway gets a publically routable IP address.
Because of this extra layer, DDNS updates the DNS record to point to your ISP’s shared IP. Connections from the outside will never reach your router directly, since the ISP’s router won’t know which host is meant by the packet. This is why DDNS is ineffective behind CGNAT, and cannot open inbound connections for you, no matter the DNS configuration.
If you want to learn more, check out this blog on details on why CGNATs were invented, and how they work.
How to check if you have a public IPv4
To confirm you’re not behind CGNAT:
- Log in to your router’s web interface in the browser. This is usually at
192.168.1.1or192.168.0.1. - Find the section labeled “Status,” “Internet,” or “WAN” (Wide Area Network).
- Look for your displayed “external IPv4 address” and note it down.
Next, look up “What is my IP” online and compare it with the router’s external IPv4. If they match, you have a “real” publically routable IP and DDNS will work as expected.
Otherwise, you’re behind a CGNAT and will have to look for other options for exposing your services to the world.
Alternatively you can tell if you’re behind a CGNAT if the external IP in the router’s interface is in the private range (e.g.,
100.64.0.0/10,10.0.0.0/8,192.168.0.0/16, or172.16.0.0/12).
Some ISPs offer public IPs as a paid feature, so it’s worth looking into if you’d benefit from DDNS.
Example DDNS usage in a homelab
If you have a true public IPv4, register a subdomain like example.hexname.com on HexName, and set up a DDNS script to keep your record updated. This makes it possible to access your homelab remotely, run services, or even share files with friends securely, without worrying about changing IPs, proxying, or complicated URL sharing.
Homelabbing is the backbone of private cloud, self-hosted apps, and can teach you a lot about real-world networking. Understanding the underlying technology is crucial for maintaining a secure deployment.