How to Look Up DNS Records

DNS is the system that translates domain names into IP addresses. When something goes wrong, a website that will not load, email that never arrives, an SSL certificate that fails, checking DNS records is almost always the first debugging step. Understanding what each record type does, how queries flow through the system, and where to look when results disagree turns mysterious outages into solvable problems.

A short history of DNS

Before DNS, every computer on the early internet shared a single file called HOSTS.TXT, maintained at Stanford Research Institute. Each site downloaded the file periodically to learn the IP addresses of other machines. The system worked when the network had a few hundred hosts. It did not scale.

In 1983, Paul Mockapetris published RFC 882 and RFC 883, which described a hierarchical distributed naming system: the Domain Name System. The specs were refined in 1987 into RFC 1034 (concepts and facilities) and RFC 1035 (implementation and specification), which remain the foundational documents today. Instead of one giant file, the namespace was split into zones, each managed by its own authoritative servers, with a small set of root servers at the top of the tree.

DNS has been extended steadily ever since. AAAA records (RFC 3596, 2003) added IPv6 support. DNSSEC (RFCs 4033 to 4035, 2005) added cryptographic signatures to protect against spoofing. DNS-over-TLS (RFC 7858, 2016) and DNS-over-HTTPS (RFC 8484, 2018) encrypted queries so eavesdroppers and middleboxes could not see or tamper with them. Each layer of the system keeps backward compatibility, which is why a forty-year-old protocol still runs the modern web.

DNS record types

There are dozens of DNS record types, but a handful cover the vast majority of real-world lookups. Knowing what each one does makes triage faster.

A, AAAA, CNAME, and MX answer most everyday questions. TXT, NS, SOA, and CAA come up during configuration and security audits. SRV and NAPTR matter for VoIP, XMPP, and other service-discovery protocols. PTR matters for mail servers, since most spam filters reject senders without valid reverse DNS.

How to look up DNS records

1. Enter a domain: type any domain name (for example, example.com) into the lookup tool. You can also enter a subdomain such as mail.example.com if you want records for that label specifically.
2. Select a record type: choose A, AAAA, MX, TXT, CNAME, NS, SOA, or CAA. The tool also supports querying all common types at once for a quick overview.
3. Review the results, the response lists each matching record with its value, TTL (how long resolvers may cache it), and any extra fields such as MX priority or SOA serial numbers.
4. Compare against expectations: if you just changed a record, check that the new value appears. If you are debugging a third party, compare what you see to what they say they configured.

Debugging real-world problems with DNS

Website not loading? Check the A and AAAA records. If they are missing, the domain is unconnected; if they point to an old IP, traffic is hitting a server that no longer hosts the site. Also confirm the NS records match the registrar's listed nameservers, since a mismatch means the whole zone is being served from a stale source.

Email not arriving? Check MX records first; missing or incorrect MX records mean nothing can be delivered. Then check the TXT records for SPF (v=spf1), DKIM (default._domainkey or similar), and DMARC (_dmarc.example.com). Modern mail providers reject or quarantine messages that fail these checks, so a missing record can silently send your messages to spam.

SSL certificate errors? Check that the A record points to the server where the certificate is installed. If the site is behind a CDN, the A record should resolve to the CDN edge, not the origin. Check CAA records too; a CAA that lists only one certificate authority will block all others from issuing certificates, even when the domain owner expects them to work.

Domain verification failing? Google Workspace, Microsoft 365, Cloudflare, and most SaaS platforms ask you to add a TXT record to prove domain ownership. Look up the TXT records to confirm the exact string is present, including any quotes or prefixes the platform required.

DNS propagation feels slow? After changing records, resolvers around the world keep serving cached values until the TTL expires. Lowering the TTL to 300 seconds the day before a planned change makes the cutover much faster. The lookup tool shows the current TTL alongside each record, so you can predict how long stale values will linger.

SPF, DKIM, and DMARC

Three TXT-based records protect email from spoofing. SPF lists which servers are allowed to send mail for your domain. DKIM publishes a public key that recipients use to verify the cryptographic signature on each message. DMARC tells recipients what to do when SPF or DKIM fails: nothing, quarantine, or reject. All three live in DNS, all three are queried on every inbound message, and a typo in any of them can cripple deliverability. A DNS lookup tool is the fastest way to read what is actually published, separate from whatever the configuration UI claims.

Certificate provisioning and CAA

When you request a TLS certificate, the certificate authority queries DNS to verify control. Most use the dns-01 challenge: they ask you to publish a specific TXT record under _acme-challenge, then check that it appeared. CAA records add an extra layer; they declare which authorities may issue certificates for the domain. A misconfigured CAA can block legitimate renewals, so check CAA whenever a Let's Encrypt cron job suddenly stops working.

Common pitfalls

• Confusing recursive with authoritative answers, your ISP's resolver may serve a cached copy that is hours behind reality. The lookup tool uses Cloudflare's DNS-over-HTTPS endpoint, which queries authoritative servers directly and bypasses ISP caches.
• Ignoring TTL, if a record's TTL is 86400 seconds (24 hours), changes can take a full day to be visible everywhere. Plan TTL reductions a day ahead of any cutover.
• CNAME at the apex, CNAME records are not allowed at the root of a zone (example.com itself). Providers offer ALIAS or ANAME records as workarounds, but those are not standard DNS, so behaviour varies.
• Stacking multiple SPF records, SPF requires exactly one TXT record beginning with v=spf1. Two SPF records cause receiving servers to mark the result as PermError, which sinks deliverability.
• Forgetting the trailing dot, in zone files, names without a trailing dot are treated as relative to the zone, so missing the dot turns mail.example.com into mail.example.com.example.com.
• Mixing IPv4 and IPv6 A records, only A is for IPv4. Putting an IPv6 address in an A record (instead of AAAA) is a configuration error that some UIs do not catch.
• CNAME chains that loop, a CNAME pointing to another CNAME that points back creates a resolution loop. Resolvers cap the chain at around eight hops before giving up.
• Caching at multiple layers, browser, OS, router, and resolver each cache DNS independently. Flushing only one of them is rarely enough; reach for the lookup tool to bypass the chain entirely.
• Wildcard records masking missing entries, a wildcard A record (*.example.com) will match any subdomain that has no explicit record, which can hide misconfigurations.
• Trusting only one resolver, propagation is uneven. Query a few resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) when verifying a global change.

Alternative ways to query DNS

The browser-based lookup tool is the fastest path for most checks, but command-line tools give richer detail when you need it.

Each has trade-offs. dig +trace walks the DNS tree from the roots and shows every step, which is invaluable for proving where a chain breaks. nslookup ships everywhere and is fine for quick sanity checks. The web tool wins on speed and on not needing a terminal at all.

Privacy and DNS

Plain DNS queries travel in cleartext, which means your ISP and anyone on the network can see every domain you visit. Two encrypted variants address this: DNS-over-HTTPS (DoH) wraps queries in HTTPS, and DNS-over-TLS (DoT) wraps them in TLS on a dedicated port. The lookup tool uses Cloudflare's DoH endpoint, so your query to the resolver is encrypted in transit. The domain you ask about is still observable to the resolver itself; if that concerns you, run your own resolver (Unbound, Pi-hole) or use a paid privacy-focused service that promises not to log.

Browser-based lookups never store your queries on our servers. The request goes from your browser straight to the DoH resolver and the response renders client-side. There is no log to subpoena, no analytics on which domains you checked, and nothing to leak in a future breach. For a task as routine as DNS debugging, that is exactly the level of privacy the work deserves.