FreeDNS Updates Your IP but Your Home Server Is Still Unreachable
At home the NAS works, and the FreeDNS hostname already resolves to your current IP, yet connections from outside time out. What sits between that address and your server?
- A successful FreeDNS update changes where a hostname points.
- The server, forwarding rule and firewall still determine whether a connection reaches the application.
- A changing public IP can work; an upstream NAT you cannot configure is a different obstacle.
A stable name does not establish an inbound connection
FreeDNS can keep a home server’s name usable as its IP changes. It does not start the application or configure the router’s forwarding rules. A successful update therefore answers only the naming part of the problem.
The service supports names pointing to home networks, workplaces and hosted systems. A recent Hacker News discussion brought renewed attention to those uses, including router compatibility. For someone troubleshooting access, the useful question is which part of the connection has actually succeeded.
An old DNS answer points to updating or caching
Check whether the hostname resolves to the current external IP. If it does not, inspect the record and the client responsible for updating it.
According to FreeDNS FAQ item 12, a changed record can coexist temporarily with cached answers on a computer or ISP resolver. The FAQ gives a default TTL of 3,600 seconds. That explains a possible stale answer; it does not mean every connection failure needs an hour of waiting.
A correct address moves the investigation to the service
TP-Link’s forwarding guide separates local server access, forwarding rules, WAN addressing and firewall checks. These are useful checkpoints for locating the failure:
| Observation | Next check |
|---|---|
| The hostname returns an old IP | The updater, DNS record and cached answer. |
| The service fails on its local IP and port | The application and access to its listening port. |
| Local access works; external access fails | The forwarding destination, port and WAN address. |
| The router has a private or shared WAN address | The upstream NAT and availability of a public IP. |
A forwarding rule must target the correct internal device and service port. DDNS does not repair that mapping. Check the relevant firewall permission rather than treating a permanently disabled firewall as the solution.
You may need a public IP without needing a static one
Dynamic DNS is designed to accommodate address changes. Public reachability is a separate condition. TP-Link’s DDNS guidance explains that a private or CGNAT WAN address indicates another NAT device upstream.
If that is another router you control, its forwarding configuration also matters. If it belongs to the ISP, changing your home router cannot configure it. Ask the provider whether a public IP is available. The shared range to recognize includes 100.64.0.0–100.127.255.255.
Start with the DNS answer, then test the local service and inspect the inbound path. Once the name points to the right address, repeatedly saving the same DDNS setting stops being a useful diagnostic step.