How DNS Propagation Works
Short answerDNS propagation is the wait while recursive resolvers refresh cached answers after you change a record. Speed depends on TTL, nameserver delegation, and each resolver's cache — updates are instant at authoritative DNS but not worldwide.
Overview
This guide covers the steps and checks you need on an unmanaged VPSGrid VPS. Guest OS configuration remains your responsibility unless a separate managed product is documented on your account.
What Is DNS Propagation?
When you add or change a DNS record (A, AAAA, CNAME, MX, TXT), the update is saved on the authoritative nameserver for your domain. Propagation is the process of that new answer spreading to recursive resolvers (ISP DNS, Google Public DNS, Cloudflare, etc.) and local device caches.
Propagation is not instant. Resolvers cache previous answers until the record's TTL (Time To Live) expires. VPSGrid does not guarantee a fixed propagation window — timelines depend on TTL, resolver behavior, and whether nameservers were changed.
TTL Explained
TTL is measured in seconds on each DNS record. A TTL of 3600 means resolvers may cache the old value for up to one hour. Lower TTL (e.g. 300 = 5 minutes) speeds up updates but increases DNS query volume.
- Before migration: Lower TTL 24–48 hours ahead if your provider allows it
- After change: Wait at least one full TTL cycle before assuming failure
- Authoritative vs cached: Your zone editor shows the new value immediately; the world may still see the old value until caches expire
Confirm Records in VPSGrid First
Log in at billing.vpsgrid.net → Domains → My Domains → Manage → DNS Zone Editor. Verify the A record for @ and www points to your VPS primary IP from Services → My Services.
Confirm authoritative records in the zone editor before testing propagation externally.
Check A Records with dig (Linux, macOS, WSL)
dig queries DNS directly and shows the TTL returned by the resolver you query.
dig example.com A +short
dig www.example.com A +short
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +shortReplace example.com with your domain and compare the answer to your VPS primary IP. Querying @8.8.8.8 (Google) and @1.1.1.1 (Cloudflare) tests major public resolvers independent of your ISP.
dig example.com A
;; ANSWER SECTION:
example.com. 300 IN A 203.0.113.10The number before IN A is the remaining TTL in seconds. When it counts down to zero, the resolver fetches a fresh answer from authoritative DNS.
Check with nslookup (Windows and cross-platform)
Windows PowerShell and Command Prompt include nslookup:
nslookup example.com
nslookup example.com 8.8.8.8
nslookup -type=MX example.comThe second form forces Google DNS. If nslookup returns the correct IP but your browser still fails, the issue may be local cache or web server configuration — not DNS propagation.
MX, TXT, and CNAME Checks
Website A records are only one part of DNS. Mail and verification records propagate on the same TTL rules:
dig example.com MX +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig www.example.com CNAME +shortMX changes affect mail delivery separately from web A records. TXT records are used for SPF, DKIM, domain verification, and ACME challenges.
dig +trace — Full Resolution Path
dig +trace walks from root nameservers to your domain's authoritative servers. Use it when propagation seems stuck to confirm which nameserver is authoritative:
dig +trace example.com AThe final lines should show your authoritative provider (VPSGrid zone, Cloudflare, registrar DNS, etc.) returning the A record you configured. If trace shows a different nameserver than expected, nameserver delegation may still be updating — see Domain Transfer & Renewal Guide at VPSGrid.
Reverse Lookup (PTR) for Mail
Outbound mail reputation often requires PTR alignment. Check reverse DNS for your VPS IP:
dig -x 203.0.113.10 +shortReplace with your VPS primary IP. PTR is managed at the IP provider level — not in your domain zone editor.
Typical Propagation Timelines
| Change type | Typical range | Notes |
|---|---|---|
| A / AAAA record edit | 5 min – 4 hours | Depends on prior TTL |
| Nameserver delegation | 4 – 48 hours | Registrar + registry sync |
| MX / TXT update | 15 min – 24 hours | Mail may lag web |
| Global consistency | Up to 48 hours | Some resolvers ignore low TTL |
These are operational guidelines, not guarantees. Always verify with multiple resolvers rather than a single local check.
Local DNS Cache vs Authoritative Delay
Your laptop or office router may cache DNS longer than public resolvers. Flush local cache after confirming authoritative DNS is correct:
- Windows:
ipconfig /flushdns - macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux (systemd):
sudo resolvectl flush-caches
If public resolvers (dig @8.8.8.8) show the correct IP but your PC does not, flush local cache. If authoritative and public resolvers disagree, wait for TTL expiry or recheck the zone editor.
Troubleshooting Partial Propagation
- Wrong IP at authoritative DNS — fix in zone editor; propagation cannot fix a typo
- Nameserver mismatch — registrar NS must point to the DNS panel you edited
- Stale high TTL — previous TTL of 86400 (24h) means old values persist globally
- Split DNS — corporate VPN or Pi-hole may override public answers
- Site still down after DNS correct — web server, firewall, or SSL — see VPS Not Accessible — Troubleshooting Guide
Verify Propagation Step by Step
- Confirm the correct A record in your authoritative DNS panel (VPSGrid zone editor or registrar)
- Query Google DNS:
dig @8.8.8.8 example.com A +short - Query Cloudflare DNS:
dig @1.1.1.1 example.com A +short - Compare both answers to your VPS primary IP from My Services
- If answers differ between resolvers, wait one TTL cycle and re-test
- Flush local DNS cache on your workstation if public resolvers are correct
- Test HTTPS/HTTP only after DNS returns the expected IP globally
Document each dig output when opening a support ticket — timestamps help support distinguish propagation delay from configuration errors.
Check ALL Record Types
Propagation applies to every record in your zone, not only A records:
dig example.com ANY +noall +answer
dig example.com AAAA +short
dig example.com NS +shortAAAA records matter if you serve IPv6. NS records confirm which nameserver set is authoritative — a mismatch here blocks all other record updates from taking effect.
When to Wait vs When to Fix
Wait if authoritative DNS and at least one major public resolver show the new IP but your local machine does not — likely TTL/cache. Fix immediately if authoritative DNS itself shows the wrong IP, nameservers point to the wrong provider, or dig +trace returns NXDOMAIN.
For domains registered at VPSGrid, nameserver and zone management live in the client area. External registrars require NS updates at the registrar before VPSGrid zone edits become authoritative. See Domain Transfer & Renewal Guide at VPSGrid for delegation workflows.
Propagation and Email (MX/TXT)
Website visitors use A records; mail servers use MX and TXT (SPF, DKIM, DMARC). These record types propagate independently. You may see correct website DNS while mail still routes to an old host — always verify MX separately:
dig example.com MX +short
dig example.com TXT +short | head -5After changing MX for Google Workspace, Microsoft 365, or self-hosted mail on your VPS, allow the same TTL-based propagation window before sending production mail.
Online Propagation Checkers
Third-party tools query multiple global locations simultaneously. Use them as supplementary checks — always confirm with dig against known resolvers. Results may vary and do not replace authoritative verification in your DNS panel.
Frequently Asked Questions
How long does DNS propagation take for a VPSGrid VPS?
A record changes often propagate within minutes to a few hours depending on TTL. Nameserver changes can take up to 48 hours. VPSGrid does not guarantee a fixed propagation time.
Why does dig show the correct IP but my website still fails?
DNS may be correct while the web server, firewall, or SSL certificate is misconfigured inside the VPS. Verify Nginx/Apache listens on ports 80/443 and review the VPS Not Accessible troubleshooting guide.
Should I query 8.8.8.8 or my ISP DNS?
Query both. Public resolvers (8.8.8.8, 1.1.1.1) show global cache state; ISP DNS reflects what local users often see. Discrepancies usually mean TTL has not expired everywhere.
Does reinstalling my VPS affect DNS propagation?
Reinstalling the OS does not change your primary IP unless you order a new service. DNS records pointing to the same IP remain valid — no re-propagation needed unless you changed the IP or records.
What is the difference between propagation and pointing a domain?
Pointing sets the DNS records or nameservers. Propagation is the waiting period for resolvers worldwide to pick up those changes. See How to Point a Domain to a VPS for setup steps.
Related Articles
Need More Help?
If authoritative DNS shows the correct VPS IP but resolution fails globally after 48 hours, open a ticket at billing.vpsgrid.net with your domain name, VPS service ID, primary IP, dig +trace output, and screenshots from the DNS zone editor.
VPSGrid provides unmanaged KVM VPS hosting — you configure DNS records and web servers inside your VPS. See What Unmanaged VPS Hosting Means.
Was this answer helpful?
