DNS and Domain Management: A Complete Guide to Domain Name System

Every time you type a URL, DNS translates that human-readable name into an IP address. Without DNS, you would have to memorize IP addresses for every website. Understanding how DNS works helps you debug connectivity issues, configure services correctly, and appreciate the infrastructure that makes the web usable.

The TCP/IP & UDP post covers the transport layer that DNS runs on. This post focuses on the domain name system itself.

---

What is DNS?

DNS (Domain Name System) is a hierarchical, distributed database that maps domain names to IP addresses. It works like a phone book for the internet.

When you visit example.com, your browser asks DNS for the IP address of example.com. DNS responds with something like 93.184.216.34. Your browser then connects to that IP address.

graph LR
    A[Browser] -->|"example.com"| B[Local DNS<br/>Resolver]
    B -->|"Recursion"| C[Root DNS<br/>Server]
    C --> D[.com TLD<br/>Server]
    D --> E[example.com<br/>Authoritative<br/>Server]
    E -->|"93.184.216.34"| B
    B -->|"93.184.216.34"| A

DNS is hierarchical and distributed. No single server contains all domain mappings. Instead, the workload is spread across millions of servers worldwide.

---

DNS Hierarchy

The DNS hierarchy has several levels:

Root Zone

The root zone sits at the top. It contains records for all TLDs (Top-Level Domains). There are 13 logical root servers, labeled A through M, operated by different organizations.

The root zone file is tiny, just a few kilobytes, but it is critically important. Without it, no one would know where to find .com or .org servers.

TLD Servers

TLD servers manage the second level. They handle domains like .com, .org, .net, and country-code TLDs like .uk, .de, .jp.

VeriSign manages .com and .net TLD servers. Other organizations manage other TLDs.

Authoritative DNS Servers

Authoritative servers hold the actual DNS records for a domain. When you registered example.com, you configured the authoritative server for that domain at your registrar.

Your authoritative server is the source of truth for your domain. If it returns the wrong IP, your website breaks.

Recursive Resolvers

Recursive resolvers are not part of the hierarchy. They are typically provided by your ISP or network administrator. When you ask your router for example.com, it forwards the request to your ISP’s recursive resolver.

The recursive resolver does the heavy lifting. It queries the hierarchy on your behalf, caches the results, and returns the final answer.

---

DNS Resolution Process

When you visit a website, DNS resolution happens in milliseconds. Here is what actually occurs:

1. Browser checks its own cache
2. If not found, the OS resolver checks its cache
3. If not found, your configured resolver (usually ISP) handles it
4. Resolver asks a root server for the TLD
5. Resolver asks the TLD server for the authoritative server
6. Resolver asks for the actual A record
7. The IP address flows back to your browser

sequenceDiagram
    participant Browser
    participant OS
    participant Resolver
    participant Root
    participant TLD
    participant Auth

    Browser->>OS: example.com
    OS->>Resolver: example.com
    Resolver->>Root: Where is .com?
    Root->>Resolver: Ask TLD server X
    Resolver->>TLD: Where is example.com?
    TLD->>Resolver: Ask auth server Y
    Resolver->>Auth: Where is example.com?
    Auth->>Resolver: 93.184.216.34
    Resolver->>OS: 93.184.216.34
    OS->>Browser: 93.184.216.34

Most of this happens in milliseconds. Caching at each level speeds up subsequent requests.

---

DNS Record Types

DNS records come in several types. Each serves a different purpose.

A Records

A records map a domain name to an IPv4 address. This is the most common record type.

# Example A record
example.com.    IN A     93.184.216.34

AAAA Records

AAAA records map a domain name to an IPv6 address. They work like A records but for the newer IP format.

# Example AAAA record
example.com.    IN AAAA  2606:2800:220:1::247a:28c5

CNAME Records

CNAME records create an alias from one domain to another. The DNS lookup follows the chain until it reaches an A or AAAA record.

# www.example.com points to example.com
www.example.com.    IN CNAME  example.com.
example.com.        IN A      93.184.216.34

When you look up www.example.com, DNS first finds the CNAME, then looks up example.com, then finds the A record.

CNAMEs cannot coexist with other records at the same name. You cannot have both an A record and a CNAME for www.example.com.

MX Records

MX records specify mail servers for a domain. They have a priority value; lower numbers get tried first.

# Example MX records
example.com.    IN MX   10 mail1.example.com.
example.com.    IN MX   20 mail2.example.com.

If mail1.example.com is unavailable, mail delivery attempts mail2.example.com.

TXT Records

TXT records hold arbitrary text. They are used for verification, spam prevention, and other purposes.

# SPF record for email validation
example.com.    IN TXT   "v=spf1 include:_spf.example.com ~all"

# Google workspace verification
example.com.    IN TXT   "google-site-verification=abc123..."

NS Records

NS records delegate a zone to a specific nameserver. They tell the world which servers are authoritative for your domain.

# Nameservers for example.com
example.com.    IN NS    ns1.example.com.
example.com.    IN NS    ns2.example.com.

SOA Records

SOA (Start of Authority) records contain administrative information about a zone. They are created automatically when you set up a domain.

# Example SOA record
example.com.    IN SOA   ns1.example.com. admin.example.com. (
                2024010101 ; Serial
                7200       ; Refresh
                3600       ; Retry
                1209600    ; Expire
                86400 )    ; Minimum TTL

---

TTL (Time To Live)

TTL tells resolvers how long to cache a record before requesting it again. It is specified in seconds.

# This record can be cached for 1 hour
example.com.    IN A     93.184.216.34
                IN TTL   3600

Lower TTL means more frequent lookups but faster propagation when you change records. Higher TTL means better performance but slower changes.

When preparing for a major change, reduce TTLs 24-48 hours in advance. Then make your change. After propagation, raise TTLs again.

Typical TTL Values

Record Type	Common TTL	Notes
A, AAAA	3600 (1 hour)	Standard for most records
MX	3600-7200	Mail servers change less often
CNAME	3600-86400	Aliases are stable
NS	86400-172800	Delegate changes are rare
After changes	300 or less	Temporary low TTL during migration

---

DNS Propagation

Changes to DNS records do not take effect instantly. Propagation takes time based on TTL values and resolver behavior.

Some resolvers ignore TTL and cache for their own duration. This is why DNS changes can take up to 48 hours to fully propagate, even though most changes are visible within minutes.

Realistically, most users see your changes within 5-15 minutes. Corporate networks with their own resolvers may take longer.

---

Subdomains

Subdomains extend your domain to create separate namespaces. blog.example.com and shop.example.com are subdomains of example.com.

Subdomains are configured the same way as the main domain. You create A, AAAA, or CNAME records for them:

# Subdomain A records
blog.example.com.    IN A      192.0.2.10
shop.example.com.     IN A      192.0.2.20
api.example.com.      IN A      192.0.2.30

Each subdomain can point to different servers. You can also delegate subdomains to different DNS providers if needed.

---

DNSSEC

DNSSEC adds cryptographic signatures to DNS records. It helps prevent DNS spoofing and cache poisoning attacks.

When you query a DNSSEC-signed domain, the response includes signatures that your resolver can verify. If the signatures do not match, the resolver rejects the response.

# DNSSEC-related records
example.com.    IN DNSKEY  256 3 13 (base64...)
example.com.    IN RRSIG   DNSKEY 13 2 7200 (base64...)

Enabling DNSSEC requires support from your registrar and DNS provider. Not all providers offer it.

---

Common DNS Issues

DNS Cache Poisoning

Attackers can inject fake DNS records into resolver caches. This redirects users to malicious servers. DNSSEC helps prevent this.

Long TTL Problems

If your TTL is set to 86400 (24 hours) and you need to change servers, users may be routed to the old server for up to 24 hours after your change.

Missing or Wrong MX Records

If your MX records point to a server that is not configured to receive mail, emails get lost. Always test mail configuration after changes.

CNAME Chain Issues

Long CNAME chains slow down resolution and create more points of failure. Keep chains short.

---

Best Practices

1. Set reasonable TTLs - 3600 is a good default for most records
2. Reduce TTLs before changes - Lower them 24-48 hours before planned maintenance
3. Use multiple nameservers - Most registrars require at least two
4. Monitor DNS actively - Use tools to verify your records are correct
5. Consider DNSSEC if security is a priority
6. Document your DNS configuration - A chart prevents confusion later

---

When to Use DNS Features

DNS is essential when:

• You need human-readable addresses for services (websites, APIs, email)
• You run services across multiple geographic regions (geoDNS)
• You need high availability with multiple server IPs (round robin DNS)
• You want to redirect traffic between service versions (canary deployments)
• You need email delivery verification (SPF, DKIM, DMARC)

When Not to Rely Solely on DNS

DNS alone is not enough when:

• You need instant failover (DNS TTLs cause delays; use load balancers)
• You need real-time load distribution (DNS cannot sense server load)
• You require sticky sessions (DNS distributes evenly, not by session)
• You need SSL certificates for many subdomains (use wildcard certificates)
• Your service IPs change frequently (DNS propagation takes time)

---

Production Failure Scenarios

Failure	Impact	Mitigation
Authoritative DNS server down	Domain resolves to nothing; complete outage	Use multiple nameservers from different providers; monitor NS availability
Incorrect A/AAAA record	Traffic routes to wrong IP or none	Validate records after changes; implement rollback plan
TTL too high	Slow recovery after changes; extended outage	Set reasonable TTLs (3600 default); reduce before planned changes
DNSSEC misconfiguration	Domain becomes unreachable	Test DNSSEC before enabling; monitor validation failures
MX record points to dead mail server	Email delivery failures	Monitor mail server health; implement backup MX
CNAME at zone apex	Breaks email, DNSSEC, and some resolvers	Use A records at zone apex; CNAME only for subdomains
Cache poisoning attack	Users redirected to malicious servers	Enable DNSSEC; use secure resolvers; monitor for anomalies
Registrar account compromised	Attacker changes nameservers; domain stolen	Enable registrar lock; use 2FA; monitor WHOIS changes

---

Observability Checklist

Metrics

• DNS query volume by record type (A, AAAA, CNAME, MX, TXT)
• Query latency from recursive resolvers
• NXDOMAIN rate (queries for non-existent domains)
• Resolution failure rate
• DNSSEC validation success/failure ratio
• Geographic distribution of queries

Logs

• All zone transfer attempts (AXFR/IXFR)
• Dynamic update requests (nsupdate)
• Changes to DNS records with timestamp and source
• Recursive resolver queries and responses
• DNSSEC validation failures
• Suspicious query patterns (potential DNS tunneling)

Alerts

• Authoritative server unreachable for more than 60 seconds
• Unusual spike in NXDOMAIN responses
• DNSSEC validation failures increase
• Unauthorized zone transfer attempts
• DNS record changes outside maintenance windows
• Serial number changes without planned updates

---

Security Checklist

• Enable DNSSEC to prevent spoofing and cache poisoning
• Use long, random TSIG keys for zone transfers
• Restrict zone transfers to authorized secondary servers only
• Enable registrar lock to prevent unauthorized transfer
• Use 2FA on registrar and DNS provider accounts
• Monitor WHOIS changes for your domain
• Implement SPF, DKIM, and DMARC for email domain protection
• Remove unnecessary records (old IPs, unused subdomains)
• Limit TXT record size to prevent fragmentation issues
• Audit NS records to ensure only authorized servers
• Consider using a reputable recursive resolver with security features
• Log and monitor DNS queries for anomalous patterns

---

Common Pitfalls / Anti-Patterns

Setting TTLs Too High

High TTLs mean slow recovery when you need to change records.

# Problem: 86400 (24 hours) TTL means 24 hour recovery time
example.com.  IN A  192.0.2.10
               IN TTL 86400

# Better: 300 seconds for dynamic records
example.com.  IN A  192.0.2.10
               IN TTL 300

CNAME at Zone Apex

You cannot have a CNAME record at the same name as other records.

# WRONG - CNAME at apex conflicts with SOA and NS
example.com.  IN CNAME  other.example.com.
example.com.  IN A      192.0.2.10

# CORRECT - CNAME only for subdomains
www.example.com.  IN CNAME  other.example.com.
example.com.      IN A      192.0.2.10

Not Having Backup Nameservers

Single nameserver is a single point of failure.

# Minimum: two nameservers from different providers
example.com.  IN NS  ns1.provider-a.com.
example.com.  IN NS  ns2.provider-b.com.

Ignoring MX Priority

MX records have priority values. Lower numbers have higher priority.

# Wrong: Higher number first means lower priority tried first
example.com.  IN MX  20 mail.example.com.
example.com.  IN MX  10 mail.example.com.

# Correct: Lower priority number first
example.com.  IN MX  10 mail.example.com.
example.com.  IN MX  20 mail-backup.example.com.

Long CNAME Chains

Multiple CNAME hops slow resolution and create fragility.

# Problem: Chain of 3 lookups
www.example.com.  IN CNAME  cdn.example.com.
cdn.example.com.  IN CNAME  cloudfront.net.
cloudfront.net.   IN A       54.230.1.1

# Better: Direct CNAME or A record
www.example.com.  IN CNAME  mysite.cloudfront.net.

---

Quick Recap

Key Bullets

• DNS maps domain names to IP addresses through a hierarchical distributed database
• A records map to IPv4; AAAA records map to IPv6
• CNAME records create aliases but cannot coexist with other records at the same name
• MX records specify mail servers with priority (lower number = higher priority)
• TXT records support verification, SPF email validation, and domain ownership
• NS records delegate zones to specific nameservers
• TTL controls caching duration; reduce before planned changes
• DNS propagation depends on TTL but may take up to 48 hours
• DNSSEC adds cryptographic signatures to prevent spoofing

Copy/Paste Checklist

# Check DNS records with dig
dig example.com A +short
dig example.com MX +short
dig example.com TXT +short

# Check propagation from multiple resolvers
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

# Check DNSSEC validation
dig +dnssec example.com A

# Check WHOIS information
whois example.com

# Test SPF record
nslookup -type=TXT example.com

# Verify certificate with openssl
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | openssl x509 -noout -dates

---

Conclusion

DNS is the backbone of web navigation. Understanding record types, TTL behavior, and resolution processes helps you manage domains effectively and debug issues when they arise.

Key takeaways: DNS maps names to IPs through a hierarchical system. A and AAAA records point to servers. CNAMEs alias to other names. MX records handle mail. TTL controls caching duration. Changes propagate based on TTL values but may take longer due to resolver behavior.

For how this data travels across networks, see the TCP/IP & UDP post. For securing DNS with TLS, see the SSL/TLS & HTTPS post.