What is DDNS? A Complete Guide to Understanding Dynamic DNS from Scratch

If you've ever wondered "how can I access my home computer from outside," sooner or later you'll come across the term DDNS. This article starts from the most fundamental concepts and breaks down the principles, workflow, and practical applications of DDNS step by step, helping you build a complete understanding.

Suppose you've set up a NAS at home, storing several terabytes of movies and photos. When you're at home, you can access it through the local network IP 192.168.1.100, and everything works fine.

But one day you're out and about, and you want to check the photos on your NAS — here's the problem:

How do you connect back to your home from outside?

You need to know your home router's public IP address. But the public IP assigned by your ISP to residential broadband is usually dynamic — it might be 43.132.141.21 today, and after restarting the router tomorrow, it could become 113.88.12.34. You can't exactly write down your home IP every time before you leave, can you?

DDNS was created to solve exactly this problem.

Its core idea can be summed up in one sentence: Let a fixed domain name always automatically point to your constantly changing IP address.

But to truly understand DDNS, we need to start with DNS.

Every server on the internet has a unique IP address, such as 93.184.216.34. When your browser wants to visit a website, what it ultimately needs is this IP address — because the underlying protocol of network communication (TCP/IP) only recognizes IPs, not domain names.

But humans can't remember strings of numbers. You can remember baidu.com, but you can't remember 39.156.66.10.

DNS (Domain Name System) is this translation layer. It works similarly to the contacts list on your phone:

• You saved a contact: Zhang San → 138xxxx1234
• When you make a call, you just look up "Zhang San," and your phone automatically dials the number

DNS does exactly the same thing:

You type in the browser: baidu.com
       ↓
Browser asks DNS: "What's the IP for baidu.com?"
       ↓
DNS responds: "39.156.66.10"
       ↓
Browser connects to 39.156.66.10, and the page loads

In the management console of a DNS provider (such as Alibaba Cloud or Cloudflare), you'll see a record table like this:

┌──────────────┬──────┬─────────────────┬──────┐
│ Host Record  │ Type │   Record Value  │ TTL  │
├──────────────┼──────┼─────────────────┼──────┤
│ www          │ A    │ 93.184.216.34   │ 600  │
│ blog         │ A    │ 93.184.216.35    │ 600  │
│ mail         │ MX   │ mail.example.com│ 3600 │
└──────────────┴──────┴─────────────────┴──────┘

Where:

• Host Record (RR): The subdomain part. For example, www represents www.example.com
• Type: An A record points to an IPv4 address, AAAA points to IPv6, and CNAME points to another domain name
• Record Value: The target that the domain ultimately points to
• TTL (Time To Live): How long this record can be cached (in seconds) — we'll cover this in detail later

For large companies' servers, IP addresses are fixed (they've purchased static IPs), so DNS records only need to be configured once and may not need to be changed for months or even years.

But for us ordinary home users, the IP changes. This introduces the concept of "dynamic."

There are only about 4.3 billion IPv4 addresses in total (2^32), and the number of internet-connected devices worldwide has long exceeded this figure. ISPs can't possibly assign a permanent, unchanging public IP to every household — there simply aren't enough IPs for that.

So ISPs adopted a dynamic allocation strategy: when your router connects to the ISP's network, the ISP temporarily assigns a public IP from an IP pool. When you disconnect, restart the router, or the lease expires, this IP may be reclaimed, and a new one will be assigned next time.

This is why your home's public IP changes — it's not "yours"; it's just temporarily lent to you.

Here's a pitfall that beginners are especially prone to: The IP you see on your computer is usually not a public IP.

Your home network structure looks roughly like this:

Internet
                          │
                    ┌─────┴─────────┐
                    │     ISP       │
                    │ Assigns Public│
                    │      IP       │
                    │ 43.132.141.21 │
                    └─────┬─────────┘
                          │
                    ┌─────┴─────┐
                    │  Router   │  ← Public IP is here
                    │  NAT      │
                    └──┬──┬──┬──┘
                       │  │  │
              ┌────────┘  │  └────────┐
              │           │           │
        ┌─────┴──────┐ ┌──┴────┐ ┌────┴────┐
        │ Your PC    │ │ Phone │ │  NAS    │
        │192.168.1.10│ │.1.11  │ │ .1.100  │
        └────────────┘ └───────┘ └─────────┘

The router uses NAT (Network Address Translation) technology to allow multiple devices on the internal network to share a single public IP for internet access. The 192.168.x.x you see on your computer is a private IP, which is only valid within your home LAN — people outside cannot reach you using this address.

Therefore, DDNS needs to obtain the router's public IP, not your computer's private IP.

Now that we understand the background of DNS and dynamic IPs, let's see how DDNS actually works.

The essence of DDNS is a continuously running program (usually called a DDNS client). What it does can be summarized as a constantly repeating loop:

┌─────────────────────────────────────────────────────────────┐
│                    DDNS Work Loop                            │
│                                                             │
│   ┌─────────┐     ┌──────────────┐     ┌────────────────┐  │
│   │ Step 1   │     │   Step 2      │     │    Step 3      │  │
│   │ Get the  │ ──→ │ Compare with  │ ──→ │ Call DNS       │  │
│   │ current  │     │ last IP —     │     │ provider API   │  │
│   │ public IP│     │ has it changed?│     │ to update      │  │
│   └─────────┘     └──────────────┘     └────────────────┘  │
│        ↑                  │                     │           │
│        │          Unchanged: skip          Update succeeded  │
│        │                  │                     │           │
│        └──────── Wait N minutes ←───────────────┘           │
└─────────────────────────────────────────────────────────────┘

Let's break down the technical details of each step below.

As mentioned earlier, the IP you see directly in your computer's network settings is a private IP, not a public IP. So how do you get the public IP?

Method: Send an HTTP request to an external server and let it tell you.

The principle is very simple: after your request passes through the router's NAT translation and reaches the external server, the source IP the server sees is your router's public IP. The server returns this IP as the response content.

Your PC                  Router                  External Server
   │                     │                   (api.ipify.org)
   │── HTTP Request ──→  │                        │
   │  (Src IP:192.168.1.10)│                     │
   │                     │── HTTP Request ──→      │
   │                     │  (Src IP:43.132.141.21) │
   │                     │                         │
   │                     │    ←── Response ──       │
   │                     │  "43.132.141.21"        │
   │    ←── Response ──  │                         │
   │  "43.132.141.21"   │                         │

Commonly used free IP lookup services include:

In actual projects, it's recommended to configure multiple services as fallbacks. If the first service times out or is unavailable, it automatically switches to the next one, improving reliability.

After obtaining the current public IP, the program compares it with the previously recorded IP:

• If they're the same: The IP hasn't changed, no action is needed — skip and wait for the next check
• If they're different: The IP has changed, and the DNS record needs to be updated

This step may seem simple, but it's an important optimization. Without this comparison, calling the DNS provider's API to update the record every time would not only waste request quotas but could also trigger the API's rate limit.

This is the most critical step. After detecting an IP change, the DDNS client needs to notify the DNS provider: "Point my domain to the new IP."

Major cloud service providers all offer DNS management API interfaces:

Taking Alibaba Cloud as an example, updating a DNS record typically requires two API calls:

First step: Query existing records

Call the DescribeDomainRecords interface, passing in the main domain and subdomain to check whether a corresponding resolution record already exists. If it exists, it returns a RecordId (the unique identifier of the record) and the current record value.

Request: DescribeDomainRecords
Parameters: DomainName=example.com, RRKeyWord=home

Response:
{
  "DomainRecords": {
    "Record": [{
      "RecordId": "123456789",
      "RR": "home",
      "Type": "A",
      "Value": "43.132.141.21"    ← Current old IP it points to
    }]
  }
}

Second step: Update the record (or create a new one)

• If the record exists: Call UpdateDomainRecord, passing in the RecordId and the new IP address
• If the record doesn't exist: Call AddDomainRecord to create a new resolution record

Request: UpdateDomainRecord
Parameters: RecordId=123456789, RR=home, Type=A, Value=113.88.12.34

Response: { "RecordId": "123456789" }   ← Update successful

After the update is complete, the record on the DNS provider's authoritative server has changed. From then on, when someone visits home.example.com, DNS will return the new IP address.

Calling a cloud provider's API isn't something just anyone can do — you need to prove that "this request was sent by me, and I have permission to operate on this domain." This is the purpose of API signature authentication.

Taking Alibaba Cloud's v3 signature as an example, the signing process is roughly as follows:

1. Concatenate all key information of the request (HTTP method, path,
   parameters, timestamp, etc.) into a string in a fixed format
   (called the "canonical request")

2. Compute a SHA-256 hash of this string

3. Using your AccessKey Secret as the key,
   perform an HMAC-SHA256 signature on the hash value

4. Place the signature result in the request's Authorization header

When the provider receives the request, it computes the signature in the same way. If it matches the one you sent, the request is considered legitimate. This mechanism ensures that even if the request is intercepted during transmission, an attacker cannot forge requests (because they don't have your Secret).

After one update is complete, the program waits for a period of time (e.g., 5 minutes), then starts again from Step 1. This loop continues indefinitely as long as the program is running.

Common scheduling methods:

• Built-in program timer: e.g., Node.js's setInterval(), Python's time.sleep() with a loop
• System-level scheduled tasks: Linux's cron, macOS's launchd
• Process managers: Use tools like PM2 or systemd to keep the script running in the background with auto-start on boot

Putting all the above steps together, a complete DDNS update flow looks like this:

[Timer triggers]
     │
     ▼
[Get current public IP]
     │
     ├── Using a fixed IP? ──Yes──→ Use the IP from config directly
     │                                    │
     └── No ──→ Request api.ipify.org     │
                    │                     │
                    ├── Success ──────────┤
                    │                     │
                    └── Failure → Try ifconfig.me
                                │
                                ├── Success ──→ ┐
                                │               │
                                └── Failure → Try icanhazip.com
                                              │
     ┌────────────────────────────────────────┘
     ▼
[Compare with last IP]
     │
     ├── Same ──→ Skip, wait for next check
     │
     └── Different ──→ [Query existing DNS records]
                            │
                            ├── Record exists, value already up to date ──→ No update needed
                            │
                            ├── Record exists, value differs ──→ Call UpdateDomainRecord
                            │
                            └── Record doesn't exist ──→ Call AddDomainRecord
                                                    │
                                                    ▼
                                            [Update successful, remember current IP]
                                                    │
                                                    ▼
                                            [Wait N minutes, start over]

You'll notice several key optimization points here:

1. Skip if IP hasn't changed: Avoids meaningless API calls
2. Multiple fallback IP lookup services: If one service goes down, it doesn't affect overall operation
3. Query before modifying: If the DNS record is already up to date (e.g., after a program restart), it won't update redundantly

Earlier we mentioned that DNS records have a TTL (Time To Live) field. This value directly affects the "propagation speed" of DDNS and deserves its own section.

TTL indicates how long a DNS record can be cached (in seconds).

DNS queries don't go directly to the authoritative server every time. To improve efficiency, there are multiple layers of caching:

Your PC                                        Authoritative DNS Server
   │                                          (Alibaba Cloud/Cloudflare)
   │── Query home.example.com ──→ Local DNS Cache     │
   │                               │                  │
   │                          Cached?                  │
   │                          ├── Yes → Return directly│
   │                          │   (Don't ask the       │
   │                          │    authoritative server)│
   │                          │                        │
   │                          └── No → Ask ISP's DNS   │
   │                                     │             │
   │                                Cached?            │
   │                                ├── Yes → Return   │
   │                                └── No ──→ Ask authoritative server
   │                                              │
   │                                         Return record
   │                                    (with TTL=600)
   │                                              │
   │    ←── Final result ─────────────────────────┘
   │         (Cache expires after 600 seconds)

Suppose your TTL is set to 600 seconds (10 minutes):

1. At 12:00, you updated the DNS record, changing the IP from 43.132.141.21 to 113.88.12.34
2. But at 11:55, someone had queried your domain, and the result was cached with a validity period until 12:05
3. During the period from 12:00 to 12:05, when this person visits your domain, they'll still get the old IP

So the smaller the TTL, the faster IP changes take effect. For DDNS scenarios, it's recommended to set the TTL to 60–600 seconds.

But smaller isn't always better — a TTL that's too small means every visit requires a fresh DNS query, which increases resolution latency. For DDNS, 60–300 seconds is a good balance.

The most classic scenario. You've set up a NAS (Synology, QNAP), a smart home hub (Home Assistant), security cameras, etc., at home, and you can access them anytime from outside through a DDNS domain.

Assign a DDNS domain to your home computer, and you can connect back via SSH or remote desktop even when you're away. Remembering home.example.com is much more convenient than remembering an IP, and it doesn't matter if the IP changes.

You've set up a private server for Minecraft, Terraria, or other games. Giving your friends a domain name is more convenient than giving them an IP, and they can still connect even if the IP changes.

Sometimes your server has a relatively stable internal IP (e.g., a development machine on a corporate network), and you want to access it via a domain name. Although the IP doesn't change often, DDNS can automate the management and save you the hassle of manual maintenance.

If you're a technical person, I recommend writing your own script — not only can you implement the functionality, but you'll also gain a deep understanding of the entire process. The core logic of the simplest DDNS script might only be a few dozen lines of code.

This is the most easily overlooked prerequisite.

Many ISPs now assign NAT internal IPs (also called "large internal network" or CGNAT) by default. A common characteristic is that the IP starts with 100.64.x.x. In this case, the IP your router gets is not a real public IP but an IP within the ISP's internal network — people outside simply cannot reach you through this IP.

How to check? Log into your router's management page and check the WAN port IP. If it's 10.x.x.x, 100.64.x.x–100.127.x.x, 172.16.x.x–172.31.x.x, or 192.168.x.x, then it's a private IP.

Solution: Call your ISP's customer service and request a public IP. It's usually free — just say "I need it for remote monitoring" or "I need a public IP." Some ISPs may require a plan upgrade.

You clearly updated the DNS record, but nslookup still shows the old IP? It's most likely a DNS caching issue.

DNS caches exist at multiple levels:

• Your computer has a local cache
• Your router may have a cache
• Your ISP's DNS server has a cache

Solutions:

1. Set the DNS record's TTL to a smaller value (60–300 seconds)
2. Clear the local DNS cache: on macOS use sudo dscacheutil -flushcache, on Windows use ipconfig /flushdns
3. Query using a specific DNS server to bypass local cache: nslookup home.example.com 8.8.8.8

AccessKeys and other credentials must be kept safe:

• ❌ Don't hardcode keys in your code and then push to GitHub (this is one of the most common security incidents)
• ✅ Use environment variables or a separate configuration file (added to .gitignore)
• ✅ Use RAM sub-accounts (Alibaba Cloud) or sub-users (Tencent Cloud), granting only the minimum permissions related to DNS. Even if the key is leaked, an attacker can only manipulate DNS and cannot touch your servers or other resources

Check the IP every second? Unnecessary, and you might get rate-limited by the API.

Generally speaking:

• Home broadband, IP changes occasionally: Checking every 5–10 minutes is sufficient
• Scenarios where IP rarely changes (e.g., fixed IP mapping): Every 1–6 hours is fine
• High real-time requirements: Every 1–3 minutes, but be mindful of API rate limits

API rate limits vary by provider. Alibaba Cloud DNS's free tier allows approximately 6 requests per second and 10,000 per day, which is more than enough for DDNS.

If you're using a Chinese domain name (e.g., 凉开水水水.top), note that some API interfaces require the original Chinese text, while others require Punycode encoding (e.g., xn--t8qz53azjkaa.top). The specifics depend on the provider's API implementation — it's recommended to consult the corresponding API documentation.

After configuring DDNS, you can use command-line tools to verify whether the domain resolves correctly:

Method 1: nslookup (concise output)

$ nslookup home.example.com
Server:    8.8.8.8
Address:   8.8.8.8#53

Non-authoritative answer:
Name:    home.example.com
Address: 43.132.141.21          ← This is the IP your domain currently points to

Method 2: dig (more detailed information)

$ dig home.example.com

;; ANSWER SECTION:
home.example.com.    600    IN    A    43.132.141.21
                      ↑                    ↑
                   TTL value          Resolved IP

dig displays more information such as TTL and authoritative servers, making it suitable for troubleshooting.

If the returned IP matches what you expect, it means DDNS is working properly 🎉

Back to the original question: What is DDNS?

It is an automation tool whose core logic can be condensed into four words: detect and update.

It's just such a simple loop that solves the big problem of "dynamic IPs being hard to remember and hard to use."

If you'd like to try it yourself, why not start by writing the simplest DDNS script? When you see ✅ DNS record updated successfully printed in your terminal, you'll think — this stuff really isn't that hard after all.