Dynamic DNS With Starlink: When It Helps and When It Does Not

Dynamic DNS (DDNS) gives a changing internet address a consistent hostname, such as home.example.com. That can make remote access easier after an address change, but DDNS does not create a public IP address and it does not bypass Starlink CGNAT.

Use this guide to decide whether DDNS is useful for your Starlink connection, configure it without exposing more than necessary, and test the result from outside your home network.

What DDNS does - and what it cannot do

A DDNS updater checks the address used by your router, NAS or another always-on device. When that address changes, it updates a DNS record so your hostname points to the new address.

That solves the naming problem. It does not solve the reachability problem.

If Starlink places your connection behind carrier-grade NAT (CGNAT), unsolicited inbound IPv4 connections normally cannot reach your router. A DDNS hostname may still resolve correctly, but it will point at an address that is shared or not directly assigned to your kit. Port forwarding on your own router cannot remove that upstream barrier.

Step 1: Check whether your Starlink connection is reachable

Do this before registering a hostname or opening a port.

1. Open the router or third-party router's Internet, WAN or status page.
2. Note the IPv4 address shown for the Starlink-facing interface.
3. Check your current public IPv4 address using a reputable address-check page from a device on your Starlink network.
4. Compare the two values.

Treat the connection as CGNAT or otherwise not directly reachable if the router shows an address in one of these private or shared ranges:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• 100.64.0.0/10, commonly used for carrier-grade NAT

A mismatch between the router's WAN address and the address seen on the internet is also a strong warning. It does not prove every possible inbound path is unavailable, but it means ordinary IPv4 port forwarding plus DDNS is unlikely to work.

Do not assume that a plan name, a router reboot or a DDNS record proves you have a public address. Check the path from your own equipment.

Step 2: Choose the right access method

If you have a public IPv4 address

DDNS can be useful when your public address changes.

Choose a DDNS provider, create a hostname and generate the narrowest update credential it offers. Then configure one updater on an always-on device:

• A third-party router is usually the most reliable place.
• A NAS or small server can run an updater if the router cannot.
• Avoid running several updaters for the same hostname unless you understand which address each one reports.

Configure only the service you actually need. Use a dedicated hostname, strong authentication and the service's own encryption. Create a single, narrow firewall or port-forward rule, then test it from a phone on cellular data or another network. Do not use a test from inside your home Wi-Fi as proof that outside access works; some routers support local loopback and some do not.

If you are behind CGNAT

DDNS alone will not make an inbound IPv4 service reachable. Prefer an outbound connection that your device initiates, such as an overlay VPN or a managed tunnel. Tailscale, for example, can provide private access without asking Starlink to accept unsolicited inbound traffic.

If you need a public endpoint for a website or webhook, use a service designed to publish an outbound tunnel, or place the public-facing service on a hosted server and connect back to home privately. Keep the home router's firewall closed unless you have a specific, tested reason to open a rule.

If you plan to use IPv6

Some Starlink setups and third-party routers can provide IPv6, but support and address behaviour vary. Treat IPv6 as a separate path:

• Confirm the client has a globally routable IPv6 address, not only a local address.
• Confirm the prefix is stable enough for your use case.
• Create or update an AAAA record rather than an A record.
• Keep the IPv6 firewall default-deny and allow only the required service.
• Test from a network that has working IPv6.

A hostname that works over IPv6 does not automatically make the service reachable over IPv4. Test both paths if your users or devices may use either.

Step 3: Configure and verify the updater

The exact screens vary by router and DDNS provider, but the safe sequence is the same:

1. Create the hostname and record type you need.
2. Generate an update token or limited credential.
3. Enter the provider, hostname and token on one updater.
4. Set the updater to check periodically, not continuously.
5. Confirm the provider's dashboard shows the address you expect.
6. Record the time of the last successful update.
7. Change or renew the connection only when you can observe the result.

If the updater reports your router's private or CGNAT address, stop and fix the reachability problem rather than forwarding ports to it. Some providers let the updater request the address it sees from an external service; that can be useful, but it still does not bypass CGNAT.

Step 4: Test from outside the Starlink network

Use a real external test:

• Resolve the hostname over the internet and confirm the record is current.
• Test the required port from cellular data or another broadband connection.
• Sign in with the service's normal encrypted method.
• Check the router, device and DDNS logs for the same connection time.
• Test after a controlled address change or reconnect.
• Test IPv4 and IPv6 separately if both are enabled.

If the hostname resolves but the connection times out, the likely causes are CGNAT, a closed firewall, a missing port-forward rule, the wrong internal address or a service that is not listening. If it works by IP address but not by hostname, check the DNS record, cached results and whether the service expects a particular hostname.

Common mistakes

• “DDNS is working, so port forwarding should work.” DDNS only updates a name. It does not create an inbound route.
• “The public address page matches my old router address.” Re-check after reconnecting; Starlink and upstream providers can change addressing.
• “The service works on home Wi-Fi.” That may be local access or router loopback, not internet access.
• “I opened several ports to make testing easier.” Remove unused rules immediately and test one service at a time.
• “IPv6 is enabled, so everything is public.” A global address still needs an allow rule, and a firewall is still essential.
• “The hostname must be updated from the Starlink router.” If the Starlink router has no DDNS client, use the router that actually controls your LAN or an always-on device.

Quick checklist

Before relying on Starlink DDNS, confirm:

• Your router's WAN address and the externally observed address are understood.
• You know whether CGNAT blocks the IPv4 path.
• Only one updater manages the hostname.
• The updater uses a limited credential and reports successful changes.
• Only the required service is exposed, with encryption and strong authentication.
• You have tested from outside the Starlink network.
• You have a private overlay VPN or managed tunnel ready if direct inbound access is unavailable.

The practical rule is simple: DDNS is useful for keeping a name current, but it is not a substitute for a reachable public address.