DNS Propagation Checker

DNS turns names into records, such as IP addresses, mail routing targets, and verification strings. It works through a distributed hierarchy of authoritative servers and recursive resolvers. When a user asks for a domain, their resolver may answer from cache or walk the hierarchy to find the authoritative answer.

Propagation is the informal name for the period during which different resolvers return different answers after a DNS change. The new record does not broadcast instantly across the internet. Instead, caches expire over time, and resolvers fetch fresh data when their stored answer is no longer valid.

Time to live, or TTL, tells resolvers how long they may cache a DNS response. A record with a 300-second TTL should usually refresh faster than one with a 24-hour TTL. Lower TTLs are useful before planned migrations because they reduce the window where old answers persist. Higher TTLs reduce query load and can improve resilience when authoritative servers are temporarily unreachable.

TTL is important, but it is not the whole story. Some resolvers clamp very low values, users may sit behind enterprise caches, and negative responses can also be cached. Browser, operating system, and application caches can add another layer of delay.

The authoritative nameserver is the source of truth for a zone. Recursive resolvers, such as ISP resolvers or public DNS services, answer user queries and cache results. After a change, checking only the authoritative server confirms the source data, but it does not show what users around the world currently receive. Checking recursive resolvers reveals the practical user-facing state.

This distinction helps during incidents. If authoritative data is wrong, the zone needs correction. If authoritative data is right but recursive answers differ, the issue is probably cache age, resolver behavior, delegation, DNSSEC, or local client caching. Different symptoms point to different fixes.

Reliable DNS changes are planned backward from cache behavior. Before a migration, teams often lower TTLs well in advance, verify authoritative records, make the change, monitor recursive answers, and keep the old destination available until stale caches fade. This is especially important for mail, CDN, load balancer, and domain verification records.

DNS is simple at the record level but complex in aggregate because many independent systems cache and forward answers. Patience and observability are part of the process. A clean change is not just a correct record; it is a transition that accounts for how resolvers and clients actually behave.