DNS Lookup Explained — How Domain Resolution Works

Back to DNS Lookup

DNS Lookup Tool

Understanding DNS & How Lookups Work

A guide to how the Domain Name System works, what each record type means, and how to interpret DNS lookup results.


01

What Is DNS?

DNS — the Domain Name System — is the internet's address book. It translates human-readable domain names like example.com into the IP addresses that computers use to route network traffic.

Without DNS, every website would need to be reached by a raw IP address. DNS allows you to type a name and have the network figure out where to send your request — transparently, in milliseconds, on every connection you make.

DNS is a globally distributed, hierarchical database. No single server holds all the records. Queries are resolved by following the hierarchy from the top down, with results cached at every layer to reduce latency and server load.

Technical Note

DNS operates primarily over UDP on port 53, falling back to TCP for responses that exceed 512 bytes (or always over TCP with DNS-over-TLS / DNS-over-HTTPS). The root of the DNS hierarchy consists of 13 logical root nameserver addresses (operated by multiple organisations across hundreds of physical servers worldwide).
02

How DNS Resolution Works

When you type a domain into your browser, a multi-step lookup takes place before a connection is made. This process typically completes in under 50 milliseconds — and is often skipped entirely when a cached answer is available.

2.1 — The Lookup Chain

StepComponentRole
1Your device (stub resolver)Before sending any query, your device checks its local DNS cache — a short-term memory of recent lookups. If it has already resolved this domain recently, the saved answer is reused instantly. If nothing is cached, it forwards the query to the configured recursive resolver, which is set in your network settings or assigned automatically by DHCP.
2Recursive resolver (e.g. 8.8.8.8)The resolver does all the work on your behalf — you ask once and it handles everything. It first checks its own cache, which may already hold the answer from a recent lookup by another user on the same resolver. If the cache is empty, it begins the resolution chain by contacting the root nameserver. This is the server you configure (or your ISP assigns) in your network settings.
3Root nameserverThere are 13 logical root nameserver addresses at the top of the DNS hierarchy, operated across hundreds of physical servers worldwide. They hold no individual domain records — only a directory of which nameservers are responsible for each top-level domain (.com, .net, .org, etc.). The resolver contacts one of these first and receives a referral pointing it to the correct TLD nameserver.
4TLD nameserverThe TLD nameserver manages one domain extension — .com, .net, .org, and so on. It does not store individual website records, but it knows which nameservers have been registered as authoritative for each domain within that extension. The resolver receives a referral pointing it directly to the domain's own nameservers.
5Authoritative nameserverThis is the definitive source — the server that stores the actual DNS records configured by the domain owner, typically at a registrar or DNS hosting provider. Unlike every previous step, this server's answer is final. When you update a DNS record in your control panel, this is where the change is stored and served from.
6Recursive resolver (returns answer)Having received the authoritative answer, the resolver caches it for the duration specified by the record's TTL. Future queries for the same domain — from any user on this resolver — are answered from cache without repeating the chain. The final answer is returned to your device, completing the entire lookup in typically under 50 milliseconds.

Most lookups skip steps 3–5

Recursive resolvers cache responses aggressively. For popular domains, the resolver almost always has a cached answer and returns it without contacting the root or TLD nameservers. The full chain is only traversed on a cache miss — typically the first time a domain is queried, or after its TTL has expired.
03

DNS Record Types

Each DNS record type serves a specific purpose. The DNS Lookup tool supports all eight of the most common types.

AAddress

Maps a hostname to an IPv4 address. The most common record type — what most DNS lookups resolve to.

AAAAIPv6 Address

Maps a hostname to an IPv6 address. Used when a host is reachable over IPv6.

CNAMECanonical Name

An alias pointing to another hostname. The target hostname is then resolved separately. Cannot coexist with other records at the same name.

MXMail Exchange

Specifies mail servers for the domain, each with a numeric priority. Lower priority number = higher preference.

NSName Server

Lists the authoritative nameservers for the domain. Changing NS records transfers DNS control to a new provider.

TXTText

Arbitrary text data. Used for SPF (email sender policy), DKIM (mail signing keys), DMARC (email authentication policy), and domain ownership verification.

SOAStart of Authority

Zone metadata: primary nameserver, administrator email, serial number, and refresh/retry/expire timers that govern zone transfers.

PTRPointer

Reverse DNS lookup — maps an IP address back to a hostname. Queries are made against the special in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones.

CNAME Restriction at the Apex

A CNAME record cannot coexist with any other record type at the same name. This means you cannot use a CNAME at your apex domain (example.com) because the apex also requires NS and SOA records. Apex domains must use A or AAAA records directly. Some DNS providers offer a proprietary "CNAME flattening" or "ALIAS" record to work around this for CDN use cases.

TXT Records & Email Authentication

SPFv=spf1 include:... ~all — Defines which mail servers are authorised to send email for the domain.

DKIM — Published at selector._domainkey.example.com — Contains the public key used to verify mail signatures.

DMARCv=DMARC1; p=reject; — Sets the policy for handling mail that fails SPF or DKIM checks.

04

Resolvers & Caching

A DNS resolver (also called a recursive resolver) is the server that performs the full lookup chain on your behalf and caches results. Which resolver you use affects speed, privacy, and whether results may be filtered or modified.

ResolverIP AddressOperatorNotes
AutoYour ISP defaultISPVariable quality; may log queries or apply filtering
Google8.8.8.8GoogleFast and global; queries logged per Google privacy policy
Cloudflare1.1.1.1CloudflareFast; privacy-focused with minimal query logging
Quad99.9.9.9Quad9 FoundationBlocks known malicious domains; non-profit operated

🔍 Why query multiple resolvers?

ISP resolvers occasionally return stale, filtered, or incorrect results — or may inject advertisements via DNS hijacking. Querying the same record across Google, Cloudflare, and Quad9 and comparing the results can reveal resolver-level interference, propagation delays, or geo-specific differences in DNS responses.
05

TTL — Time to Live

Every DNS record has a TTL (Time to Live), measured in seconds. This value tells resolvers and clients how long to cache the record before re-querying the authoritative server for a fresh answer.

TTL RangeTypical Use
60 – 300 sLow TTL — records that change frequently, or during planned migrations
3,600 s (1 hr)Standard for most production A, AAAA, and CNAME records
86,400 s (24 hr)High TTL — stable records such as NS and MX; reduces resolver load

DNS Propagation

When you change a DNS record, old values remain cached by resolvers worldwide until their TTL expires. A record with a 24-hour TTL won't be refreshed by some resolvers for up to 24 hours after the change — this is what people mean by "DNS propagation." To minimise propagation delay before a planned change, lower the TTL to 60–300 seconds at least 24 hours in advance. After the change is complete, restore the TTL to a normal value.
06

How to Use This Tool

The DNS Lookup tool queries a real DNS resolver and returns the live response for any domain and record type combination.

1

Enter a domain

Type the full domain name — e.g. google.com, mail.example.com, or an IP address for PTR lookups (e.g. 8.8.8.8).

2

Select a record type

Choose the record type you want to query. Defaults to A. Use MX for mail servers, TXT for SPF/DKIM, NS for nameservers.

3

Select a resolver

Auto uses your network's default resolver. Select Google, Cloudflare, or Quad9 to query a specific public resolver.

4

Click Lookup

Results are returned within 1–2 seconds and include the record value, type, and TTL.

💡 Tip — Reverse DNS (PTR)

To look up the hostname for an IP address, select the PTR record type and enter the IP address as the domain (e.g. 8.8.8.8). The tool will automatically convert it to the correct reverse lookup format (8.8.8.8.in-addr.arpa) and return the PTR record if one exists.
07

Interpreting Results

Each row in the results table represents one DNS record returned by the resolver.

ColumnMeaning
NameThe hostname that was queried
TypeThe record type returned (A, MX, TXT, etc.)
ValueThe record data — IP address, hostname, or text content
TTLRemaining cache lifetime in seconds

Reading specific record types:

  • A / AAAAThe IP address(es) the domain resolves to. Multiple A records indicate load balancing or redundancy — clients typically use the first one returned.
  • CNAMEFollow the chain — a CNAME points to another hostname, which must itself resolve to an A or AAAA record. Chains longer than 8 hops are typically rejected by resolvers.
  • MXLower priority number = higher preference. priority 10 is preferred over priority 20. Multiple MX records provide mail server redundancy.
  • NSThe authoritative nameservers for the zone. These must match what is registered at the TLD registry. Discrepancies cause resolution failures.
  • TXTMultiple TXT records are common on the same name. Each serves a different purpose — read them individually. SPF, DKIM, and DMARC records each have their own distinct format.
  • SOAThe serial field is a version counter incremented on every zone change. The refresh, retry, and expire fields govern how secondary nameservers synchronise with the primary.

NXDOMAIN vs NOERROR with No Records

These two outcomes look similar but mean very different things. NXDOMAIN (Non-Existent Domain) means the domain itself does not exist at the authoritative nameserver. NOERROR with zero records means the domain exists but has no records of the queried type — the zone is valid but that specific record hasn't been configured.