DNS Lookup

What is a DNS Lookup?

A DNS lookup queries the Domain Name System — the internet's phone book — and shows the records published for a domain name. Every time you type an address like example.com into a browser, a DNS lookup happens behind the scenes to translate that human-readable name into the IP address of the server that hosts the site. Our DNS lookup tool performs that same query on demand and displays the raw records, so you can see exactly what the internet believes about any domain.

DNS is a distributed, hierarchical system. At the top sit the root servers, below them the top-level domain registries (.com, .org, country codes), and below those the authoritative name servers chosen by each domain owner. When you run a lookup, the query walks this chain — or asks a recursive resolver that has already walked it — and returns resource records, each with a type, a value, and a TTL (time to live) that says how long the answer may be cached. The record types tell very different stories: A and AAAA records map a name to IPv4 and IPv6 addresses, CNAME creates an alias to another name, MX designates mail servers, TXT carries free-form text used for verification and email security (SPF, DKIM, DMARC), NS names the authoritative servers, SOA holds zone administration data, and CAA restricts which certificate authorities may issue certificates for the domain.

Because nearly every internet failure is, at some level, a DNS failure, reading these records is a core troubleshooting skill. A website that "is down" is often a domain whose A record still points at an old host after a migration. Email that silently vanishes is usually a missing or malformed MX record, or an SPF TXT record with a syntax error that causes receiving servers to reject mail. A new subdomain that "doesn't work" is typically a CNAME that was never created or that points at a hostname that no longer exists. In each case, a thirty-second DNS lookup reveals the problem that an hour of guessing would miss.

DNS is also where security policy lives. SPF, DKIM, and DMARC records — all published as TXT records — determine whether your email gets delivered or flagged as spam, and whether attackers can spoof your domain. CAA records control which CAs may issue certificates, closing a real avenue for mis-issuance attacks. Checking these records is therefore not just debugging; it is due diligence for anyone who owns a domain or evaluates someone else's.

Our free DNS lookup queries authoritative servers directly and presents every major record type in a clean, readable report: A, AAAA, CNAME, MX, TXT, NS, SOA, and CAA, each with its TTL. Your queries are processed instantly and never stored. It pairs naturally with our WHOIS lookup (who owns the domain behind these records), our SSL lookup (is the certificate on the resolved IP valid?), and our IP lookup (where does that A record actually point?).

How to Use the DNS Lookup Tool

Reading any domain's DNS records takes seconds:

1. Enter the domain name. Type the domain into the input field — example.com is enough; you do not need https:// or www. To check a subdomain, enter it fully (e.g. mail.example.com or blog.example.com).
2. Run the lookup. Click the lookup button. The tool queries the domain's authoritative name servers directly and retrieves all major record types in one pass, usually within a couple of seconds.
3. Read the A and AAAA records. These are the addresses the domain resolves to. If you recently migrated hosts, confirm these point to the new server's IPs — a stale A record is the single most common cause of "the site works for some people but not others" (the "some people" are hitting cached old answers until the TTL expires).
4. Check mail records. Review the MX records to confirm mail is routed to the correct provider and in the right priority order (lower preference number = tried first). Then inspect TXT records for SPF, DKIM, and DMARC — missing or broken email-authentication records are why legitimate mail lands in spam.
5. Verify nameservers and SOA. The NS records should match the name servers your registrar lists, and the SOA record shows the zone's serial number and timing values. After DNS changes, a bumped serial confirms the zone actually updated.
6. Diagnose and re-check. If something is wrong — a missing record, a typo in an SPF string, a CNAME loop — fix it at your DNS provider, wait out the old TTL, and run the lookup again to confirm the corrected records are live worldwide. For ownership questions that DNS cannot answer, follow up with our WHOIS lookup.

Key Features of the DNS Lookup

All major record types in one report. A, AAAA, CNAME, MX, TXT, NS, SOA, and CAA are fetched together, so you get the domain's complete public DNS posture without running eight separate queries.

Authoritative answers. The tool queries the domain's authoritative name servers rather than relying solely on cached resolver data, which means you see what the domain owner actually published — essential when verifying a change you just made.

TTL visibility. Every record is shown with its time-to-live, so you know exactly how long stale answers may persist in caches worldwide. This is the number that determines how long a migration or fix takes to fully propagate.

Email authentication inspection. TXT records are displayed in full, making it easy to audit SPF syntax (watch for too many DNS lookups — the 10-lookup limit — and missing ~all/-all qualifiers), spot DKIM selectors, and confirm a DMARC policy exists. These three records are the difference between inbox and spam folder.

Subdomain support. Query any fully-qualified name, not just apex domains — verify that www, mail, shop, or api subdomains resolve where you expect before you point users or webhooks at them.

Instant and private. No signup, no software, results in seconds. Your lookup queries are processed instantly and never stored or logged.

DNS Lookup Use Cases

Developers and system administrators

The problem: You migrated a site to a new host, updated the A record, and the client reports the old site is still showing. Or a webhook integration fails with a TLS error, and you suspect the hostname resolves to the wrong server. Or email suddenly bounces after a DNS edit.

How this tool helps: A DNS lookup instantly shows the currently published records, so you can distinguish "the record is wrong" from "the record is right but cached" (check the TTL — that is your propagation countdown). For the TLS error, compare the A record against the certificate's SAN list using our SSL lookup: if the IP changed but the certificate on the new server does not cover the hostname, you have found your bug. For email, the MX and TXT records reveal misrouted mail or broken SPF in one glance.

SEO specialists

The problem: A site migration tanked rankings, or a client's new domain shows odd behavior in Search Console. DNS misconfigurations — apex domains that do not resolve, www subdomains pointing at different servers than the apex, missing IPv6 records — create duplicate-content and crawlability problems that look like mysterious ranking drops.

How this tool helps: Audit the domain's full record set during every migration: confirm the apex and www resolve to the intended infrastructure, check that no stale records point at decommissioned servers, and verify CAA records are not blocking your certificate renewals. Catching a DNS-level canonicalization issue here prevents weeks of ranking volatility later.

Students and the technically curious

The problem: Textbooks describe DNS as "the phone book of the internet," but that metaphor stays abstract until you see real records. You want to understand what actually happens between typing a URL and seeing a page.

How this tool helps: Look up domains you use every day and read their real records: the A records behind your favorite sites, the MX records revealing which email provider a company uses, the TXT records showing their SPF policies and domain verifications. It is the fastest way to turn DNS from a diagram into something concrete — and every record type you learn here maps directly to concepts in networking courses and certifications.

Diagnosing Common DNS Problems

Most DNS failures fall into recognizable patterns. Here is how to read the symptoms in a lookup report and fix each one.

"The site works for me but not for them" (or vice versa). This is the signature of TTL caching during a change. Your resolver has the new A record; theirs still holds the old one until its TTL expires. Confirm with the lookup that the authoritative record is correct, note the TTL, and wait it out — or ask the affected party to flush their local DNS cache. This is normal propagation behavior, not a bug, which is why lowering TTLs before migrations matters so much.

Website down after moving hosts. The A/AAAA records still point at the old server. Verify in the lookup, update the records to the new IPs, and confirm the new server actually serves the site for the domain (virtual-host configuration must recognize the hostname, or visitors get a default page). Also check that you updated both the apex and www records — updating one and forgetting the other is a classic half-migration.

Email suddenly bouncing or vanishing. Check MX records first: are they still pointing at your mail provider, in the right priority order? Then check TXT records for SPF: a single syntax error (a missing mechanism, an unquoted string, exceeding 10 DNS lookups) can cause receiving servers to reject everything. Common trigger: someone "cleaned up" DNS and deleted the TXT records, or added a second SPF record (there must be exactly one — multiple SPF records invalidate all of them).

Subdomain does not resolve. Either the record was never created, or a CNAME points at a target that no longer exists (a dangling CNAME — also a security risk, since attackers can claim abandoned targets). The lookup shows the CNAME target directly; follow it and verify the target itself resolves. For apex domains that need CDN-style aliasing, remember that CNAMEs are illegal at the apex — use your provider's ALIAS/ANAME record type instead.

Intermittent resolution failures. Compare the NS records against what your registrar lists. If they disagree, some queries go to name servers that no longer host your zone — a delegation mismatch that produces maddening on-again-off-again failures. Also check that all listed name servers answer authoritatively; a dead name server in the NS set causes slow, sporadic timeouts rather than clean failures.

HTTPS warnings after a DNS change. DNS and TLS interact: if you pointed the domain at a new server (or a new CDN), the certificate on the new endpoint must cover the hostname. Run our SSL lookup against the domain after every DNS change that moves traffic — a valid DNS record pointing at a server with the wrong certificate still breaks the site.

The universal debugging sequence: query the authoritative records with this tool, compare against what you intended to publish, fix discrepancies at your DNS provider, account for TTL caching, and re-verify. Ninety percent of DNS mysteries dissolve at step two.

Frequently Asked Questions

What is DNS and how does it work?

DNS (Domain Name System) is the distributed naming system that translates human-readable domain names like example.com into IP addresses like 93.184.216.34 that computers use to route traffic. When you enter a URL, your device asks a recursive resolver, which walks the hierarchy — root servers, then the top-level domain servers, then the domain's authoritative name servers — to find the requested records. Answers are cached at each level for the duration specified by the record's TTL, which is why DNS changes take time to propagate globally.

How long does DNS propagation take?

It depends on the TTL values of the changed records and how aggressively resolvers and ISPs cache. With a low TTL (e.g. 300 seconds), most of the world sees the change within minutes; with the common default of 3600 seconds (1 hour) or 86400 seconds (24 hours), stale answers can persist for a day or more. Best practice before a migration is to lower the TTL to 300 seconds at least 48 hours in advance, make the change, verify with a lookup tool, and then raise the TTL again. Note that some resolvers ignore low TTLs, so "up to 48 hours" remains the honest worst case.

What is the difference between A and CNAME records?

An A record maps a hostname directly to an IPv4 address (AAAA does the same for IPv6). A CNAME maps a hostname to another hostname — an alias. The practical difference: with an A record you manage the IP yourself, while with a CNAME the target's owner manages it. CDNs and managed platforms (Cloudflare, Shopify, Heroku) typically ask you to point a CNAME at their hostname so they can change IPs freely. One hard rule: a CNAME cannot coexist with any other record type on the same name, so you cannot put a CNAME on an apex domain that also needs MX or NS records — that is what provider-specific ALIAS/ANAME records are for.

Why is my email going to spam? Can DNS fix it?

Often, yes. Receiving servers check three DNS-published mechanisms: SPF (a TXT record listing which servers may send mail for your domain), DKIM (a TXT record holding the public key that verifies message signatures), and DMARC (a TXT record stating what to do when the first two fail, plus where to send reports). Missing SPF, an SPF record with syntax errors or over 10 DNS lookups, absent DKIM, or no DMARC policy are among the top reasons legitimate mail is flagged. Publishing correct records for all three — and monitoring DMARC reports — is the single highest-impact deliverability fix most domains can make.

What is a TTL and what value should I use?

TTL (time to live) is the number of seconds resolvers may cache a DNS record before asking again. Short TTLs (300 seconds) make changes propagate fast but increase query load and slightly slow initial lookups; long TTLs (86400 seconds) reduce load but make emergency changes painful. A common strategy: keep stable records at 3600–86400, and drop to 300 before any planned migration. Our lookup shows each record's TTL so you always know the propagation math for the change you are about to make.

What are MX records and how does mail routing work?

MX (mail exchanger) records tell the internet where to deliver email for a domain. Each MX record has a preference number — lower numbers are tried first, higher numbers are backups. When someone emails you@example.com, their mail server looks up example.com's MX records and connects to the lowest-preference reachable server. If no MX records exist, mail falls back to the domain's A record, which is rarely what you want. After changing email providers, always verify the new MX records with a lookup before canceling the old service.

Can DNS records reveal security problems?

Yes. A DNS lookup can expose missing SPF/DMARC (your domain can be spoofed for phishing), absent CAA records (any CA may issue certificates for your domain), dangling CNAMEs pointing at decommissioned services (a classic subdomain-takeover vector — an attacker claims the abandoned target and inherits your subdomain's trust), and unexpectedly changed name servers (possible domain hijacking). Security teams routinely audit DNS records for exactly these issues, and our lookup makes the raw data visible in seconds.

What is the difference between authoritative and recursive DNS?

Authoritative name servers hold the actual zone data published by the domain owner — they are the source of truth. Recursive resolvers (run by your ISP, Google at 8.8.8.8, or Cloudflare at 1.1.1.1) do the legwork of walking the hierarchy on your behalf and cache the answers. When you are verifying a change you just made, you want the authoritative answer (which this tool queries directly); when you are debugging what a user experiences, you want the recursive answer with its cache. Discrepancies between the two almost always come down to TTL caching.