DNS Lookup: How Domain Names Work
· 12 min read
Table of Contents
- What is DNS and Why It Matters
- How DNS Works: The Complete Resolution Process
- DNS Record Types Explained
- DNS Lookup Commands and Tools
- Understanding DNS Caching and TTL
- DNS Security: Threats and Protection
- Common DNS Issues and Solutions
- Optimizing DNS Performance
- Advanced DNS Concepts
- Frequently Asked Questions
- Related Articles
What is DNS and Why It Matters
The Domain Name System (DNS) is often called the "phonebook of the internet," and for good reason. Every time you visit a website, send an email, or use any internet service, DNS works behind the scenes to translate human-readable domain names into machine-readable IP addresses.
Without DNS, you'd need to memorize strings of numbers like 172.217.14.206 instead of simply typing google.com into your browser. This translation service is so fundamental to how the internet works that when DNS fails, entire portions of the web become inaccessible.
DNS operates as a distributed database system, with millions of servers worldwide working together to resolve billions of queries every day. This decentralized architecture makes the internet both scalable and resilient, allowing it to handle massive traffic loads while maintaining redundancy.
Quick tip: DNS isn't just for websites. It's used for email delivery (MX records), service discovery, load balancing, and even spam prevention. Understanding DNS is essential for anyone working with networked systems.
How DNS Works: The Complete Resolution Process
When you type a domain name into your browser, a complex chain of events unfolds in milliseconds. This process, called DNS resolution, involves multiple servers and caching layers working together to deliver the IP address you need.
Step-by-Step DNS Resolution
- Browser Cache Check: Your browser first checks its own cache for any recently resolved IP addresses. Modern browsers cache DNS records for a short period (typically 60 seconds to a few minutes) to speed up repeat visits to the same site.
- Operating System Cache: If the browser cache misses, the query moves to your operating system's DNS resolver cache. This cache stores DNS records for all applications on your system, not just your web browser. On Windows, you can view this cache using
ipconfig /displaydns. - Router Cache: Many home and office routers also maintain their own DNS cache. This provides another layer of speed optimization before queries leave your local network.
- ISP DNS Resolver: When local caches don't have the answer, your query reaches your Internet Service Provider's DNS resolver (also called a recursive resolver). This server is configured automatically when your device connects to the network via DHCP.
- Root Nameservers: The ISP's resolver contacts one of the 13 root nameserver systems (actually hundreds of servers using anycast routing). These servers don't know the IP address of specific domains, but they know where to find the authoritative servers for each top-level domain (TLD).
- TLD Nameservers: The root server directs the query to the appropriate TLD nameserver. For example, queries for
.comdomains go to .com TLD servers, while.orgqueries go to .org servers. These servers maintain information about which authoritative nameservers handle each domain within their TLD. - Authoritative Nameservers: Finally, the query reaches the domain's authoritative nameserver, which is configured by the domain owner. This server contains the actual DNS records mapping the domain to its IP address and other information.
- Response and Caching: The IP address travels back through the chain, with each server caching the result according to the record's Time To Live (TTL) value. Your browser receives the IP address and can now establish a connection to the web server.
This entire process typically completes in 20-120 milliseconds, though it can be much faster when cached results are available. You can test DNS resolution speed using our DNS Lookup Tool to see how quickly different DNS servers respond.
Pro tip: The first DNS lookup for a domain is always slower than subsequent lookups due to caching. This is why websites often feel faster on repeat visits, even if you clear your browser cache.
Recursive vs. Iterative DNS Queries
DNS queries come in two flavors: recursive and iterative. Understanding the difference helps explain how DNS servers communicate with each other.
Recursive queries place the burden of finding the answer on the DNS server. When your computer sends a recursive query to your ISP's resolver, that server is responsible for following the entire chain until it gets a definitive answer. The resolver does all the work and returns either the IP address or an error.
Iterative queries are used between DNS servers. When your ISP's resolver queries a root server, it receives a referral to the next server in the chain rather than a final answer. The resolver then queries that server, receives another referral, and continues until it reaches the authoritative nameserver.
DNS Record Types Explained
DNS records are instructions stored on authoritative nameservers that provide information about a domain. Different record types serve different purposes, from pointing domains to servers to verifying email authenticity.
| Record Type | Purpose | Example |
|---|---|---|
A |
Maps domain to IPv4 address | example.com → 192.0.2.1 |
AAAA |
Maps domain to IPv6 address | example.com → 2001:db8::1 |
CNAME |
Creates alias pointing to another domain | www.example.com → example.com |
MX |
Specifies mail servers for domain | example.com → mail.example.com (priority 10) |
TXT |
Stores text information (SPF, DKIM, verification) | "v=spf1 include:_spf.google.com ~all" |
NS |
Delegates subdomain to nameservers | example.com → ns1.example.com |
PTR |
Reverse DNS lookup (IP to domain) | 192.0.2.1 → example.com |
SRV |
Specifies location of services | _sip._tcp.example.com → sipserver.example.com:5060 |
CAA |
Specifies which CAs can issue certificates | 0 issue "letsencrypt.org" |
A and AAAA Records: The Foundation
A records are the most fundamental DNS record type, mapping domain names directly to IPv4 addresses. When you visit a website, your browser typically looks up the A record first to find the server's IP address.
AAAA records (pronounced "quad-A") serve the same purpose for IPv6 addresses. As the internet transitions to IPv6, more domains are adding AAAA records alongside their A records to support both protocols.
CNAME Records: Domain Aliases
CNAME (Canonical Name) records create aliases that point to other domain names. They're commonly used to point www.example.com to example.com, or to point multiple subdomains to a single server.
One important limitation: CNAME records cannot coexist with other record types at the same name. This means you can't have a CNAME and an MX record for the same domain, which is why CNAMEs are typically used for subdomains rather than root domains.
MX Records: Email Routing
MX (Mail Exchange) records tell email servers where to deliver mail for your domain. Each MX record includes a priority value—lower numbers indicate higher priority. If the primary mail server is unavailable, senders will try servers with higher priority values.
For example, Google Workspace uses multiple MX records with different priorities to ensure email delivery even if one server is down. You can check your domain's MX records using our MX Lookup Tool.
TXT Records: Verification and Security
TXT records store arbitrary text data and have become essential for email security and domain verification. Common uses include:
- SPF records: Specify which servers can send email on behalf of your domain
- DKIM records: Provide public keys for email signature verification
- DMARC records: Define policies for handling failed email authentication
- Domain verification: Prove domain ownership to services like Google Search Console
- Site verification: Confirm ownership for various web services and platforms
Pro tip: TXT records have a 255-character limit per string, but you can concatenate multiple strings in a single record. Long DKIM keys often use this technique to fit within DNS constraints.
DNS Lookup Commands and Tools
Whether you're troubleshooting connectivity issues, verifying DNS changes, or investigating domain configurations, several command-line tools and online services can help you query DNS records.
Command-Line DNS Tools
nslookup is the most widely available DNS lookup tool, included with Windows, macOS, and most Linux distributions. Basic usage is simple:
nslookup example.com
nslookup -type=MX example.com
nslookup example.com 8.8.8.8
The first command performs a basic A record lookup. The second queries MX records specifically. The third queries using Google's DNS server (8.8.8.8) instead of your default resolver.
dig (Domain Information Groper) is more powerful and provides detailed output. It's the preferred tool for DNS professionals and is available on macOS and Linux by default:
dig example.com
dig example.com MX
dig example.com +short
dig @8.8.8.8 example.com
dig example.com +trace
The +short flag provides concise output with just the answer. The +trace flag shows the complete resolution path from root servers to authoritative nameservers, which is invaluable for troubleshooting.
host is a simpler alternative to dig, providing clean output without extra details:
host example.com
host -t MX example.com
host -a example.com
Online DNS Lookup Tools
Web-based DNS tools offer advantages over command-line utilities, including the ability to query from multiple geographic locations and check DNS propagation across different servers worldwide.
Our DNS Lookup Tool provides comprehensive DNS record queries with a user-friendly interface. You can check A, AAAA, CNAME, MX, TXT, NS, and other record types without installing any software.
For checking DNS propagation after making changes, our DNS Propagation Checker queries servers around the globe to show how your DNS changes are spreading across the internet.
Interpreting DNS Query Results
Understanding DNS query output helps you diagnose issues quickly. Here's what to look for in dig output:
- ANSWER SECTION: Contains the actual DNS records you requested
- AUTHORITY SECTION: Shows the authoritative nameservers for the domain
- ADDITIONAL SECTION: Provides IP addresses for nameservers mentioned in other sections
- Query time: How long the lookup took (useful for performance analysis)
- SERVER: Which DNS server answered your query
- WHEN: Timestamp of the query
- MSG SIZE: Size of the DNS response packet
Quick tip: If you see "NXDOMAIN" in your DNS query results, it means the domain doesn't exist. "SERVFAIL" indicates the DNS server encountered an error, while "REFUSED" means the server declined to answer your query.
Understanding DNS Caching and TTL
DNS caching is crucial for internet performance, reducing the load on DNS servers and speeding up website access. However, caching can also cause confusion when you're making DNS changes and wondering why they haven't taken effect yet.
How DNS Caching Works
Every DNS record includes a Time To Live (TTL) value, specified in seconds, that tells caching servers how long they can store the record before querying the authoritative nameserver again. Common TTL values range from 300 seconds (5 minutes) to 86400 seconds (24 hours).
When a DNS resolver caches a record, it decrements the TTL value each second. Once the TTL reaches zero, the cached record expires and the resolver must fetch a fresh copy on the next query.
DNS Caching Layers
DNS records can be cached at multiple levels, each with its own TTL countdown:
- Browser cache: Typically 60 seconds to a few minutes, regardless of the record's TTL
- Operating system cache: Respects the record's TTL but may have minimum and maximum limits
- Router cache: Varies by router model and configuration
- ISP resolver cache: Strictly follows the record's TTL value
- Public DNS services: Services like Google DNS (8.8.8.8) and Cloudflare DNS (1.1.1.1) respect TTL values
Planning DNS Changes
When you need to change DNS records, especially for critical services, follow this strategy to minimize downtime:
- Lower the TTL: 24-48 hours before your change, reduce the TTL to 300 seconds (5 minutes). This ensures caches expire quickly once you make the actual change.
- Make the change: Update your DNS records to point to the new IP address or server.
- Monitor propagation: Use tools like our DNS Propagation Checker to verify the change has spread globally.
- Restore the TTL: After confirming the change is working, increase the TTL back to a normal value (3600-86400 seconds) to reduce DNS query load.
Clearing DNS Caches
Sometimes you need to clear cached DNS records to see changes immediately. Here's how on different systems:
Windows:
ipconfig /flushdns
macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Linux (systemd-resolved):
sudo systemd-resolve --flush-caches
Chrome browser:
Navigate to chrome://net-internals/#dns and click "Clear host cache"
Pro tip: Flushing your local DNS cache doesn't affect caches on your ISP's servers or other resolvers. If you're still seeing old DNS records after flushing, the cache exists upstream and you'll need to wait for the TTL to expire.
DNS Security: Threats and Protection
DNS was designed in the 1980s without security in mind, making it vulnerable to various attacks. Understanding these threats and implementing protective measures is essential for maintaining secure network infrastructure.
Common DNS Security Threats
DNS Spoofing (Cache Poisoning): Attackers inject false DNS records into a resolver's cache, redirecting users to malicious websites. This can lead to phishing attacks, malware distribution, or man-in-the-middle attacks.
DNS Hijacking: Attackers gain control of DNS settings, either by compromising a router, modifying system settings, or taking over a domain registrar account. This allows them to redirect all traffic for a domain to servers they control.
DDoS Attacks: Distributed Denial of Service attacks can overwhelm DNS servers with massive query volumes, making domains unreachable. DNS amplification attacks exploit open resolvers to multiply attack traffic.
DNS Tunneling: Malicious actors encode data within DNS queries and responses to exfiltrate information or establish command-and-control channels, bypassing firewall restrictions.
Domain Generation Algorithms (DGA): Malware uses algorithms to generate thousands of domain names, making it difficult to block command-and-control servers through DNS filtering.
DNSSEC: Cryptographic Protection
DNS Security Extensions (DNSSEC) add cryptographic signatures to DNS records, allowing resolvers to verify that responses haven't been tampered with. DNSSEC creates a chain of trust from the root zone down to individual domains.
When DNSSEC is enabled, each DNS zone signs its records with a private key. Resolvers can verify these signatures using public keys published in the parent zone. If verification fails, the resolver rejects the response as potentially malicious.
However, DNSSEC adoption remains limited due to complexity in implementation and management. As of 2026, only about 30% of top-level domains have DNSSEC fully deployed.
DNS over HTTPS (DoH) and DNS over TLS (DoT)
Traditional DNS queries are sent in plaintext, allowing ISPs, network administrators, and attackers to see which domains you're accessing. DoH and DoT encrypt DNS traffic to protect privacy.
DNS over TLS (DoT) encrypts DNS queries using the TLS protocol on port 853. It's designed to be easily identifiable and can be blocked by network administrators if needed.
DNS over HTTPS (DoH) tunnels DNS queries through HTTPS connections on port 443, making them indistinguishable from regular web traffic. This provides stronger privacy but can complicate network management and security monitoring.
Major browsers like Firefox and Chrome now support DoH, and you can configure them to use encrypted DNS providers like Cloudflare (1.1.1.1) or Google (8.8.8.8).
Best Practices for DNS Security
- Use reputable DNS providers: Public DNS services like Cloudflare, Google, and Quad9 offer better security than many ISP resolvers
- Enable DNSSEC validation: Configure your resolver to validate DNSSEC signatures when available
- Implement DNS filtering: Block known malicious domains at the DNS level to prevent connections to phishing sites and malware servers
- Monitor DNS traffic: Watch for unusual query patterns that might indicate DNS tunneling or DGA activity
- Secure your domain registrar account: Use strong passwords and two-factor authentication to prevent account takeover
- Regular audits: Periodically review your DNS records for unauthorized changes
- Rate limiting: Configure DNS servers to limit query rates and prevent amplification attacks
| DNS Provider | Primary IP | Secondary IP | Features |
|---|---|---|---|
| Cloudflare | 1.1.1.1 |
1.0.0.1 |
Fast, privacy-focused, DoH/DoT support |
| Google Public DNS | 8.8.8.8 |
8.8.4.4 |
Reliable, DNSSEC validation, DoH/DoT |
| Quad9 | 9.9.9.9 |
149.112.112.112 |
Security-focused, blocks malicious domains |
| OpenDNS | 208.67.222.222 |
208.67.220.220 |
Content filtering, phishing protection |
Common DNS Issues and Solutions
DNS problems can manifest in various ways, from complete inability to access websites to intermittent connectivity issues. Here's how to diagnose and resolve the most common DNS problems.
DNS Server Not Responding
Symptoms: Browsers display "DNS server not responding" or "DNS_PROBE_FINISHED_NXDOMAIN" errors. You can't access any websites by domain name, but IP addresses might still work.
Causes and Solutions:
- Router or modem issues: Restart your router and modem. Unplug them for 30 seconds, then plug them back in and wait for full startup.
- ISP DNS problems: Switch to public DNS servers like Cloudflare (1.1.1.1) or Google (8.8.8.8) in your network settings.
- Firewall blocking: Check if your firewall is blocking DNS traffic on port 53. Temporarily disable the firewall to test.
- Network adapter issues: Reset your network adapter or update its drivers.
DNS Propagation Delays
Symptoms: You've changed DNS records, but some users still see the old configuration while others see the new one. Different DNS lookup tools show different results.
Causes and Solutions:
- TTL not expired: Wait for the old record's TTL to expire. Check the TTL value using
digor our DNS