Tencent Cloud DNSPod Setup: From Adding a Domain to Verifying Resolution

Tencent Cloud DNSPod Setup: From Adding a Domain to Verifying Resolution

Most DNS incidents are not caused by a record entered incorrectly. A wrong record fails immediately, which makes it the easiest kind of problem to fix. What actually consumes a working day is three other things: which nameservers the domain is delegated to, what TTL was configured, and what evidence you have that a change has really propagated. None of the three has a clear answer inside a console, and all three decide whether the rest of the work means anything.

DNSPod is a useful sample for this flow. Founded in Shenzhen in 2006 and fully acquired by Tencent Cloud in 2015, it offers intelligent routing that splits answers by carrier and by province, with average domestic query response below 20 milliseconds and changes usually taking effect within seconds. None of that is hard to use. The hard part is handing the domain over correctly and knowing when to trust your own verification.

What follows reorders the steps into the sequence real troubleshooting uses: confirm the current delegation, choose how to connect, and only then pick record types, set TTL, and verify. Console paths and interface copy follow current DNSPod documentation, and protocol behaviour follows the DNS standards; details differ between releases.

1. The First Step Is Delegation, Not a New Record

1.1 Reading whois and dig NS

The only authoritative answer to who resolves a domain is its NS records. The set configured at the registrar is the delegation: it tells every recursive resolver on the internet which servers hold authoritative data for the zone. There are two ways to look, and they ask different systems.

dig NS example.com +short          # walk the authoritative chain for NS records
whois example.com | grep -i "name server"   # read the NS registered at the registrar

The two should agree. When they do not, apply one rule: trust the NS that DNS actually returns, and treat whois as reference only. Registrar data is cached and synchronised with delay, so a panel change may not appear in whois yet. In the opposite case, where the registrar panel shows the new value but dig NS still returns the old set, the registry-level delegation has simply not refreshed; wait rather than changing it again.

Without +short, dig NS returns a full response. The records in the ANSWER SECTION are the delegation currently in force, while those in the AUTHORITY SECTION are the referral from the parent zone. Keeping the two apart matters, because reading only the AUTHORITY SECTION makes it look as though a domain is already hosted somewhere when nothing has changed.

1.2 Before NS changes, no new record takes effect

This is the spot where DNSPod beginners stall most often. Adding a record in the DNSPod console writes data into DNSPod's own authoritative zone. If the domain's NS still point at the registrar default or another DNS provider, no recursive resolver anywhere will ask DNSPod. The console reports success, dig returns something else entirely, and the two sides tell different stories.

The test is direct. Run dig NS yourdomain.com +short first. If it does not return the nameserver set DNSPod assigned to you, then however many records you add in the console will have no external effect. The next action is not another record; it is finishing the NS change at the registrar or switching to subdomain delegation.

Conversely, the "record active" message in the console means only that the record was written to the authoritative zone. It makes no promise that resolvers worldwide can see it. Confusing the two is the origin of most tickets that read "configured but not working".

2. Two Ways to Connect: Full Hosting or Subdomain Delegation

2.1 Full hosting: point NS at DNSPod

Full hosting means changing the domain's NS to the servers DNSPod assigns, after which every record for that domain is answered by DNSPod. This is the common path, and it is the precondition for intelligent routing to apply to the whole site.

The correct order is migrate data first, change NS second. Copy every record in use at the previous provider, namely A, AAAA, CNAME, MX, TXT, NS and SRV, into DNSPod, check each host name and value, and only then change NS at the registrar. Doing it the other way around creates a resolution vacuum: NS already point at DNSPod while DNSPod is still empty, every lookup in that window returns NXDOMAIN, and the website, mail, and verification records all break together.

There is one more prerequisite that gets skipped. If the previous provider enabled DNSSEC, remove the DS record there before switching, and rebuild the chain of trust on the DNSPod side once the new delegation is stable. Skip this and some public resolvers return SERVFAIL for every query while everything looks fine elsewhere, which is a particularly misleading failure mode.

2.2 Subdomain delegation: hand over only one branch

The second option delegates a single subdomain to DNSPod. You add NS records for that subdomain at the parent DNS, hand over resolution for that branch, and leave the apex and the other subdomains with the original provider.

Two situations fit. One is wanting intelligent routing for one business subdomain while everything else stays untouched, which minimises the blast radius. The other is organisational: separate teams manage their own subdomains in their own DNS, without touching each other.

The boundary is worth stating plainly. You can delegate a subdomain, not an individual host record. The whole example.com branch can be handed over; the single name www.example.com cannot, because it is not a separate delegation point. The apex itself cannot be split this way either.

2.3 How the risk differs

Full hosting concentrates risk. One NS change affects every record of the domain, a mistyped MX means no mail at all, and a lost TXT record kills SPF and domain verification together. The benefit is equally concentrated: one panel, one TTL policy, intelligent routing applying site-wide.

Subdomain delegation isolates risk. A mistake only affects the branch that was handed over, leaving the main site and mail untouched. The price is fragmentation: two panels, two TTL policies, and a troubleshooting step that first asks which branch the fault belongs to.

The decision compresses into one sentence. If the domain's records already live in one place and you intend to manage them centrally, use full hosting. If you only need to fix path quality for one subdomain, or the organisation genuinely separates ownership, use subdomain delegation. Never change the delegation of an entire domain to solve a single subdomain's problem; that escalates a local need into a global risk.

3. Using Record Types Correctly

3.1 A, AAAA, and CNAME

An A record maps a host name to an IPv4 address and an AAAA record maps it to an IPv6 address. Both can exist at once, and clients pick according to their own network capability. When the origin address is stable and under your control, a hard-coded A record is reasonable.

A CNAME maps a host name to another domain name, and resolvers follow the chain. It fits services whose addresses change: the accelerated domain a CDN assigns, the access domain of object storage, the site domain of a hosting platform. Hard-coding those as A records is a common mistake, because the provider changes addresses without notice and your site suddenly fails in some regions.

An apex domain usually cannot be a CNAME. This is not a vendor limitation but a protocol constraint: the apex necessarily carries SOA and NS records, and CNAME may not coexist with any other record type. To put an apex behind a CDN, the usual approaches are the fixed addresses the vendor publishes, used as A records, or a resolution service that supports apex flattening.

3.2 MX, TXT, and NS

MX records carry a priority, and a lower number wins. Multiple MX records point at multiple receiving servers: mail is delivered to the highest-priority host first and retried down the list on failure. Changing MX hands receiving authority to another provider and is effectively irreversible. After the switch the old mailbox usually keeps receiving for a while, so both mailboxes must be watched, and missing one loses mail. Account and archive handling during a business mailbox migration follows the provider's own migration documentation.

TXT records serve domain ownership verification, SPF, DMARC, and similar purposes, and several TXT records may coexist at the same host name. This is widely misunderstood: many people assume one host name can hold only one TXT record, when in practice verification, SPF, and DMARC can live side by side. What does need attention is total length and format, since long strings must be split according to the specification.

NS records exist for delegation and are used only when handing a branch to different nameservers. Adding an NS record for a subdomain inside DNSPod hands over resolution for that branch, which is the same operation described above as subdomain delegation, reached through a different screen.

3.3 SRV records and the CNAME constraint

SRV records carry priority, weight, port, and target, putting service discovery into DNS. They appear in SIP, XMPP, and some self-hosted game and collaboration deployments: a client only needs the domain name and can read from DNS which host and port to use.

One hard constraint deserves repeating: a CNAME may not coexist with any other record at the same host name. If MX, NS, TXT, or A and AAAA records already exist there, adding a CNAME is either rejected or produces unpredictable answers. The constraint bites hardest when adding a CNAME for www pointing at a CDN: if a verification TXT record was previously placed on www, the two conflict. There are only two fixes, moving that TXT to the apex or abandoning CNAME for an A record.

That is also why verification TXT records belong at the apex while business subdomains stay free for A and CNAME. Deciding in advance which host name carries which record type eliminates a large amount of later conflict chasing.

4. Choosing a TTL and the Two-Step Routine

4.1 The real cost of a short or long TTL

TTL means how long an answer may be cached, not how long until a change takes effect. The two ideas are routinely conflated, and the cost of conflating them is concrete.

A short TTL propagates changes quickly but raises the rate at which recursive resolvers come back to ask. Query volume against the authoritative servers grows with traffic, latency variance becomes more visible, and during an attack or a traffic peak the authoritative side becomes the bottleneck sooner. A long TTL keeps queries low and answers stable, but every change then waits for old caches to expire, turning an urgent fix into an hour-long wait.

Setting a very short TTL "to be safe" therefore works backwards. The flexibility it buys is smaller than the query pressure it creates. A sound approach layers by record type: long TTL for stable infrastructure records, shorter TTL for records likely to change.

4.2 The two-step routine before a major change

This is standard operations knowledge, yet tutorials often omit it. To change the value of a record with a long TTL, editing it directly is wrong: resolvers that already cached the old TTL keep returning the old value until that cache expires. You believe the change is live when it is actually waiting out an entire old TTL.

The correct sequence has three steps. First, one full old-TTL period in advance, lower the TTL to the order of minutes and wait for existing caches to expire. Second, change the record value. Third, once traffic and error rates are stable, raise the TTL back to its previous length.

"One full period in advance" is the operative phrase. A one-day TTL means waiting a full day so that caches everywhere cycle once. Change the value after only a few hours and resolvers that have not expired still answer with the old address, so the switch completes in batches and presents as "live in some regions, not in others". That half-live state is the hardest to troubleshoot, because repeated lookups give different answers.

4.3 Where wildcards and TTL interact badly

A wildcard uses * as the host label and matches every host name not explicitly defined. It is useful when handing out random subdomains to users, but combined with a short TTL it magnifies risk: any mistyped subdomain resolves to a live address, configuration errors and junk traffic get swallowed silently, and logs show nothing unusual.

Wildcards also collide with verification flows. Some domain verification depends on the host name not existing, and a wildcard A record makes it exist, so verification fails while the error message never hints that a wildcard is the cause.

A workable practice confines the wildcard to a specific subdomain, such as *.user.example.com, instead of placing it at the apex, and gives it a longer TTL so that probing costs less to answer.

5. How to Verify That a Change Took Effect

5.1 Query several public resolvers explicitly

Verification starts by leaving the local environment and asking several different public resolvers. When one domain gives different answers across resolvers, the caches themselves are telling you they have not converged.

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @223.5.5.5 example.com A +short
dig @8.8.8.8 www.example.com CNAME +short   # confirm where the CNAME chain points

Why the explicit resolver matters: without @, dig uses the system resolver, which may hit a local or carrier cache, so the answer describes one path only. Naming resolvers from different providers is the closest thing to sampling from several locations.

Three criteria settle it: the A answers agree across public resolvers, the CNAME chain is complete and terminates where intended, and the TTL in the response counts down rather than staying frozen, since a frozen value usually means every query hit the same cache.

5.2 Local caches and carrier caches

Local caching is the most overlooked layer. Operating systems, browsers, and even some SDKs keep their own DNS caches, so a query from the same machine may still return the old value right after a change. Flushing first saves a lot of self-doubt.

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS
sudo systemd-resolve --flush-caches                             # Linux systemd
ipconfig /flushdns                                              # Windows

Carrier recursive caches cannot be flushed at all; you can only wait for the TTL to expire. That is exactly why lowering the TTL ahead of a change matters: the one thing you control is letting caches expire sooner, not clearing someone else's cache.

5.3 Why "it opens on my machine" is not verification

One person opening the site successfully means only that the resolution path that person hit is working. DNS has caches, split routing, and multiple recursive levels, so a single success cannot rule out other regions still receiving the old address.

Real verification checks four things: whether several public resolvers agree, whether authoritative query volume matches expectations, whether the CNAME chain ends at the right service, and whether latency from the target region is normal. If the record points at a CDN, also confirm the accelerated domain resolves, the certificate chain is complete, and the origin is reachable; the order for those layers is in CDN HTTPS configuration basics.

One class of verification is skipped even more often: mail. After changing MX, the test is not sending one message. Check that the MX records are complete and priorities correct, then send from an external mailbox and inspect both inboxes. Correctness at the DNS layer and success at the session layer are two different things.

6. Five Common Mistakes and How to Locate Them

6.1 The five-item list

• Adding records before NS changes. The console reports success and nothing changes externally. This is the most frequent case, and its root cause is mistaking a write to the authoritative zone for global propagation.
• Configuring only one of apex and www. Configure only www and the bare domain fails; configure only the apex and every link with www fails. Users see one site, while DNS sees two independent objects.
• CNAME conflicting with MX or NS. Putting a CNAME on a host name that already carries another type either breaks resolution or is refused on save. It shows up most around apex-and-CDN setups and around verification TXT records on www.
• An extremely short TTL inflating query volume. Compressing the TTL "so changes apply instantly" multiplies authoritative queries with traffic and makes the service fail earlier under a peak or an attack.
• A wildcard silently covering subdomains. One * makes every misspelled name exist, hides the real configuration gap, and breaks verification flows that depend on NXDOMAIN.

6.2 What to check for each

Use the table top to bottom rather than jumping by intuition to the last row. Order matters: if delegation is wrong, every later check is meaningless.

7. A Pre-Launch Checklist

7.1 One pass before, one pass after

Before the switch:

• dig NS has confirmed the current delegation, and the result is recorded as the rollback reference
• Every record at the previous provider has been migrated, with host names and values checked one by one
• MX record count and priorities match the old configuration, and TXT records for SPF and verification are all present
• If the previous provider used DNSSEC, the order for removing and rebuilding DS records has been decided
• The change window avoids mail peaks and business peaks, and a rollback path is defined

After the switch:

• dig NS returns the DNSPod nameservers, and several public resolvers agree
• Both the apex and www have been verified, and the CNAME chain terminates correctly
• Mail has been verified in both directions, not just outbound
• Record TTLs match expectations and were not silently extended by a default
• If pointing at a CDN, accelerated domain resolution, certificate chain, and origin reachability are all verified

7.2 What to watch during the observation window

Do not close the ticket immediately after the switch. Four things belong in the observation window: the authoritative query volume curve, to confirm it matches expectations and shows no unusual spikes; the NXDOMAIN ratio, since an elevated ratio usually means a missing host record; the mail queue and bounces, where MX problems surface first; and certificate issuance status, because a failure that depends on TXT verification only appears days later.

Come back four to six hours later, and again the next day. DNS problems are strongly delayed: everything looks fine on the day, then a cache elsewhere expires and reveals the missing record. Writing the recheck into the process is far cheaper than repairing afterwards.

Scenarios that need resolution strategy planned in advance, such as multi-carrier splitting, cross-region scheduling, and CDN with origin coexistence, carry more variables; the framework is in the DNS smart routing guide. If a CDN follows this step, the connection order and its interaction with cache policy are covered in the Tencent Cloud CDN guide, and naming and suffix choices are in the domain naming basics guide. For sites aimed at mainland users where filing is part of the path, the order of resolution and filing is explained in hosting without ICP filing.

To compare a different hosting model after moving DNS elsewhere, see the Cloudflare setup guide. Cache-side symptoms where content was edited but users still see the old version are a separate chain from DNS verification, and the troubleshooting order is in CDN cache not updating troubleshooting. The broader entrance-layer trade-off is in Cloudflare versus CloudFront.

Source: 16IDC original. Product capabilities, configuration options, and pricing follow the official Cloudflare, AWS, and Tencent Cloud documentation and public pricing pages; console paths and interface copy change between releases.