DNS Check
-
πΊπΈ Mountain View, CA, United StatesGoogle (anycast)β
-
πΊπΈ Mountain View, CA, United StatesGoogle #2 (anycast)β
-
πΊπΈ San Francisco, CA, United StatesCloudflare (anycast)β
-
πΊπΈ San Francisco, CA, United StatesCloudflare #2 (anycast)β
-
πΊπΈ San Francisco, CA, United StatesOpenDNS (Cisco) (anycast)β
-
πΊπΈ San Francisco, CA, United StatesOpenDNS #2 (anycast)β
-
πΊπΈ Reston, VA, United StatesVerisign (anycast)β
-
πΊπΈ Wilmington, DE, United StatesNextDNS (anycast)β
-
πΊπΈ Fremont, CA, United StatesHurricane Electricβ
-
πΊπΈ Broomfield, CO, United StatesLevel3 / CenturyLinkβ
-
πΊπΈ Clifton, NJ, United StatesComodo Secure DNS (anycast)β
-
πΊπΈ Reston, VA, United StatesNeustar UltraDNS (anycast)β
-
πΊπΈ New York, NY, United StatesCleanBrowsing (anycast)β
-
πΊπΈ Wilmington, DE, United StatesControlD (anycast)β
-
π¨π Zurich, SwitzerlandQuad9 (anycast)β
-
π¨π Zurich, SwitzerlandQuad9 unfiltered (anycast)β
-
π©πͺ Frankfurt, GermanyDNS.SB (anycast)β
-
π©πͺ Leipzig, GermanyUniversitaet Leipzigβ
-
π¦πΉ Innsbruck, Austrianemox.netβ
-
π³π± Amsterdam, NetherlandsOpenNIC EU root (anycast)β
-
π«π· Paris, FranceDNS0.eu (anycast)β
-
π¨πΎ Nicosia, CyprusAdGuard (anycast)β
-
π¨πΎ Nicosia, CyprusAdGuard #2 (anycast)β
-
π·πΊ Moscow, RussiaYandex (anycast)β
-
π·πΊ Moscow, RussiaYandex #2 (anycast)β
-
π·πΊ Moscow, RussiaYandex Family (anycast)β
-
π·πΊ Moscow, RussiaComss.one DNS (anycast)β
-
π¨π³ Hangzhou, ChinaAliDNS (anycast)β
-
π¨π³ Shenzhen, ChinaDNSPod (Tencent) (anycast)β
-
π¨π³ Beijing, China114DNSβ
-
π°π· Seoul, South KoreaKT (Korea Telecom)β
-
ππ° Hong Kong, Hong KongHKIX Public (anycast)β
-
π¦πΊ Research, VIC, AustraliaCloudflare (AU) (anycast)β
-
π¦πΊ Adelaide, AustraliaTelstra Internetβ
DNS Propagation Validation
Whether you have recently changed your DNS records, switched web host, or started a new website β checking whether the DNS records are propagated globally is essential. Enter a hostname above and click Search; we'll query 34 public DNS resolvers across multiple countries and update the map and list live as each replies.
DNS Propagation Map
Monitor this automatically
NetTests can run this check on a schedule, preserve historical results, compare changes over time, and alert you the moment something breaks.
Start monitoring free β See all monitoring productsFrequently Asked Questions
What is DNS propagation?
When you change a DNS record, resolvers around the world don't update instantly β each one serves its cached copy until the TTL expires, then re-queries the authoritative nameserver. Propagation is the time it takes for all resolvers globally to start returning the new value.
How long does DNS propagation take?
It depends on the record's TTL. A TTL of 3600 means resolvers may cache the old value for up to one hour. In practice most resolvers update within minutes after the TTL expires, and the majority of global traffic sees the new record within 1β24 hours. Pre-lowering your TTL to 300 seconds a day before a planned change dramatically speeds this up.
What does it mean when resolvers return different IPs?
Different IPs from different resolvers is normal for CDN and anycast setups β providers like Cloudflare, Akamai, and AWS Route 53 intentionally return different addresses based on the resolver's geographic location to route users to the nearest edge node. If you're NOT using a CDN and see different IPs, it may indicate incomplete propagation or a misconfiguration.
Why do some resolvers still return the old record?
Those resolvers cached the record before you made the change and their cached copy hasn't expired yet. Wait for the old TTL to pass β the resolver will re-query the authoritative nameserver and get the new value. You can also try flushing the public resolver's cache (Google and Cloudflare offer cache flush tools on their websites).
What is a split-horizon DNS setup?
Split-horizon (also called split-brain DNS) returns different records depending on where the query comes from β typically internal corporate resolvers get private IPs while public resolvers get public IPs. This lets internal users reach internal services while external users reach the public-facing endpoint.