DNS Queries: Translate Names

You type api.example.com into a browser, and somehow your request reaches the right server — but how? Under the hood, every connection over IPv4 or IPv6 needs a numeric address, and mapping that friendly name to an address is the job of the Domain Name System (DNS). If you've ever seen curl: Could not resolve host or spent an hour chasing a "network" problem that was really a DNS misconfiguration, this lesson is for you. You'll learn how DNS queries translate names to IPs, how to inspect that process with practical Linux tools, and how to fix the most common DNS failures before they waste another minute of your day.

The problem this lesson solves

Every TCP/IP connection — an HTTP request, an SSH session, a database client — ultimately needs an IP address. Humans are terrible at remembering 142.250.190.46, but give us google.com and we're fine. DNS is the phone book of the internet: it translates human-readable names into machine-readable IP addresses.

But DNS is more than a lookup. It's a distributed, hierarchical database with caching layers, multiple record types, and failure modes that can take down an entire service. When dig returns nothing or nslookup hangs, the problem might be:

• a dead DNS server
• a wrong search domain in /etc/resolv.conf
• a missing or typo'd DNS record
• a local cache holding a stale entry

Without a solid mental model, you'll be stuck guessing. This lesson gives you a repeatable method to translate names with DNS queries — and to know exactly which layer is failing when things go wrong.

Core concept / mental model

Think of DNS as a distributed lookup service. Your machine doesn't know every domain on the internet; instead, it asks a chain of servers, each one handing you closer to the final answer. The classic model has three roles:

• Resolver — your OS or local DNS client (like systemd-resolved or dnsmasq) that initiates queries on your behalf.
• Recursive resolver — often your ISP or a public service (e.g., 8.8.8.8) that walks the DNS hierarchy until it finds the answer.
• Authoritative nameserver — the server that owns the DNS records for a domain and can give a definitive answer.

A DNS query is simply a request sent to a resolver, asking: "What IP does this name map to?" The response can be a direct answer (address record), a referral to another server, or an error. The A record holds an IPv4 address, AAAA holds IPv6, and the CNAME record aliases one name to another — the kind of thing behind www.example.com pointing to example.com.

Pro tip: Most people think DNS is a single lookup. In practice, it's a cascade — and understanding that cascade is what separates someone who can debug DNS from someone who just restarts their router.

The entire hierarchy looks like this: your resolver → root servers → TLD servers (.com) → authoritative servers for the domain. Each step narrows the search until an authoritative answer is found. Caching occurs at every level, which is why a change to a DNS record can take minutes to hours to propagate.

How it works step by step

If you want to translate a name with a DNS query yourself, you follow a sequence:

1. Choose your tool. dig is the gold standard for DNS troubleshooting. nslookup is older but still common. host is a quick alias for simple lookups.
2. Issue a query for a record type. The default is A, but you can ask for AAAA, MX, TXT, CNAME, and more.
3. Read the response section. The answer (if any) appears in the ANSWER SECTION. The status line tells you if it was NOERROR, NXDOMAIN, SERVFAIL, or REFUSED.
4. Check the query time and server. This tells you how long the lookup took and which resolver replied — early insight into caching or reachability issues.
5. Verify against an authoritative source. Use dig @<ip> to query a specific server directly, bypassing caches. This is your ground truth.

For resolution to work end-to-end, the chain must be complete: your /etc/resolv.conf points to a reachable resolver, the resolver can reach root servers, and the authoritative server has the record you need. Break any link, and you'll see symptoms like NXDOMAIN or timeouts.

Hands-on walkthrough

Let's get practical. Fire up a terminal on any Linux machine with dig installed (if not, install dnsutils on Debian/Ubuntu or bind-utils on RHEL/Fedora).

First, a basic DNS query to resolve a domain's IPv4 address:

dig example.com

The output (abridged) looks like:

;; ANSWER SECTION:
example.com.        3600    IN  A   93.184.216.34

;; Query time: 41 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jan  3 12:00:00 2025
;; MSG SIZE  rcvd: 56

You just translated the name example.com to the IP 93.184.216.34. Wait — where did the query go? The SERVER line shows your local resolver (often your router or a local DNS service). Now, let's be explicit and query a public resolver directly:

dig @8.8.8.8 example.com A

This bypasses your local cache and asks Google's resolver. Any delay here points to your network path, not your local config.

Next, let's ask for a different record type. To see what handles email for a domain, query MX records:

dig gmail.com MX

You'll get lines like gmail-smtp-in.l.google.com. with priority numbers — perfect for debugging email delivery issues.

For a quick scripted lookup, use host or nslookup:

host example.com
nslookup example.com

Both are fine for a one-liner, but dig gives you full control over the query and shows every detail — that's why it's the standard for troubleshooting.

Now, a more interesting scenario: tracing the full resolution path. Use dig +trace to see how the resolver walks the hierarchy:

dig +trace example.com

You'll see root servers delegating to .com TLD servers, which then point to the authoritative nameservers for example.com. This is the entire chain — and it's the best way to see where a lookup breaks.

Compare options / when to choose what

You have three main command-line tools for DNS queries. Here's a quick comparison:

For automation and deep dives, dig is your default. For interactive or simple checks, nslookup is fine. host is great when you only need a single line.

If you're writing a script that needs to translate names to IPs programmatically, you might also consider getent hosts (uses system resolver and caches) or python3 -c "import socket; print(socket.gethostbyname('example.com'))" — but those don't give you the visibility dig provides.

Troubleshooting & edge cases

DNS errors are frustrating because they mimic other network issues. Here's how to pinpoint the real cause:

• dig example.com returns ;; connection timed out; no servers could be reached → Check your /etc/resolv.conf for valid nameservers. Run cat /etc/resolv.conf and make sure the IP addresses are reachable (try ping 8.8.8.8).
• status: NXDOMAIN → The domain does not exist (or you misspelled it). Verify with dig @8.8.8.8 to rule out local cache issues.
• status: SERVFAIL → The resolver couldn't get a valid answer, often due to DNSSEC validation failure or upstream outage. Try dig +dnssec to see validation errors.
• status: REFUSED → Your resolver refuses to answer, likely because it's configured to only serve certain domains (e.g., a corporate DNS). Try a public resolver like @8.8.8.8.
• Caching sanity: If you just changed a DNS record and you're seeing old IPs, query the authoritative server directly with dig @ns1.example.com example.com A to bypass caches.

Edge case: split-horizon DNS. In corporate environments, the same name may resolve differently inside vs. outside the network — your local resolver may give you an internal IP while a public resolver gives a public one. This is by design, but debugging requires you to compare dig from within and outside the network.

Edge case: IPv6 vs IPv4. If dig example.com returns only AAAA records but your network doesn't support IPv6, connections may fail. Check both record types explicitly.

What you learned & what's next

You now understand how DNS queries translate names to IP addresses — the pain of failures, the mental model of the resolver hierarchy, the step-by-step lookup process, and the hands-on commands (dig, nslookup, host) to diagnose and solve issues. You can read a dig response, interpret error statuses, and choose the right tool for the job.

This foundation is exactly what you need for the next lesson in our Linux · networking · telemetry track: HTTP requests and working with web APIs. Knowing how names resolve to IPs means you'll be able to separate DNS problems from HTTP connection problems — and that's a superpower when you're building and debugging network services.

Go ahead: open a terminal, run dig example.com, and see the answer for yourself. You're one step closer to networking fluency.