How DNS Lookup Works (and How to Run One Yourself)

When you type ip2geo.dev into your browser and hit enter, your computer doesn’t actually know where to send the request. Computers move data using IP addresses, not human-readable names. Translating between the two is the job of DNS — the Domain Name System — and the act of translating one specific name is called a DNS lookup.

This post walks through what actually happens during a DNS lookup, every common record type you’ll encounter, why caching matters, and how to run a lookup yourself from the terminal, a browser, or our DNS lookup tool.

What a DNS Lookup Actually Is

A DNS lookup is a query. Your device asks: “What is the IP address of ip2geo.dev?” Somewhere on the internet, an authoritative server responds: “It’s 104.18.27.89 (or whichever address is currently configured).” Your device then opens a TCP connection to that IP, sends an HTTPS request, and receives the page.

That single step — name to IP — hides one of the most elegant and battle-tested systems on the internet. DNS has been running since 1983, predates the World Wide Web, and quietly handles trillions of queries per day across roughly 600 million domain names.

If you’ve ever wondered why your browser sometimes loads a page instantly and other times “stalls” for a fraction of a second before the page even starts to appear, that pause is almost always DNS resolution. Once the IP is known, the rest of the request is fast.

The Resolution Chain

A full DNS lookup isn’t one question to one server. It’s a chain of queries to several servers, each one knowing slightly more than the last. The chain has four roles:

1. Stub resolver — software inside your operating system. When an app asks for ip2geo.dev, the OS asks the stub resolver, which forwards the question upstream.
2. Recursive resolver — usually run by your ISP, your router, or a public service like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). This is the “concierge” — it does the actual legwork.
3. Root servers — 13 logical clusters of servers (in reality hundreds of physical machines, anycasted globally) that know where to find any top-level domain (.dev, .com, .io).
4. TLD nameservers — these know where to find the authoritative nameservers for a specific domain inside their TLD.
5. Authoritative nameservers — these know the actual records (IP addresses, mail servers, etc.) for the specific domain you asked about.

So a “cold” lookup for ip2geo.dev from a fresh resolver goes:

stub → resolver → root → .dev TLD → ip2geo.dev's authoritative NS → answer

That’s potentially five network hops before your browser even knows what server to contact. In practice, caching collapses most of these steps to zero hops, which is why DNS feels instant most of the time.

Why Caching Is the Real Hero

Every layer in the chain caches answers. The TTL (Time To Live) on the record — typically 300 to 86400 seconds — tells each layer how long to keep the answer before re-asking. Without caching, every page load on the internet would require five lookups to a half-dozen servers around the world. DNS would crumble within minutes.

This is also why DNS changes appear to “take time to propagate.” They don’t propagate — the new record is available the moment you set it on your authoritative nameserver. What’s actually happening is that resolvers around the world are still holding cached copies of the old record until their TTL expires. If your TTL was 3600 seconds, expect up to an hour of lag after a change. This is why DNS pros lower TTLs to 60 seconds before a migration, then raise them again afterwards.

The Record Types That Matter

A domain doesn’t just have one record. It has a whole table of them, keyed by type. The ones you’ll meet most often:

A record

Maps a name to an IPv4 address. The bread-and-butter record. ip2geo.dev. A 104.18.27.89.

AAAA record

Same as A, but for IPv6. As IPv6 adoption grows, dual-stacking with both A and AAAA is now standard. If you’re working with IPv6 directly, you might also want to know how to convert between IPv4 and IPv6 notation.

CNAME record

“Canonical name.” Aliases one hostname to another. www.ip2geo.dev. CNAME ip2geo.dev. means www.ip2geo.dev follows whatever ip2geo.dev resolves to. CNAMEs cannot coexist with any other record at the same name — a common gotcha.

MX record

Mail exchange. Tells SMTP servers which host(s) accept mail for the domain. Includes a priority number (lower = preferred). If you’ve ever configured email with a provider like Fastmail or Google Workspace, you’ve set MX records.

TXT record

Free-form text. Originally for arbitrary notes, now used for SPF (anti-spam), DKIM (mail signing), DMARC (mail policy), domain ownership verification, and a hundred other small protocols layered on top of DNS.

NS record

Nameserver delegation. Identifies which servers are authoritative for the zone. The TLD points to your NS records, your NS records point to your A/MX/TXT/etc records.

SOA record

Start of Authority. One per zone. Holds metadata about the zone itself: the primary nameserver, an admin email, a serial number for versioning, and various timer values used by secondary nameservers replicating the zone.

CAA record

Certificate Authority Authorization. Tells CAs which of them are allowed to issue TLS certificates for your domain. A small but important record for security — without a CAA record, any CA can technically issue a cert for your domain (which is bad).

PTR record

The reverse of an A record. Maps an IP back to a name. This is what powers reverse DNS lookups — given 1.1.1.1, what name does it claim to be? Mail servers and abuse-tracking tools use these extensively.

Running a Lookup Yourself

You don’t need any special tools to do a DNS lookup. Every major OS ships with one, and there are several ways to do it.

macOS / Linux: dig

dig ip2geo.dev

dig is the most flexible command-line lookup tool. It shows the full DNS exchange — the question, the answer, the timing, and which server replied. To ask for a specific record type:

dig ip2geo.dev MX
dig ip2geo.dev TXT
dig ip2geo.dev AAAA

To trace the entire resolution chain (root → TLD → authoritative):

dig +trace ip2geo.dev

macOS / Linux: nslookup

Older, simpler, still widely used:

nslookup ip2geo.dev
nslookup -type=mx ip2geo.dev

Windows

nslookup is built in. PowerShell also has Resolve-DnsName:

Resolve-DnsName ip2geo.dev -Type MX

In the browser

If you don’t want to drop to a terminal, the Ip2Geo DNS lookup tool runs A, AAAA, MX, NS, TXT, CNAME, SOA, and CAA queries for any domain and renders the results in a single page. Useful when you’re diagnosing a deployment from a phone or a locked-down workstation.

Common Lookup Failures and What They Mean

Even a simple lookup has half a dozen failure modes. Knowing what each one means saves a lot of time.

NXDOMAIN — the name doesn’t exist. The TLD nameserver says “I’ve never heard of this subdomain.” Usually a typo or a domain that was let expire.

SERVFAIL — something is broken upstream. The authoritative nameserver is unreachable, returning malformed responses, or DNSSEC validation failed. Try a different recursive resolver to confirm — if 1.1.1.1 says SERVFAIL but 8.8.8.8 works, it’s a resolver-side issue.

Timeout — no response at all within the resolver’s window (usually 2–5 seconds). The authoritative server is down or your network can’t reach it.

REFUSED — the server is alive but won’t answer your query. Usually because the server isn’t actually authoritative for the name you asked about.

Stale answer — the resolver returned an old, cached record. The fix is usually to wait for TTL expiry, query a different resolver, or flush the local DNS cache (sudo killall -HUP mDNSResponder on macOS; ipconfig /flushdns on Windows).

What Happens After the Lookup

Once the resolver returns an IP, your device doesn’t necessarily know anything else about that IP. To learn more — what country it’s in, which ISP runs it, what autonomous system it belongs to — you need an IP-to-geo lookup. That’s a different system entirely, and it sits on top of DNS rather than inside it.

If you’re building anything where you need to know “who is this user, geographically” after their request lands on your server, the DNS lookup is the first step and the IP geolocation lookup is the second. Tools like our IP lookup handle the second step.

Putting It All Together

DNS lookups are the silent foundation under every URL you’ve ever typed. The chain is short, the caches are aggressive, and most of the time it just works. When it doesn’t, knowing the record types and the chain structure cuts through 80% of the debugging.

Practical takeaways:

• Lower DNS TTLs before any planned change. Raise them after.
• Use dig for diagnostics, not nslookup. dig +trace is your friend.
• Every TXT record has a purpose. If you see one you don’t recognize, look it up before deleting.
• A and AAAA should usually be set together. Don’t ship IPv4-only in 2026.
• CAA records are cheap insurance. Set one even if you only use one CA today.
• If a change “isn’t working,” check TTLs first and DNSSEC second before assuming a typo.

Once a name resolves to an IP, the rest of the story is about that IP — its country, its ISP, its ASN. That’s where IP geolocation picks up. If you want to know what 8.8.8.8 actually is — what country, what network, what timezone — try the IP lookup tool or the Ip2Geo API directly.