DNS Record Lookup

The Problem DNS Lookup Solves

DNS is often called the phone book of the internet, but checking it manually requires either trusting your local resolver's cache — which may be stale or split-horizon — or reaching for a terminal and remembering the right flags for dig or nslookup. A DNS lookup tool removes that friction: it queries the Domain Name System directly and returns the authoritative records associated with a domain — A records that point to IPv4 addresses, MX records that route email, TXT records used for domain ownership verification and email authentication, and more — without requiring shell access or local tooling.

The operational stakes go well beyond name resolution. TXT records carry SPF and DKIM policies that determine whether your outbound email is accepted or marked as spam. CAA records control which certificate authorities are permitted to issue TLS certificates for your domain. NS records determine which authoritative servers a registrar delegates to. Misreading or missing any of these during a migration is a common cause of self-inflicted outages, so having an instant, reliable way to verify them from any browser — on a phone during an incident, or a locked-down corporate laptop without dig installed — is a genuinely practical operational need.

How It Works Under the Hood

This tool sends DNS queries using Cloudflare's DNS-over-HTTPS (DoH) API at 1.1.1.1/dns-query. DoH wraps the DNS query inside an HTTPS request, which means the lookup is encrypted in transit and not visible to network intermediaries. The response contains the resource records from the authoritative nameservers for the queried domain, along with the TTL (Time to Live) for each record. Because the queries go through Cloudflare's globally distributed resolver, results represent the public DNS view rather than any cached or split-horizon view specific to your local network.

Real-World Use Cases

• Deployment verification: After updating a DNS record — such as pointing an A record to a new load balancer IP — confirm that the change is visible from the public internet before cutting over traffic.
• SSL certificate debugging: Verify that a CNAME or TXT record required by your CA for domain-validated (DV) certificate issuance has propagated correctly before triggering certificate issuance.
• Email deliverability checks: Inspect SPF TXT records and DMARC TXT records to ensure they are correctly configured and not inadvertently blocking your outbound mail.
• Nameserver delegation verification: Confirm that NS records reflect the correct authoritative nameservers after transferring a domain between registrars or migrating DNS hosting.

Common Mistakes & Troubleshooting

The most frequent mistake is checking a DNS change immediately after making it and concluding it "isn't working" — propagation is bound by the record's TTL, and a record published with an 86400-second TTL can legitimately take up to 24 hours to be visible everywhere, even though Cloudflare's resolver may already show the new value. A second common error is confusing your local resolver's cached answer with the authoritative one: if you changed a record minutes ago and your laptop still shows the old IP, the problem is usually local OS-level DNS caching, not propagation — flushing the local cache (sudo dscacheutil -flushcache on macOS, ipconfig /flushdns on Windows) often resolves it instantly. Third, people forget that CNAME records cannot coexist with other record types on the same name — adding a TXT record to a hostname that already has a CNAME is invalid DNS and will be silently rejected or cause unpredictable behaviour depending on the provider. Finally, when debugging SPF failures, remember that DNS enforces a 255-character limit per TXT string and a practical limit on the number of DNS lookups SPF evaluation can perform (10) — an SPF record with too many include: mechanisms will fail validation even though the record itself looks syntactically correct.

Frequently Asked Questions