Skip to content
trace·warrior
Branching tree of five nodes under a magnifying glass, with one bottom node highlighted
updated · 2026-11-07

How to perform a DNS lookup

Resolve any hostname to its A, AAAA, MX, TXT, CNAME, NS, or SOA records, step by step, with the tools you actually need and how to read the answers.

DNSTrace Warrior Team
6 min read

A DNS lookup answers a single question with surprising depth: what record does the Domain Name System hold for this hostname? The right tool, the right record type, and a basic feel for the response will save you hours of guesswork on bad days.

This guide walks through the full workflow, from choosing the record type, to running the lookup, to interpreting the result, to ruling out cache and propagation issues when something looks wrong.

What is a DNS lookup

A DNS lookup is a query against the Domain Name System asking "what is the X record for this name?" where X is the record type. The full registry is long, but the most common are:

  • A - IPv4 address (4 bytes), defined in RFC 1035 with MX, NS, TXT, CNAME, and SOA
  • AAAA - IPv6 address (16 bytes), defined in RFC 3596
  • MX - mail exchanger (the server that accepts email for this domain)
  • TXT - free-form text (SPF, DKIM verification, domain-ownership proofs)
  • CNAME - alias from one hostname to another
  • NS - the authoritative nameservers for the zone
  • SOA - start of authority, contains the zone's master metadata

When people say "DNS checker" or "nslookup" or "ns lookup", they generally mean any tool that runs one of these queries. Pick the record type that answers your real question.

Step 1. Open the DNS lookup tool

Open the DNS Lookup tool. Everything you need is visible up front: the hostname you want to resolve, the record types you want to query, and the resolver to ask.

If you already know what you need, you can pre-fill the URL: https://www.tracewarrior.com/tools/dns-lookup?domain=example.com&types=A,MX runs the lookup automatically when you land on the page. Useful for bookmarks or sharing a specific lookup with a colleague.

Step 2. Enter the hostname

Type the hostname into the field. A few rules:

  • No http:// or https:// prefix. DNS doesn't care about protocols.
  • No trailing slashes.
  • Subdomains are valid and common. mail.example.com is a different hostname from example.com and resolves separately.

If you've heard a domain referred to with a leading dot (.example.com), drop the leading dot. That's nameserver-config syntax, not a query.

Step 3. Pick the record types

Click the type chips to toggle each record you want (CAA, SRV, PTR, DS, DNSKEY, NAPTR, and TLSA are there too). Default is A, AAAA, MX, which covers the most common "is this domain set up?" question. Specifically:

  • Migrating a site? A and AAAA tell you where the domain is currently pointed.
  • Setting up email? MX shows the mail exchangers in priority order.
  • Investigating an SPF or DKIM issue? Add TXT to see the email-authentication records.
  • Verifying you own a domain? Most verification systems use a TXT record on the apex or a _subdomain.
  • Debugging delegation? NS shows the authoritative nameservers; SOA shows zone metadata including serial number.
  • Tracking a chain of redirects? CNAME tells you which hostname aliases to which.

You can pick as many types as you want in one lookup. The tool runs each query in parallel and returns them all.

Step 4. Read the result

After you click Run lookup, the result table renders with three columns: TYPE, TTL, VALUE. A badge above it names the resolver that answered.

This is the real result for example.com with A, AAAA, MX, TXT, NS, and SOA selected, on 7 November 2026:

10 RECORDS · 44ms
CLOUDFLARE · LONDON

TYPE  TTL     VALUE
A     242s    104.20.23.154
A     242s    172.66.147.243
AAAA  34s     2606:4700:10::ac42:93f3
AAAA  34s     2606:4700:10::6814:179a
MX    300s    0
TXT   300s    v=spf1 -all
TXT   300s    _k2n1y4vw3qtb4skdx9e7dxt97qrmmq9
NS    75247s  hera.ns.cloudflare.com
NS    75247s  elliott.ns.cloudflare.com
SOA   18s     elliott.ns.cloudflare.com dns.cloudflare.com 2418004112 10000 2400 604800 1800

A few things worth knowing:

  • Multiple A or AAAA records mean the domain is using round-robin or anycast. A single lookup may return all of them.
  • TTL is how many more seconds the resolver will keep serving its cached copy. It counts down between lookups, which is why the AAAA records read 34s here.
  • MX records are returned sorted by priority (lower number = higher priority, primary mail server). The lone 0 above is a null MX: priority 0 and no host, which is how example.com declares it accepts no mail at all.
  • TXT records are shown without their surrounding quotes. v=spf1 -all says no server may send mail for this domain.
  • NS records are the authoritative nameservers for the zone, useful when investigating "is my registrar's delegation correct?"
  • SOA lists the primary nameserver and the admin mailbox, then five numbers: serial, refresh, retry, expire, and minimum TTL. The serial increments every time the zone is updated. Cache-invalidation magic.

If the result table is empty for a type, that record doesn't exist for the hostname. If the entire lookup fails with NXDOMAIN, the hostname doesn't resolve at all.

Step 5. Verify against authoritative DNS when in doubt

The DNS lookup goes through a recursive resolver, which means the answer may be cached. The Resolver select lets you ask Cloudflare, Google, Quad9, or OpenDNS in turn, and the TTL column shows how fresh each answer is. If you've just made a DNS change and want to verify it's live, repeat the lookup a minute or two after the change with a fresh hostname (fresh.example.com if you have control over the zone) to bypass cache.

For really stuck propagation, query authoritative nameservers directly. The NS record in step 4 tells you which servers to query. Pick one of them and run the same record-type lookup against it. The answer you get from authoritative DNS is the truth as of right now, ignoring all caches.

There's a longer field-notes piece on the mechanics of DNS propagation, TTLs, and the difference between authoritative and recursive. Recommended reading if you do this often.

Common DNS lookup mistakes

A few patterns that cost time:

Trusting your local resolver. Your laptop, your ISP, and your office firewall all cache DNS. Any of them may be holding an answer that's hours out of date. Always cross-check from at least one other resolver when something looks wrong.

Wrong record type. Looking up A on a mail-only subdomain returns nothing. You needed MX. Looking up MX on the apex when mail is on mail.example.com returns no mail records. There's a CNAME or A on a subdomain.

Forgetting AAAA. IPv6 is increasingly the path of least resistance for users on modern networks. A site that resolves on IPv4 but breaks on IPv6 is invisible to many home connections. AAAA gets you a fast check.

Cached negative answers. When a resolver gets an NXDOMAIN for a hostname, it caches that negative result. If you just added a record, your resolver may keep saying "doesn't exist" for the TTL of the SOA's minttl field (RFC 2308 sets the rule). The fix is the same: query authoritative or wait it out.

Related tools

  • Reverse DNS lookup - when you have an IP and want the hostname (the PTR record). Useful for verifying mail-server reverse-lookup setup.
  • WHOIS lookup - registrar and ownership data, separate from DNS.
  • SSL Certificate Checker - once DNS resolves, the next thing to check is the certificate.

TL;DR

  1. Open the DNS Lookup tool.
  2. Enter the hostname (no protocol, no trailing slash).
  3. Pick the record types relevant to your question. Defaults of A, AAAA, MX cover most lookups.
  4. Read the result table. Empty rows for a type mean no record of that type exists.
  5. If the answer looks wrong, suspect cache. Verify against authoritative nameservers (use the NS row) or wait out the TTL.

This guide covers the standard workflow, same one you'd run with dig, nslookup, or host from a terminal. The advantage of the web tool is shareable URLs and a result table you can read at a glance, particularly on devices where you don't have a shell.