11 min to read
Understanding DNS - How Domain Name System Works
A comprehensive guide to DNS architecture, types of DNS servers, and record types

Overview
Let’s explore how DNS (Domain Name System) works, from basic concepts to detailed operations.
Introduction to DNS
DNS (Domain Name System) is the internet’s phonebook, translating human-friendly domain names (like www.example.com) into machine-readable IP addresses (like 192.0.2.1) that computers use to identify each other on the network. This translation is essential because humans find it easier to remember domain names than strings of numbers.
Working Process
- User accesses website (www.a.com)
- Computer checks local DNS cache
- If not in cache, DNS query begins
- Root DNS server IP address is obtained
- Query sent to Root DNS for TLD server address
- Query sent to TLD DNS for Authoritative DNS server address
- Query sent to Authoritative DNS for IP address
- IP address cached and returned to browser
What is DNS?
DNS (Domain Name System) is a system that converts human-readable domain names into IP addresses used by computers on the internet.
DNS Resolution Process in Detail
- Browser Request: User types www.example.com in browser
- OS Check: Operating system checks local hosts file (/etc/hosts on Linux/Mac, C:/Windows/System32/drivers/etc/hosts on Windows)
- Local DNS Cache Check: OS checks its DNS cache (TTL determines how long entries remain)
- Recursive DNS Query: OS sends query to configured DNS resolver (typically ISP DNS or public DNS like 8.8.8.8)
- Root Nameserver Query: If resolver doesn't have record cached, it queries root nameservers (.)
- TLD Nameserver Query: Root server refers resolver to TLD nameserver (.com, .org, etc.)
- Authoritative Nameserver Query: TLD nameserver refers resolver to domain's authoritative nameserver
- Final Resolution: Authoritative nameserver provides the actual IP address
- Response Return: IP address returns through the chain to the requesting device
- Caching: DNS resolver caches the result to speed up future requests
- Recursive Query: Client requests DNS server to respond with requested record or error if record doesn't exist
- Iterative Query: Client allows DNS server to return best answer it has; if server doesn't know answer, it returns referral to another server
- Non-recursive Query: Server responds only if it has authority for domain name or has record cached
-
Root DNS Server
- Most critical DNS server in internet infrastructure
- Globally distributed
- Manages root domain names (.)
- Maintained by ICANN
- Provides TLD DNS server information
- Only 13 logical root nameserver sets (A through M) but hundreds of physical servers worldwide -
TLD (Top-Level Domain) DNS Server
- Manages top-level domains (.com, .org, .edu)
- Processes DNS queries for TLD domains
- Works with domain registrars
- Maintained by ICANN
- Directs to Authoritative DNS servers
- Types include gTLD (.com, .org) and ccTLD (.uk, .jp) -
Second-Level DNS Server (Authoritative)
- Typically hosting provider's nameserver
- Contains actual domain-IP mappings
- Final authority for domain information
- Manages specific domain records
- Can be managed by domain owner or hosting provider -
Other DNS Server Types
Recursive DNS Server: Performs complete DNS queries and contacts other servers as needed.
Caching DNS Server: Stores previous query results, improves query performance, and can be cleared (e.g., ipconfig/flushdns).
Forwarding DNS Server: Forwards queries to other servers and can cache results.
Secondary DNS Server: Replicates primary DNS data and provides redundancy.
📊 DNS Working Process Flowchart
📝 DNS Record Types
Common DNS Records
Record Type | Purpose | Example |
---|---|---|
A | Maps domain to IPv4 address | example.com. IN A 192.0.2.1 |
AAAA | Maps domain to IPv6 address | example.com. IN AAAA 2001:db8::1 |
CNAME | Creates domain alias pointing to another domain | www.example.com. IN CNAME example.com. |
MX | Specifies mail servers and priority | example.com. IN MX 10 mail.example.com. |
NS | Identifies authoritative nameservers | example.com. IN NS ns1.example.com. |
TXT | Stores text information (often for verification) | example.com. IN TXT "v=spf1 include:_spf.example.com ~all" |
SOA | Provides authoritative information about zone | example.com. IN SOA ns1.example.com. admin.example.com. (
2023010101 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
86400 ) ; minimum TTL |
PTR | Maps IP to domain (reverse DNS) | 1.2.0.192.in-addr.arpa. IN PTR example.com. |
SRV | Specifies service location | _sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com. |
CAA | Specifies which CA can issue certificates | example.com. IN CAA 0 issue "letsencrypt.org" |
A Record: Domain name → IPv4 address
CNAME: Domain alias → Another domain
MX: Mail server priority
NS: Authoritative nameserver
TXT: Text information
SPF: Email sender verification
SRV: Service location
AAAA: Domain name → IPv6 address
SOA: Zone authority information
PTR: IP address → Domain name (reverse DNS)
Advanced DNS Records
NSID: Nameserver identifier
DNSKEY: DNSSEC public key
CAA: Certificate Authority Authorization
TLSA: TLS certificate association
SSHFP: SSH public key fingerprint
DNAME: Domain redirection
NAPTR: Naming Authority Pointer
DNS Security (DNSSEC)
Domain Name System Security Extensions (DNSSEC) adds cryptographic signatures to DNS records to verify their authenticity, protecting against DNS spoofing and cache poisoning attacks.
How DNSSEC Works:
- Chain of Trust: Creates a hierarchical chain of trust from root zone down to individual domains
- Digital Signatures: DNS records are cryptographically signed using public key cryptography
- Record Validation: DNS resolvers verify signatures to ensure records haven't been tampered with
Key DNSSEC Record Types:
- DNSKEY: Contains public keys used to verify DNSSEC signatures
- RRSIG: Contains digital signatures for DNS record sets
- DS: Delegation Signer, links to the DNSKEY record of a delegated zone
- NSEC/NSEC3: Provides authenticated denial of existence
Implementation Considerations:
- Must be implemented at every level (domains, TLDs, resolvers)
- Requires regular key rotation for security
- Increases DNS record sizes and processing requirements
Configuration Examples
TinyDNS Record Format
. SOA, NS, A
& NS, A
@ MX, A
= PTR, A
+ A
' TXT
^ PTR
C CNAME
Z SOA
% Client location condition
# Comment
- Disable A record
: Custom
6 AAAA, PTR
3 AAAA
BIND forwarding zone example
$TTL 1D
@ IN SOA ns.somaz.com. root.somaz.com. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns.somaz.com.
IN A 172.17.5.10
ns IN A 172.17.5.10
www IN A 172.17.5.10
BIND reverse zone example
$TTL 1D
@ IN SOA ns.somaz.com. root.somaz.com. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns.somaz.com.
IN A 172.17.5.10
10 IN PTR ns.somaz.com.
10 IN PTR www.somaz.com.
Practical DNS Configuration Examples
DNS Load Balancing with Multiple A Records
example.com. IN A 192.0.2.1
example.com. IN A 192.0.2.2
example.com. IN A 192.0.2.3
GeoDNS Configuration (PowerDNS with GeoIP)
-- PowerDNS Lua script for GeoDNS
function geoip(dq)
local country = dq.remoteaddr:toString():geoip('country')
if country == 'US' then
return {
{qtype=pdns.A, content='192.0.2.1', ttl=300}
}
elseif country == 'EU' then
return {
{qtype=pdns.A, content='192.0.2.2', ttl=300}
}
else
return {
{qtype=pdns.A, content='192.0.2.3', ttl=300}
}
end
end
AWS Route 53 Weighted Round Robin Example (JSON)
{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"SetIdentifier": "Server 1",
"Weight": 70,
"TTL": 300,
"ResourceRecords": [
{
"Value": "192.0.2.1"
}
]
}
},
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com",
"Type": "A",
"SetIdentifier": "Server 2",
"Weight": 30,
"TTL": 300,
"ResourceRecords": [
{
"Value": "192.0.2.2"
}
]
}
}
]
}
DNS Troubleshooting Guide
Issue | Diagnosis | Solution |
---|---|---|
Domain not resolving | dig example.com or nslookup example.com |
- Check if NS records are correctly set - Verify domain is registered - Ensure authoritative nameservers are responding |
DNS propagation delay | Different results from different DNS servers | - Wait for TTL to expire (can take 24-48 hours) - Lower TTL values before making changes |
Cache poisoning | Unexpected DNS results, security alerts | - Implement DNSSEC - Flush DNS cache - Update DNS software |
Email delivery issues | dig MX example.com |
- Verify MX records are correct - Check for SPF, DKIM, and DMARC records |
Reverse DNS failures | dig -x 192.0.2.1 |
- Set up proper PTR records - Contact ISP if IP allocation requires their configuration |
NXDOMAIN errors | Domain doesn't exist response | - Check for typos in domain name - Verify zone file configuration - Check if domain has expired |
# Check A records dig example.com A # Check MX records dig example.com MX # Trace full DNS resolution path dig +trace example.com # Query specific nameserver dig @8.8.8.8 example.com # Check DNS zone transfer (if allowed) dig axfr example.com @ns1.example.com # Check reverse DNS dig -x 192.0.2.1 # View full response with timing details dig +stats example.com # Check DNSSEC validation dig +dnssec example.com # DNS lookup on Windows nslookup example.com # Flush DNS cache on Windows ipconfig /flushdns # Flush DNS cache on macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Flush DNS cache on Linux (systemd) sudo systemd-resolve --flush-caches
DNS Best Practices
- Multiple Nameservers: Implement at least two nameservers in different locations/networks
- TTL Strategy: Use lower TTLs (300-900s) for frequently changing records, higher TTLs (86400s) for stable records
- Security: Implement DNSSEC, restrict zone transfers, keep DNS software updated
- Monitoring: Set up monitoring for DNS resolution and expiration dates
- Performance: Use anycast DNS for global distribution, consider DNS-based load balancing
- Documentation: Maintain comprehensive documentation of DNS architecture and record changes
- SPF, DKIM, DMARC: Implement email authentication to prevent spoofing
- CAA Records: Control which CAs can issue certificates for your domains
- Change Management: Lower TTLs before making significant DNS changes
- Redundancy: Use multiple DNS providers for critical domains
Comments