$ traceroute dns-record-lookup 3 hops · 100% reply
1 ~/home (localhost) 0.1 ms
2 network-ops (10.0.0.1) 0.4 ms
3 dns-record-lookup (127.0.0.13) 0.2 ms

DNS Record Lookup

Query A, AAAA, CNAME, MX, TXT, NS and SOA records for any domain.

local DNS · IP · CIDR 0 bytes uploaded
dns-record-lookup.console TTY · 80×24
◇ man dns-record-lookup

"I Updated My DNS But the Change Isn't Working" — What's Actually Happening

This is the most common DNS support ticket. You updated an A record in your DNS registrar's dashboard, waited the recommended "propagation time," and your site still resolves to the old IP on your laptop — but your colleague's phone sees the new IP. The frustration is real, and the cause is specific: DNS caching operating at multiple independent layers, each with its own TTL.

When your OS resolves example.com, the query travels through at least three cache layers: your OS resolver cache (controlled by the TTL your OS honors, typically the full record TTL), your ISP's recursive resolver (which may cache independently of the TTL you set, especially if they cap minimum TTL at 300 or 600 seconds), and the authoritative nameserver response. Until the TTL on the old record expires at every intermediate cache, some resolvers continue to serve the old value. This is not misconfiguration — it is DNS working as designed.

This tool bypasses your local cache entirely by querying Cloudflare's public resolver (1.1.1.1) via DNS-over-HTTPS. What you see here is what a fresh resolver sees — useful for confirming the authoritative record has been updated while your ISP's cache is still serving the old value.

TTL: The Variable That Determines Propagation Time

TTL (Time To Live) is a field in every DNS record specifying how many seconds resolvers may cache the response before re-querying. Common values:

  • 60 s: aggressive — useful immediately before a planned migration; high query load on authoritative servers.
  • 300 s (5 min): standard for records that change occasionally.
  • 3600 s (1 hour): common default for stable records.
  • 86400 s (24 hours): appropriate for records that never change (static infrastructure). Cuts query volume significantly.

Before making a DNS change, lower the TTL of the target record to 60–300 seconds at least one current-TTL period in advance. If the current TTL is 86400 seconds, lower it today — the change propagates within 24 hours. Then make the actual record change tomorrow, when caches are refreshed frequently enough that propagation completes in minutes.

DNS Record Types and Their Real-World Uses

Beyond the basics, several record types are frequently misunderstood:

  • TXT records: free-form text with structured uses. SPF records (Sender Policy Framework) specify which mail servers are authorized to send email for your domain — a missing or misconfigured SPF record is one of the top reasons legitimate email lands in spam. DKIM records publish a public key for cryptographic email signing. DMARC records specify the policy for handling email that fails SPF or DKIM. Domain ownership verification (for Google Search Console, AWS ACM certificates, etc.) uses TXT records with provider-specified random values.
  • MX records: specify which server accepts inbound email, with a priority value (lower = preferred). Multiple MX records provide redundancy. The hostname in an MX record must resolve to an A record, not a CNAME — RFC 2181 prohibits CNAME targets in MX, NS, and SOA records.
  • CAA records: Certificate Authority Authorization specifies which certificate authorities are permitted to issue TLS certificates for your domain. Adding a CAA record that restricts issuance to only your CA prevents misissuance by other CAs. Browsers do not check CAA records directly — CAs do before issuing.
  • SOA record: the Start of Authority record holds zone metadata: primary nameserver, responsible email address (encoded with the first dot replacing @), serial number (used to track zone changes), and timing parameters (refresh, retry, expire, negative caching TTL).

How to Use This Tool

  1. Enter a domain name (with or without www).
  2. Select the record type to query: A, AAAA, CNAME, MX, TXT, NS, SOA, or CAA.
  3. Results from Cloudflare's public resolver appear within seconds, showing the current cached value and the remaining TTL.

FAQ

01 Why does this tool show a different result than my OS's nslookup? +

nslookup uses your OS's configured resolver, which may return a cached value or use a different upstream (your ISP, corporate DNS, or a custom server). This tool queries Cloudflare's 1.1.1.1 via DNS-over-HTTPS directly, bypassing your local and ISP caches. Results differ when propagation is in progress or when your local resolver is authoritative for a split-horizon zone.

02 How long does DNS propagation actually take? +

"DNS propagation" takes exactly as long as the TTL of the record being changed — at each cache layer independently. If your record has a 3,600-second TTL, resolvers may serve the old value for up to one hour after you update it. Global propagation is complete when all caches whose TTL was running have expired and re-queried. The practical range is minutes (if TTL was already lowered to 60–300 s) to 48 hours (for records with a 86,400 s TTL that caches had just refreshed).

03 What is a CNAME and when should I use an A record instead? +

A CNAME points a name to another name; an A record points a name directly to an IP. Use CNAME for subdomains pointing to services whose IP may change (CDNs, load balancers, PaaS endpoints) — the service provider handles IP changes without your involvement. Never use CNAME at the zone apex (the bare domain, example.com) — RFC prohibits it because the apex must have SOA and NS records, which cannot coexist with a CNAME. Many DNS providers offer a "ALIAS" or "ANAME" record that provides CNAME-like behavior at the apex by resolving at query time.

04 What does the SOA serial number mean? +

The serial number is an integer that increases every time the zone is modified. Secondary nameservers compare their serial to the primary's — if the primary's serial is higher, the secondary fetches the updated zone. The conventional format is YYYYMMDDNN (date plus a two-digit daily sequence), e.g., 2024031502 for the second change on March 15, 2024. Some DNS providers increment serially (1, 2, 3...) instead; both are valid as long as the number always increases.