DNS Check

  • πŸ‡ΊπŸ‡Έ Mountain View, CA, United States
    Google (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ Mountain View, CA, United States
    Google #2 (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ San Francisco, CA, United States
    Cloudflare (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ San Francisco, CA, United States
    Cloudflare #2 (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ San Francisco, CA, United States
    OpenDNS (Cisco) (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ San Francisco, CA, United States
    OpenDNS #2 (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ Reston, VA, United States
    Verisign (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ Wilmington, DE, United States
    NextDNS (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ Fremont, CA, United States
    Hurricane Electric
    β€”
  • πŸ‡ΊπŸ‡Έ Broomfield, CO, United States
    Level3 / CenturyLink
    β€”
  • πŸ‡ΊπŸ‡Έ Clifton, NJ, United States
    Comodo Secure DNS (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ Reston, VA, United States
    Neustar UltraDNS (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ New York, NY, United States
    CleanBrowsing (anycast)
    β€”
  • πŸ‡ΊπŸ‡Έ Wilmington, DE, United States
    ControlD (anycast)
    β€”
  • πŸ‡¨πŸ‡­ Zurich, Switzerland
    Quad9 (anycast)
    β€”
  • πŸ‡¨πŸ‡­ Zurich, Switzerland
    Quad9 unfiltered (anycast)
    β€”
  • πŸ‡©πŸ‡ͺ Frankfurt, Germany
    DNS.SB (anycast)
    β€”
  • πŸ‡©πŸ‡ͺ Leipzig, Germany
    Universitaet Leipzig
    β€”
  • πŸ‡¦πŸ‡Ή Innsbruck, Austria
    nemox.net
    β€”
  • πŸ‡³πŸ‡± Amsterdam, Netherlands
    OpenNIC EU root (anycast)
    β€”
  • πŸ‡«πŸ‡· Paris, France
    DNS0.eu (anycast)
    β€”
  • πŸ‡¨πŸ‡Ύ Nicosia, Cyprus
    AdGuard (anycast)
    β€”
  • πŸ‡¨πŸ‡Ύ Nicosia, Cyprus
    AdGuard #2 (anycast)
    β€”
  • πŸ‡·πŸ‡Ί Moscow, Russia
    Yandex (anycast)
    β€”
  • πŸ‡·πŸ‡Ί Moscow, Russia
    Yandex #2 (anycast)
    β€”
  • πŸ‡·πŸ‡Ί Moscow, Russia
    Yandex Family (anycast)
    β€”
  • πŸ‡·πŸ‡Ί Moscow, Russia
    Comss.one DNS (anycast)
    β€”
  • πŸ‡¨πŸ‡³ Hangzhou, China
    AliDNS (anycast)
    β€”
  • πŸ‡¨πŸ‡³ Shenzhen, China
    DNSPod (Tencent) (anycast)
    β€”
  • πŸ‡¨πŸ‡³ Beijing, China
    114DNS
    β€”
  • πŸ‡°πŸ‡· Seoul, South Korea
    KT (Korea Telecom)
    β€”
  • πŸ‡­πŸ‡° Hong Kong, Hong Kong
    HKIX Public (anycast)
    β€”
  • πŸ‡¦πŸ‡Ί Research, VIC, Australia
    Cloudflare (AU) (anycast)
    β€”
  • πŸ‡¦πŸ‡Ί Adelaide, Australia
    Telstra 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

Untested Resolved Not resolved

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 products

Frequently 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.