Databáze řešení

DNS changes don't take effect everywhere instantly — caching at multiple levels means "propagation" can appear inconsistent for hours. This guide covers diagnosing what's actually happening versus a genuine misconfiguration.

Understanding DNS Propagation

When you change a DNS record, it doesn't update globally at once. Each resolver caches records according to the record's TTL (Time To Live) — until that cache expires, some users will still see the old value.

Step 1 — Verify the Record Is Actually Correct at the Source

dig +short yourdomain.com @8.8.8.8

Querying Google's public DNS (8.8.8.8) directly bypasses your local resolver's cache, showing what's actually been published.

Step 2 — Check Multiple Record Types as Needed

dig A yourdomain.com
dig CNAME www.yourdomain.com
dig MX yourdomain.com
dig TXT yourdomain.com
dig NS yourdomain.com

Step 3 — Check from Multiple Global Locations

Use an online "DNS propagation checker" tool to see the record's status from various global resolvers simultaneously — this quickly reveals whether it's genuinely still propagating or if the record itself is wrong.

Step 4 — Check the TTL Value

dig yourdomain.com

The TTL (in seconds) in the response tells you the maximum time a resolver will cache that answer. A TTL of 3600 means up to 1 hour of caching; 86400 means up to 24 hours.

Step 5 — Clear Your Local DNS Cache

If your own machine seems stuck on an old value longer than the TTL should allow:

Windows:

ipconfig /flushdns

macOS:

sudo dscacheutil -flushcache

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Step 6 — Confirm You Edited the Correct DNS Zone

A very common mistake: editing DNS at the wrong provider (e.g. the registrar) when nameservers actually point to a different DNS host (e.g. a CDN or separate DNS management service).

dig NS yourdomain.com

This shows which nameservers are authoritative — confirm you're editing records at that exact provider.

Step 7 — Verify No Typos in the Record

Double-check the exact IP address, and that CNAME/A records don't accidentally include a trailing dot inconsistency or extra whitespace that some DNS panels are sensitive to.

Planning DNS Changes to Minimize Downtime

Before a planned migration, lower the TTL (e.g. to 300 seconds) a day in advance, make the change, confirm it's working, then raise the TTL back to normal once stable.

Common Errors

Record shows correctly via dig but browser still shows old site — almost always a local/browser DNS cache issue; flush it and try a private/incognito window.

NXDOMAIN (domain not found) — the domain may have expired, or nameservers aren't correctly configured at the registrar.

Best Practices

• Lower TTL before planned changes, raise it back afterward
• Always query 8.8.8.8 or another public resolver directly to bypass your own cache during troubleshooting
• Confirm which nameservers are authoritative before editing records anywhere

Related Articles

• How to Set Up Reverse DNS (PTR/rDNS) for Email Deliverability
• Website Down? A Step-by-Step Troubleshooting Checklist
• VPS Terminology: A Beginner's Glossary