Troubleshooting DNS Propagation: Record Types, TTL, and Caching

The most common confusion after changing DNS records is: it works for me, but others still see the old version. Or vice versa—others can access it, but you can’t.

These issues can usually be resolved within an hour using dig. The key is to compare results from multiple DNS servers rather than relying solely on local checks.

First, Verify Your Configuration

The “Host” field (@ / www) is the most frequently misconfigured:

• @ represents the root domain itself (example.com)
• www represents www.example.com
• If you only add www without adding @, the root domain will fail to resolve

# Verify both names separately
dig +short example.com A
dig +short www.example.com A

Compare Multiple DNS Servers Using dig

# Result from your local DNS
dig +short example.com A

# Compare against public DNS servers
dig @8.8.8.8         example.com +short   # Google
dig @114.114.114.114 example.com +short   # China Telecom/Unicom/Mobile default
dig @223.5.5.5       example.com +short   # Alibaba Cloud

# Check remaining TTL
dig example.com A | grep -A1 'ANSWER SECTION'

# Query authoritative DNS directly (bypassing all caches)
dig @AuthoritativeNSServer example.com A

# Trace the full resolution chain
dig +trace example.com A

Judgment criteria:

• Inconsistent results across multiple DNS servers → Still propagating, or some DNS servers are caching old records
• Authoritative DNS shows the new value, but public DNS still shows the old one → Normal propagation process; wait for TTL to expire
• Authoritative DNS itself still shows the old value → Your modification has not taken effect; go back and check your DNS management platform

The third point is critical: The authoritative DNS is the source of truth. If it hasn’t changed, the issue lies in your configuration settings; if it has changed, it’s just a matter of time.

What is TTL and How Long Do You Wait?

TTL (Time To Live) is the maximum duration that various DNS levels cache this record. It determines “how long you might have to wait globally after making changes before they take effect.”

# Check the currently effective TTL
dig example.com A | grep -A2 'ANSWER SECTION'
# The number in the second column is the remaining TTL (in seconds)

Key point: The TTL is determined by the record’s TTL BEFORE the change, not after.

Therefore, the correct approach is to lower the TTL in advance:

1. At least one day before the planned switch, change the TTL to 600 or 300 seconds
2. Wait for the old TTL to expire (at this point, the entire network caches short-TTL records)
3. Then make the actual record changes; propagation will be much faster

Lowering the TTL at the last minute is useless because the global network has already cached the old record with its long TTL.

Local Cache Illusions

# Clear local DNS cache and retest
ipconfig /flushdns                   # Windows
sudo systemd-resolve --flush-caches  # Linux
sudo dscacheutil -flushcache         # macOS

# Bypass system cache for direct queries (more reliable)
dig @8.8.8.8 example.com +short

Another common scenario: You modified the hosts file and forgot about it. The hosts file takes precedence over DNS, causing you to see results completely different from reality.

# Check hosts file
cat /etc/hosts                                    # Linux/macOS
type C:WindowsSystem32driversetchosts        # Windows

An Often Overlooked Point: NS Records

If you switch DNS providers (e.g., from registrar DNS to cloud DNS), you need to update the NS records at your domain registrar, not just add resolution records on one side.

# See who the current effective NS servers are
dig example.com NS +short

If the NS records still point to the old DNS provider, records added on the new platform will never take effect. This pitfall is characterized by: the new platform shows “configuration normal,” but resolution simply doesn’t work.

Decision Tree

Resolution Not Taking Effect
├─ Value found via Authoritative DNS
│  ├─ Still old        → Modification didn't take effect; check DNS platform
│  └─ Already new      → Just propagating; wait for TTL
├─ Are results from multiple public DNS consistent?
│  ├─ Inconsistent     → Propagating; normal
│  └─ Consistent and new → Issue is elsewhere; check service/ports
├─ Local result differs from others
│  ├─ Local DNS cache  → flushdns
│  └─ Hosts file       → Check and clean up
├─ Added records on new platform but still invalid
│  └─ Does NS point to new platform? → Update NS at registrar
└─ Root domain works, www doesn't (or vice versa)
   └─ Only one host record added → Add missing @ or www

Scenario Walkthrough: Changed Resolution, Half Can Access, Half Cannot

Symptom: Domain record modifications are complete and confirmed saved,
but access results vary by region and network—some can open the site, others still see the old site.

1. First, determine if the change actually took effect → Query the authoritative server specified for the domain directly.
   If it returns the new value, this step separates “was it changed?” from “has it propagated?”, which is the watershed moment of troubleshooting.
2. Then compare return values from public resolution nodes → Some nodes return old values, others return new ones,
   indicating the process is still gradually taking effect.
3. Confirm the cache duration setting of the old record → Previous cache times were long,
   so regional nodes will continue using old values until they naturally expire.
4. Exclude interference from local machine cache → The local OS also caches resolution results,
   leading to false judgments that “it hasn’t taken effect yet.”
5. Wait for the longest cache to expire → There is no forced refresh method; you must wait according to the set time.
6. Verify across different networks → Query multiple public resolution nodes individually to observe convergence.

# ① Query authoritative server: Confirm if changes reached the source
dig example.com NS +short
dig example.com A @ObtainedAuthoritativeServer +noall +answer

# ② Compare different public resolution nodes
for d in 223.5.5.5 119.29.29.29 8.8.8.8; do
  echo "--- $d"; dig example.com A @$d +short
done

# ③ Check how much old cache time remains
dig example.com A +noall +answer | awk '{print "Remaining TTL:", $2, "seconds"}'

# ④ Clear local cache before testing to avoid misleading results
ipconfig /flushdns            # Windows
systemd-resolve --flush-caches   # Linux

Root Cause: The change has taken effect, but resolution nodes in various regions still hold cached old records.
The original cache duration was set very long, so convergence requires waiting for a full cycle.

Two points worth remembering:

• To judge “was it changed?” and “has it propagated?”, you must use different query methods.
  Query the authoritative server to verify the former, and query public nodes to verify the latter; mixing them leads to wrong conclusions.
• Before planning resolution changes, lower the cache duration first and wait for it to take effect.
  This temporary measure effectively shortens convergence time; if not handled in advance, you can only wait for the original duration to expire naturally.

Common Record Type Reference

The most important takeaway from the table is the CNAME entry: On the same host record, CNAME cannot coexist with other record types.
When the root domain needs to resolve to a website AND configure MX, using CNAME causes direct conflicts.
This explains the best practice: “Use A records for the root domain, and CNAME only for subdomains.”

# Query authoritative response (looks at values on authoritative servers, best indicator of correctness)
dig example.com A @ns1.dnsprovider.com +noall +answer
dig example.com NS +short

# Compare if public DNS has synchronized
for d in 223.5.5.5 119.29.29.29 8.8.8.8; do
  echo "--- $d"; dig example.com A @$d +noall +answer
done

# Check remaining TTL (to judge how long to wait)
dig example.com A +noall +answer | awk '{print "TTL:", $2}'

Using @ to specify DNS servers for individual comparison is the watershed between judging “is it correct?” and “has it propagated”:
If the authoritative server has the new value but public DNS still has the old one, it means the change is correct and just needs time;
if the authoritative server itself has the old value, waiting longer won’t help.

8 Common Pitfalls

1. Only checking local resolution results: Affected by cache; must compare authoritative and public DNS.
2. Adding www but forgetting @: Root domain becomes inaccessible.
3. CNAME coexisting with other records: Causes conflicts and resolution anomalies.
4. Not lowering TTL in advance: Propagation takes a long time after switching.
5. Lowering TTL after the fact: Completely useless.
6. Switching DNS providers without updating NS: Records added on the new platform won’t take effect.
7. Forgetting about the hosts file: Results seen are completely different from reality.
8. Decommissioning the old environment before propagation completes: Users still on the old site lose access entirely.

Real Customer Feedback (From Similar Cloud Market Product Reviews and Consultations)

The following excerpts are from real buyer reviews and consultations for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (service providers include our store and competitors, provided here for reference only, not fictional tickets from this site):

10***77 2022-09-19 5.0 Affordable price | Skilled technology | Patient and professional Received filing rectification notice, found this service exactly when needed, handled quickly 10***49 2022-04-12 5.0 On-time delivery | Affordable price | Skilled technology Needed rectification, fast configuration, good

b****4 Rating: 5.0 points 2025-06-23 16:57 b****4 Rating: 5.0 points 2025-06-23 16:56 Jian****Wei Rating: 5.0 points 2021-01-20 15:03 Technology is awesome! Speed is very fast! Originally caused by trojan causing Baidu global hijacking!!!! 1 f****u Rating: 5.0 points 2021-01-02 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 points 2020-11-20 10:03 As always, great service 1****1 Rating: 5.0 points 2020-11-17 09:13 Thanks for the consistently great service. 1****1 Rating: 5.0 points 2020-09-25 15:42 Many thanks. 1****1 Rating: 5.0 points 2020-08-24 15:34 Many thanks to your company’s technical staff 1****1 Rating: 5.0 points 2020-07-24 09:49 Many thanks! 1