DNS Checker & Propagation Tool

How DNS Resolution Actually Works

Every time a user types a domain into their browser, an invisible chain of queries fires across the internet. The browser first checks its own cache, then the operating system's stub resolver, then the configured recursive resolver (often your ISP or a public resolver like 1.1.1.1). If none of those have a fresh answer, the recursive resolver walks the DNS hierarchy: root servers → TLD servers → authoritative nameservers. Each step adds latency, which is why caching and TTL values matter so much for performance.

The resolver's cache honours the TTL (Time to Live) value attached to every DNS record. A TTL of 3600 means the resolver will serve the cached answer for one hour before asking the authoritative server again. Lower TTLs give you faster propagation when you make changes, but increase query load on your nameservers. Most production domains settle on TTLs between 300 and 3600 seconds — short enough for operational agility, long enough to absorb traffic spikes.

Why DNS Propagation Takes Time

When people say "DNS propagation," they usually mean the window during which old and new records coexist across the global resolver network. Propagation is not a push mechanism — there is no central broadcast that tells every resolver to update. Instead, each resolver independently expires its cached copy based on the TTL that was in effect when it last fetched the record. If your old TTL was 86400 (24 hours), some resolvers may serve stale data for a full day even after you publish new records.

A practical strategy is to lower the TTL 24–48 hours before a migration. Drop it to 60–300 seconds, wait for the old TTL to expire everywhere, then make the actual record change. Once the change is confirmed, raise the TTL back to a production-friendly value. This two-step approach is standard practice for zero-downtime domain migrations, CDN cutovers, and email provider switches.

Common DNS Misconfigurations and How to Spot Them

Misconfigured DNS is one of the most common — and most invisible — causes of website and email outages. Here are the issues our tool helps you catch:

• Missing MX records: Without valid MX records, email sent to your domain bounces. Verify that at least one MX record points to a reachable mail server, and that the priority values are ordered correctly.
• Orphaned CNAME records: A CNAME that points to a hostname that no longer exists creates a dangling reference. Browsers will fail to resolve the domain entirely, producing a generic "site can't be reached" error.
• Conflicting records at the apex: RFC 1034 prohibits placing a CNAME at the zone apex alongside other record types. If your registrar allows it, you may end up with resolver-dependent behaviour — working in some locations and failing in others.
• Stale NS delegations: If you changed hosting providers but left old NS records at the registrar, queries may still route to servers that no longer serve your zone, causing intermittent resolution failures.
• Missing or incorrect SPF/DKIM TXT records: Email deliverability depends on correctly formatted TXT records. A missing SPF record means receiving servers can't verify your domain, increasing the chance your messages land in spam.

DNS Security: DNSSEC, DoH, and DoT

Traditional DNS queries travel in plaintext over UDP port 53, making them vulnerable to eavesdropping and spoofing. Three technologies address different aspects of this problem:

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses. A validating resolver can verify that the answer came from the legitimate authoritative server and wasn't tampered with in transit. DNSSEC doesn't encrypt the query — it authenticates the response. Deployment requires signing your zone and publishing DS records at the parent zone (your registrar).

DNS over HTTPS (DoH) wraps DNS queries inside standard HTTPS connections to port 443. This encrypts the query content from network observers and makes DNS traffic indistinguishable from regular web traffic. Major browsers now support DoH natively, and public resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8) accept DoH queries.

DNS over TLS (DoT) encrypts DNS queries using TLS on a dedicated port (853). Unlike DoH, DoT traffic is identifiable by port number, which allows network administrators to apply DNS-specific policies while still protecting query privacy. DoT is more commonly used in enterprise and mobile OS configurations.