What Are DNS Lookups?
Every time you type a URL into your browser, something has to figure out where that website actually lives. That's what a DNS lookup does. It takes a domain name like inventivehq.com and finds the IP address (like 192.0.2.1) that your computer needs to connect to the right server.
Think of it like a phone book for the internet. You know the name you want to reach, but your computer needs the number. DNS lookups happen constantly in the background, every time you load a page, send an email, or connect to an API. Most of the time you never notice them, but when something goes wrong with DNS, nothing works.
How DNS Lookups Work
A DNS lookup might seem simple from the outside, but there's actually a chain of servers involved. Here's what happens when you type inventivehq.com into your browser:
Step 1: Check the local cache. Your computer first checks if it already looked up this domain recently. If it has a cached result, it skips everything else and uses that. This is the fastest path.
Step 2: Ask the recursive resolver. If there's no cache hit, your computer sends the request to a recursive resolver. This is usually run by your ISP, though you can also use public ones like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. The resolver's job is to track down the answer on your behalf.
Step 3: Query the root nameserver. The resolver starts at the top of the DNS hierarchy by asking a root nameserver. The root doesn't know the IP address for inventivehq.com, but it does know where to find the .com TLD (Top-Level Domain) nameserver.
Step 4: Query the TLD nameserver. The resolver follows that referral and asks the .com TLD server. The TLD server doesn't have the final answer either, but it knows which authoritative nameserver is responsible for inventivehq.com.
Step 5: Query the authoritative nameserver. This is the server that actually holds the DNS records for the domain. It looks up the A record and returns the IP address.
Step 6: Return the result. The resolver passes the IP address back to your computer, which caches it for next time. Your browser then connects to that IP address and loads the page.
This whole chain usually finishes in under 100 milliseconds. You'd never know all that just happened.
A Visual Walkthrough
Your Computer: What's the IP for inventivehq.com?
↓
Recursive Resolver: I'll find out (queries root nameserver)
↓
Root Nameserver: Ask the .com TLD server
↓
Recursive Resolver: (queries .com TLD server)
↓
.com TLD: Ask inventivehq.com's authoritative nameserver
↓
Recursive Resolver: (queries authoritative nameserver)
↓
Authoritative NS: inventivehq.com's IP is 192.0.2.1
↓
Response: 192.0.2.1 returned to your computer
↓
Your Browser: Connects to 192.0.2.1
Why DNS Lookups Matter
Without DNS, the Internet Breaks
Imagine having to memorize 192.0.2.1 instead of inventivehq.com. Now multiply that by every website you visit. DNS lets us use names that make sense to humans while computers handle the numbers behind the scenes. It also means a website can move to a different server (and a different IP address) without anyone having to update their bookmarks.
Load Balancing and Failover
DNS doesn't just point to one server. A single domain can have multiple A records pointing to different servers, which lets traffic get distributed across data centers. If one server goes down, DNS can route visitors to a healthy one instead. This is how large sites stay online even during outages.
Email Routing
Email relies heavily on DNS. When you send a message to someone@example.com, your mail client looks up the MX (Mail Exchange) records for example.com to figure out which server handles their email. DNS also hosts SPF, DKIM, and DMARC records that help prevent spoofing and authenticate legitimate messages.
Service Discovery
Modern applications, especially those running in microservices or Kubernetes environments, use DNS internally to locate services. SRV records can point to specific ports and protocols, making DNS a lightweight service directory.
Security
DNSSEC adds cryptographic signatures to DNS responses so resolvers can verify they haven't been tampered with. TLS certificate validation often depends on DNS records too. CAA records let domain owners specify which certificate authorities are allowed to issue certs for their domain.
Real-World DNS Lookup Examples
Web browsing: You type https://inventivehq.com. Your browser does a DNS lookup, gets back 192.0.2.1, connects, and loads the page.
Sending email: You send a message to user@example.com. Your mail client looks up the MX record for example.com, finds mail.example.com at 192.0.2.5, connects to the mail server, and delivers the message.
API calls: Your application needs to reach api.example.com. It does a DNS lookup, resolves the IP, connects, and makes the request. If the API provider changes servers, they just update their DNS records and your app keeps working.
How DNS Lookups Affect Performance
The speed of a DNS lookup depends on where the answer comes from:
| Source | Typical Time |
|---|---|
| Local cache | Less than 1ms |
| ISP resolver cache | 10-50ms |
| Full recursive lookup | 100-500ms |
That 100-500ms range is the worst case, where the resolver has to walk the entire chain from root to authoritative server. Most lookups hit a cache somewhere along the way, so real-world performance is usually much faster.
Ways to Speed Things Up
Caching is the biggest factor. DNS results are cached at every level: your browser, your operating system, your ISP's resolver, and even at the TLD servers. The TTL (Time To Live) on each record controls how long caches hold onto it.
DNS prefetching lets browsers resolve domain names before you click a link. If a page references assets on cdn.example.com, the browser can look that up while you're still reading the page.
Public DNS resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8) are often faster than your ISP's default resolver because they have larger caches and better infrastructure.
Types of DNS Records
Not all DNS lookups are the same. The type of record you're querying for determines what you get back:
| Record Type | Purpose | Example |
|---|---|---|
| A | IPv4 address | inventivehq.com → 192.0.2.1 |
| AAAA | IPv6 address | inventivehq.com → 2001:db8::1 |
| CNAME | Alias to another domain | www → example.com |
| MX | Mail server | example.com → mail.example.com |
| TXT | Text data (SPF, DKIM, etc.) | SPF, DKIM, DMARC records |
| NS | Authoritative nameserver | Points to the servers for a domain |
| SRV | Service location | _ldap._tcp.example.com |
| CAA | Certificate authority authorization | Specifies who can issue TLS certs |
DNS Propagation: Why Changes Aren't Instant
When you update a DNS record, the change doesn't take effect everywhere at once. The old record is still cached by resolvers around the world, and those caches won't refresh until the TTL expires.
Here's the typical timeline:
- First 1-30 minutes: The change is live on the authoritative nameservers.
- 30 minutes to 24 hours: ISP resolvers start picking up the new record as their caches expire.
- 24-48 hours: Virtually all resolvers worldwide have the updated record.
If you know a change is coming, lower your TTL to something short (like 300 seconds) a day or two beforehand. That way, when you make the switch, caches expire faster and the new record propagates more quickly.
Troubleshooting Common DNS Issues
Slow DNS Resolution
If websites are slow to load but fast once they start, DNS is often the bottleneck. You'll typically see a "Resolving host..." or "Waiting for..." message in your browser's status bar for several seconds before anything happens.
The quickest fix is to switch to a faster DNS resolver. Try 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) in your network settings. If the problem is specific to your ISP's resolver, this usually solves it immediately.
NXDOMAIN (Domain Not Found)
An NXDOMAIN response means the resolver couldn't find any records for that domain. This can happen if the domain is misspelled, hasn't been registered, expired, or if the nameserver configuration is wrong. It also shows up during DNS propagation if the new records haven't reached your resolver yet.
Start by double-checking the domain name. If you just made DNS changes, give propagation some time. If the domain should definitely exist, check the nameserver delegation at your registrar.
Intermittent Failures
When DNS works sometimes but not others, the issue is usually one of the authoritative nameservers being down or unreachable. Since most domains have multiple nameservers, requests that hit the healthy server succeed while requests to the broken one fail.
Test with dig against each nameserver individually to identify which one is having problems. Also try querying from different DNS resolvers to rule out a resolver-specific issue.
Tools for DNS Lookups
Command Line
# Basic DNS lookup
nslookup inventivehq.com
dig inventivehq.com
host inventivehq.com
# Look up MX records
nslookup -type=MX example.com
# Query all record types
dig inventivehq.com ANY
# Trace the full resolution path
dig +trace inventivehq.com
dig is the most versatile of these. The +trace flag is especially useful because it shows you every step of the resolution chain, making it easy to spot where things break down.
Online Tools
For quick checks without opening a terminal, MXToolbox, DNSChecker, and WhatsMyDNS all let you look up records and check propagation status from multiple locations around the world. Google also runs a public DNS lookup tool at dns.google.
Best Practices
Use a reliable public DNS resolver. ISP resolvers vary in quality. Switching to Cloudflare or Google DNS is one of the easiest networking improvements you can make.
Lower your TTL before making changes. If your records have a 24-hour TTL, drop it to 5 minutes a day or two before you plan to make changes. After the change propagates, raise it back up.
Keep records documented. It's easy to lose track of DNS records, especially across multiple domains. Maintain a record of what's configured and why. This saves a lot of time when troubleshooting or onboarding new team members.
Audit regularly. Old records for decommissioned servers, test environments, or previous email providers should be cleaned up. Stale records can cause confusion and, in some cases, security issues.
Conclusion
DNS lookups are one of those things that quietly make the internet work. They happen billions of times a day, usually in milliseconds, converting the domain names we type into the IP addresses computers need. When they work, nobody thinks about them. When they don't, nothing loads.
Understanding how the process works puts you in a much better position to diagnose problems, optimize performance, and make smart decisions about your DNS infrastructure.