DNS and Domain Management: The Complete Guide

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.

---

Introduction

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 Fundamentals

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.

---

Advanced DNS & Security

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)

---

Topic-Specific Deep Dives

DNS Zone Transfer Deep Dive

Zone transfers let secondary nameservers copy zone data from primary servers. This is how you get redundancy across multiple machines—and how you expose your entire DNS landscape if you get it wrong.

AXFR vs IXFR

AXFR (Full Zone Transfer) copies the entire zone file. It works, but it is wasteful for large zones.

IXFR (Incremental Zone Transfer) sends only records that changed. The secondary server tracks the SOA serial and recent changes to figure out what is different.

# Force AXFR from primary
dig @ns1.example.com example.com AXFR

# IXFR with current serial
dig @ns1.example.com example.com IXFR=2024010101

Most DNS providers prefer IXFR to cut down on bandwidth.

TSIG keys

TSIG (Transaction Signature) authenticates zone transfers using shared keys. Without TSIG, anyone can request a zone transfer and see your entire DNS landscape.

# Example TSIG key configuration (BIND)
key "transfer-key" {
    algorithm hmac-sha256;
    secret "base64-encoded-secret==";
};

server ns2.example.com {
    keys { transfer-key; };
};

Use long, random keys (at least 256 bits). Rotate keys regularly and after any potential compromise.

Best practices for zone transfers

• Always use TSIG authentication
• Restrict AXFR/IXFR to authorized secondary servers only
• Monitor for unauthorized transfer attempts
• Consider using VPN or encrypted tunnels between primary and secondary
• Test zone transfer functionality during drills

Zone transfer takeaways

• IXFR is preferred over AXFR for efficiency
• TSIG authentication is mandatory for production zones
• Restrict zone transfers to known IP addresses
• Monitor for unauthorized transfer attempts

---

Split-Horizon DNS Guide

Split-horizon DNS returns different records depending on who asks—internal clients get private IPs, external clients get public IPs.

Why split-horizon?

Corporate networks use private IP ranges (10.x.x.x, 192.168.x.x). If internal users query the same DNS as external users, they get public IPs that are unreachable from inside the network.

Split-horizon fixes this by matching the response to the requester’s network.

Implementation approaches

View-based DNS (BIND)

# BIND split-horizon configuration
view "internal" {
    match-clients { 10.0.0.0/8; 192.168.0.0/16; };
    zone "example.com" {
        type master;
        file "internal/example.com.zone";
    };
};

view "external" {
    match-clients { any; };
    zone "example.com" {
        type master;
        file "external/example.com.zone";
    };
};

Forwarding to Internal Resolvers

# Internal resolver handles private ranges
# External resolver handles public queries
options {
    forwarders { 10.0.0.53; };
    forward only;
};

Split-horizon vs VPC DNS

AWS VPC has its own DNS resolution for private hosted zones, so you do not need separate views for *.compute.internal queries.

# Route53 private hosted zone
aws route53 create-hosted-zone \
    --name example.internal \
    --vpc VPCId=vpc-123456 \
    --caller-reference $(date +%s)

Split-horizon takeaways

• Use split-horizon when internal and external clients need different answers
• BIND views or forwarding resolvers are common implementations
• VPC private hosted zones simplify AWS environments
• Ensure consistency between internal and external records

---

DNS Query Types and Filters

Resolvers and nameservers use more than just A and AAAA queries. Flags and extended options control how queries work.

Recursion vs iteration

Recursive queries ask the resolver to do all the chasing—follow referrals until it has the final answer.

Iterative queries ask each nameserver to return only what it knows and point the client to the next server.

# Recursive query (default for clients)
dig @8.8.8.8 example.com A +recurse

# Iterative query (nslookup uses this)
dig @a.root-servers.net example.com A +iter

EDNS0 (extension mechanisms for DNS)

EDNS0 adds optional extensions to DNS packets, including larger packet sizes and additional flags.

# Request large UDP packet size
dig @8.8.8.8 example.com A +edns=0

# View EDNS options in response
dig @8.8.8.8 example.com A +ednsopt

DNSSEC flags

DNSSEC responses include validation status flags:

Flag	Meaning
AD (Authenticated Data)	Response is cryptographically validated
CD (Checking Disabled)	Resolver should not validate
DO (DNSSEC OK)	Client wants DNSSEC records in response

# Request DNSSEC records with DO flag
dig @8.8.8.8 example.com A +dnssec

# Check AD flag in response
dig @8.8.8.8 example.com A +ad

DNS flags

# QR (Query/Response) - 1 bit
# OPCODE (Operation Code) - 4 bits (0=Query, 1=IQuery, 2=Status)
# AA (Authoritative Answer) - 1 bit
# TC (Truncation) - 1 bit
# RD (Recursion Desired) - 1 bit
# RA (Recursion Available) - 1 bit

# View all flags
dig @8.8.8.8 example.com A +qr +aa +tc +rd +ra

Query type takeaways

• Recursive queries simplify client logic; iterative queries reduce resolver load
• EDNS0 enables larger UDP packets and additional metadata
• DNSSEC flags (AD, CD, DO) control validation behavior
• Use +dnssec flag to request DNSSEC records explicitly

---

DNS Anycast and GeoDNS

Anycast routes queries to the nearest server that announces the same IP prefix. GeoDNS uses geographic information to give location-specific answers.

Anycast DNS

With Anycast, multiple nameservers in different locations announce the same IP prefix via BGP. Traffic automatically routes to the nearest hop.

graph LR
    A[Client<br/>Tokyo] -->|"Route to<br/>nearest"| B[Tokyo<br/>PoP<br/>203.0.113.1]
    C[Client<br/>Frankfurt] -->|"Route to<br/>nearest"| D[Frankfurt<br/>PoP<br/>203.0.113.1]
    B --> E[(Primary<br/>DNS)]
    D --> E

Major DNS providers (Cloudflare, AWS Route53, Google Cloud DNS) operate Anycast networks globally.

GeoDNS (geographic routing)

GeoDNS returns different answers based on the resolver’s location. Common uses:

• CDN integration: point users to the nearest edge server
• Regional failover: shift traffic away from degraded regions
• Compliance: keep data in specific jurisdictions

# Route53 geolocation routing example
aws route53 change-resource-record-sets \
    --hosted-zone-id ZONEID \
    --change-batch '{
        "Changes": [{
            "Action": "CREATE",
            "ResourceRecordSet": {
                "Name": "api.example.com",
                "Type": "A",
                "GeoLocation": {"CountryCode": "US"},
                "SetIdentifier": "us-east-1",
                "AliasTarget": {
                    "DNSName": "dualstack.api-elb.us-east-1.elb.amazonaws.com.",
                    "HostedZoneId": "Z3XXX",
                    "EvaluateTargetHealth": true
                }
            }
        }]
    }'

Latency-based routing

Route53 latency-based routing measures actual latency between users and AWS regions.

# Latency record set
{
    "Name": "api.example.com",
    "Type": "A",
    "SetIdentifier": "us-east-1",
    "Region": "us-east-1",
    "AliasTarget": {
        "DNSName": "api-elb.us-east-1.elb.amazonaws.com.",
        "HostedZoneId": "Z3XXX",
        "EvaluateTargetHealth": true
    }
}

Anycast and GeoDNS takeaways

• Anycast provides built-in redundancy and low latency
• GeoDNS enables location-specific routing for CDNs and compliance
• Latency-based routing selects the fastest AWS region per user
• Combine Anycast with health checks for automatic failover

---

Trade-off Analysis

Factor	Self-Hosted	Cloud Provider	Third-Party Managed	Recommendation
Cost	Low upfront, high ops	Pay-per-query	Subscription	Depends on scale
Control	Full control	Moderate	Limited	Enterprise needs
Maintenance	High (you own it)	Low	Very low	Small teams
Scalability	Manual	Auto	Auto	Auto
SLA	Your responsibility	Provider SLA	Provider SLA	Provider SLA

DNS Provider Trade-offs

Provider	Free Tier	DNSSEC	GeoDNS	Anycast	API Access	Best For
Cloudflare	Yes	Yes	Yes	Yes	Yes	Performance-first websites
AWS Route53	No	Yes	Yes	Yes	Yes	AWS environments
Google Cloud DNS	Yes (1M queries/mo)	Yes	Yes	Yes	Yes	GCP environments, low cost
Azure DNS	No	Yes	Yes	Yes	Yes	Azure environments
GoDaddy	No	Yes	Limited	No	Yes	Simple registrar with DNS
NS1	Limited	Yes	Yes	Yes	Yes	Enterprise with complex routing
Quad9	Yes	Yes	No	Yes	Limited	Security-first (blocks malware)

Choosing a DNS Provider

Pick Cloudflare for performance and DDoS protection. Route53 if you live in AWS. Quad9 if you want to block malware domains at the DNS level. NS1 for complex enterprise routing needs.

---

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

---

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.

---

Interview Questions

---

Further Reading

RFCs and Standards

• RFC 1034 - Domain Names - Concepts and Facilities
• RFC 1035 - Domain Names - Implementation and Specification
• RFC 2308 - Negative Caching of DNS Queries (NXDOMAIN)
• RFC 4033 - DNS Security Introduction and Requirements (DNSSEC)
• RFC 5155 - DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• RFC 8484 - DNS over HTTPS (DoH)

Tools and References

• DNS Propagation Checker - Verify DNS records across global resolvers
• IntoDNS - DNS report and analysis tool
• ViewDNS.info - Multiple DNS lookup and investigation tools
• DNSviz - DNSSEC analysis and visualization
• Cloudflare DNS - Fast public DNS resolver (1.1.1.1)
• Quad9 DNS - Security-focused public DNS (blocks malware)

Related Posts

• TCP/IP & UDP - Transport layer protocols DNS uses
• SSL/TLS & HTTPS - Secure communications and certificate validation
• Load Balancing Strategies - Complementary to DNS-based routing
• CDN Configuration - Leveraging DNS for content delivery

---

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.