Understanding DNS: From Domain to IP

Introduction

Every time you type a URL into your browser, send an API request, or load an image from a CDN, there's an invisible system working behind the scenes to translate human-readable domain names into machine-readable IP addresses. That system is the Domain Name System (DNS), and it's one of the most critical pieces of internet infrastructure. Without DNS, you'd need to memorize the IP address of every website you visit — imagine typing 142.250.80.46 instead of google.com.

Despite its critical importance, many developers treat DNS as a black box. This guide will change that. We'll explore how DNS resolution works step by step, examine every major DNS record type, understand caching and TTL, and learn how to optimize DNS for performance and reliability. Whether you're deploying a simple website or managing infrastructure for millions of users, understanding DNS is essential.

Understanding DNS: Core Concepts

DNS is a hierarchical, distributed naming system that translates domain names to IP addresses. It was invented in 1983 by Paul Mockapetris, replacing the original system where a single file (HOSTS.TXT) maintained a mapping of all hostnames to IP addresses. Today, DNS handles billions of queries per day across millions of servers worldwide.

The DNS Hierarchy

The DNS hierarchy is a tree structure with the root zone at the top. Below the root are the top-level domains (TLDs) like .com, .org, .net, .io, and country-code TLDs like .uk, .de, .jp. Below the TLDs are second-level domains (like example.com), and below those are subdomains (like api.example.com or www.example.com).

. (root)
├── com.
│   ├── google.com.
│   │   ├── www.google.com.
│   │   ├── mail.google.com.
│   │   └── maps.google.com.
│   ├── github.com.
│   └── example.com.
├── org.
│   └── wikipedia.org.
├── io.
│   └── dev.io.
└── uk.
    └── co.uk.
        └── bbc.co.uk.

Each level in the hierarchy is managed by different organizations. The root zone is managed by ICANN and operated by Verisign. TLDs are managed by various registries (Verisign for .com/.net, PIR for .org, etc.). Second-level domains are registered through domain registrars like Namecheap, GoDaddy, or Cloudflare Registrar.

DNS Servers and Their Roles

Several types of DNS servers participate in resolving a domain name:

Recursive Resolvers (also called DNS recursor or recursive DNS server) are the intermediaries between clients and the DNS hierarchy. When your computer needs to resolve a domain, it asks a recursive resolver (usually provided by your ISP or a service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8). The recursive resolver does the heavy lifting of traversing the DNS hierarchy to find the answer.

Root Name Servers are the entry point into the DNS hierarchy. There are 13 root server clusters (labeled A through M), operated by organizations like ICANN, Verisign, NASA, and the US Army. These servers don't know the IP address of google.com — they know which name servers are authoritative for the .com TLD.

TLD Name Servers maintain information about domains within their TLD. The .com TLD servers know which name servers are authoritative for google.com and direct the resolver there.

Authoritative Name Servers hold the actual DNS records for a domain. When you register example.com, you configure its authoritative name servers (e.g., ns1.cloudflare.com). These servers provide the final answer — the IP address or other record data for the requested domain.

The DNS Resolution Process

When you type https://www.example.com into your browser, the following resolution process occurs:

// Step 1: Browser cache
// Browser checks its own DNS cache first
// If found and not expired → done
 
// Step 2: Operating system cache
// OS checks its DNS cache (systemd-resolved on Linux, etc.)
// If found → done
 
// Step 3: Router cache
// Home router may have cached the result
// If found → done
 
// Step 4: Recursive resolver
// Query sent to ISP's DNS or configured resolver (1.1.1.1, 8.8.8.8)
// Resolver checks its cache
// If not cached, begins recursive resolution:
 
// Step 5: Root name server
// Resolver asks root: "Where is www.example.com?"
// Root responds: "I don't know, but the .com TLD servers are at these IPs"
 
// Step 6: TLD name server
// Resolver asks .com TLD: "Where is www.example.com?"
// TLD responds: "I don't know, but example.com's authoritative servers are at these IPs"
 
// Step 7: Authoritative name server
// Resolver asks example.com's NS: "Where is www.example.com?"
// NS responds: "www.example.com is at 93.184.216.34, TTL 300"
 
// Step 8: Response returned
// Resolver returns 93.184.216.34 to the OS
// OS returns it to the browser
// Browser connects to 93.184.216.34 on port 443

This entire process typically completes in 20-120 milliseconds. Caching at every level means that subsequent lookups for the same domain are nearly instantaneous.

DNS Caching and TTL

Every DNS record has a Time To Live (TTL) value, specified in seconds. This tells resolvers and clients how long they can cache the response before querying the authoritative server again.

// Common TTL values and their use cases:
const ttlValues = {
  "60": "1 minute — for rapid changes during migrations or failover",
  "300": "5 minutes — for most dynamic records",
  "3600": "1 hour — for stable records that rarely change",
  "86400": "24 hours — for very stable records (MX, TXT)",
  "604800": "1 week — for records that essentially never change",
};
 
// Trade-off: lower TTL = faster propagation but more DNS queries
// Higher TTL = better performance but slower propagation

When you change a DNS record, the old value remains cached across the internet until all caches expire according to the previous TTL. This is why DNS changes can take hours to propagate, and why lowering TTL before a migration is a common best practice.

Architecture and DNS Record Types

DNS supports dozens of record types, but the most commonly used ones are essential for every developer to understand.

A Record (Address Record)

Maps a domain name to an IPv4 address. This is the most fundamental DNS record.

// A record: domain → IPv4 address
// example.com.  IN  A  93.184.216.34
// www.example.com.  IN  A  93.184.216.34
 
// Multiple A records for load balancing (round-robin)
// example.com.  IN  A  93.184.216.34
// example.com.  IN  A  93.184.216.35
// example.com.  IN  A  93.184.216.36
 
// DNS lookup using Node.js
import dns from "dns/promises";
 
const addresses = await dns.resolve4("example.com");
// ["93.184.216.34"]

AAAA Record (Quad-A Record)

Maps a domain name to an IPv6 address. As IPv6 adoption grows, AAAA records become increasingly important.

// AAAA record: domain → IPv6 address
// example.com.  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946
 
const addresses = await dns.resolve6("example.com");
// ["2606:2800:220:1:248:1893:25c8:1946"]

CNAME Record (Canonical Name)

Creates an alias from one domain name to another. The DNS resolver then follows the alias to resolve the target domain.

// CNAME record: alias → canonical domain
// www.example.com.  IN  CNAME  example.com.
// blog.example.com. IN  CNAME  myblog.wordpress.com.
// cdn.example.com.  IN  CNAME  d1234.cloudfront.net.
 
// Important rules:
// 1. A CNAME cannot coexist with other records at the same name
// 2. A CNAME cannot point to another CNAME (technically possible but discouraged)
// 3. A CNAME cannot be used at the zone apex (example.com without www)
//    Use ALIAS/ANAME or CNAME flattening for the root domain
 
// Example: resolving www.example.com with CNAME
// www.example.com → CNAME → example.com → A → 93.184.216.34

MX Record (Mail Exchange)

Specifies the mail servers responsible for receiving email for a domain. MX records have a priority value — lower numbers indicate higher priority.

// MX records for email routing
// example.com.  IN  MX  10 aspmx.l.google.com.
// example.com.  IN  MX  20 alt1.aspmx.l.google.com.
// example.com.  IN  MX  30 alt2.aspmx.l.google.com.
 
const mxRecords = await dns.resolveMx("example.com");
// [
//   { priority: 10, exchange: "aspmx.l.google.com" },
//   { priority: 20, exchange: "alt1.aspmx.l.google.com" },
//   { priority: 30, exchange: "alt2.aspmx.l.google.com" }
// ]

TXT Record (Text Record)

Stores arbitrary text data. Widely used for domain verification, SPF (email authentication), DKIM, and DMARC policies.

// TXT records for email authentication
// example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"
// example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
// _dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject"
 
// Domain verification
// example.com.  IN  TXT  "google-site-verification=abc123def456"
// example.com.  IN  TXT  "facebook-domain-verification=xyz789"
 
const txtRecords = await dns.resolveTxt("example.com");
// [["v=spf1 include:_spf.google.com ~all"], ["google-site-verification=abc123"]]

NS Record (Name Server)

Delegates a domain (or subdomain) to a set of name servers. NS records define which servers are authoritative for a domain.

// NS records
// example.com.  IN  NS  ns1.example.com.
// example.com.  IN  NS  ns2.example.com.
 
const nsRecords = await dns.resolveNs("example.com");
// ["ns1.example.com", "ns2.example.com"]

SRV Record (Service Record)

Specifies the location of servers for specific services. Used by protocols like XMPP, SIP, and Microsoft Active Directory.

// SRV record format: _service._proto.name TTL class priority weight port target
// _sip._tcp.example.com.  IN  SRV  10  60  5060  sip1.example.com.
// _sip._tcp.example.com.  IN  SRV  10  40  5060  sip2.example.com.
 
const srvRecords = await dns.resolveSrv("_sip._tcp.example.com");
// [{ priority: 10, weight: 60, port: 5060, name: "sip1.example.com" }]

PTR Record (Pointer Record)

Maps an IP address to a domain name — the reverse of A/AAAA records. Used for reverse DNS lookups, which are important for email server verification and security.

// PTR record (reverse DNS)
// 34.216.184.93.in-addr.arpa.  IN  PTR  example.com.
 
const hostnames = await dns.reverse("93.184.216.34");
// ["example.com"]

CAA Record (Certification Authority Authorization)

Specifies which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for a domain.

// CAA records
// example.com.  IN  CAA  0 issue "letsencrypt.org"
// example.com.  IN  CAA  0 issue "digicert.com"
// example.com.  IN  CAA  0 issuewild "letsencrypt.org"
// example.com.  IN  CAA  0 iodef "mailto:security@example.com"

Step-by-Step Implementation

Programmatic DNS Queries with Node.js

import dns from "dns/promises";
import { Resolver } from "dns";
 
// Using the default system resolver
async function lookupDomain(domain: string) {
  const aRecords = await dns.resolve4(domain, { ttl: true });
  const aaaaRecords = await dns.resolve6(domain, { ttl: true }).catch(() => []);
  const mxRecords = await dns.resolveMx(domain).catch(() => []);
  const txtRecords = await dns.resolveTxt(domain).catch(() => []);
  const nsRecords = await dns.resolveNs(domain).catch(() => []);
  const cnameRecords = await dns.resolveCname(domain).catch(() => []);
 
  return {
    domain,
    a: aRecords,
    aaaa: aaaaRecords,
    mx: mxRecords,
    txt: txtRecords,
    ns: nsRecords,
    cname: cnameRecords,
  };
}
 
// Using a specific DNS resolver
const resolver = new Resolver();
resolver.setServers(["1.1.1.1", "8.8.8.8"]);
 
async function resolveWithCustomResolver(domain: string) {
  resolver.resolve4(domain, (err, addresses) => {
    if (err) throw err;
    console.log(`${domain} resolves to:`, addresses);
  });
}

DNS over HTTPS (DoH)

DNS over HTTPS encrypts DNS queries by sending them over HTTPS, preventing ISP snooping and man-in-the-middle attacks.

// DNS over HTTPS using Cloudflare's resolver
async function resolveDoH(domain: string, type: string = "A") {
  const url = new URL("https://cloudflare-dns.com/dns-query");
  url.searchParams.set("name", domain);
  url.searchParams.set("type", type);
 
  const response = await fetch(url.toString(), {
    headers: { "Accept": "application/dns-json" },
  });
 
  const data = await response.json();
  return data.Answer?.map((a: any) => ({
    name: a.name,
    type: a.type,
    ttl: a.TTL,
    data: a.data,
  }));
}
 
// Usage
const results = await resolveDoH("example.com", "A");
// [{ name: "example.com", type: 1, TTL: 300, data: "93.184.216.34" }]
 
// Using Google's DoH
async function resolveGoogleDoH(domain: string) {
  const response = await fetch(
    `https://dns.google/resolve?name=${domain}&type=A`
  );
  return response.json();
}

Setting Up DNS with Cloudflare (Terraform)

# DNS records managed with Terraform
resource "cloudflare_record" "root" {
  zone_id = var.zone_id
  name    = "@"
  value   = "93.184.216.34"
  type    = "A"
  ttl     = 300
  proxied = true  # Cloudflare proxy for DDoS protection
}
 
resource "cloudflare_record" "www" {
  zone_id = var.zone_id
  name    = "www"
  value   = "example.com"
  type    = "CNAME"
  ttl     = 300
  proxied = true
}
 
resource "cloudflare_record" "api" {
  zone_id = var.zone_id
  name    = "api"
  value   = "93.184.216.35"
  type    = "A"
  ttl     = 60  # Lower TTL for API subdomain
  proxied = true
}
 
resource "cloudflare_record" "mx_google" {
  zone_id  = var.zone_id
  name     = "@"
  value    = "aspmx.l.google.com"
  type     = "MX"
  priority = 10
  ttl      = 3600
}
 
resource "cloudflare_record" "spf" {
  zone_id = var.zone_id
  name    = "@"
  value   = "v=spf1 include:_spf.google.com ~all"
  type    = "TXT"
  ttl     = 3600
}

Real-World Use Cases

Use Case 1: Blue-Green Deployment with DNS

DNS-based traffic switching enables blue-green deployments where you update DNS records to point to a new server version.

// Before deployment: lower TTL
// example.com  A  300  10.0.1.1  (blue server)
 
// During deployment: switch to green server
// example.com  A  300  10.0.2.1  (green server)
 
// Script to update DNS for blue-green deployment
async function switchTraffic(fromIP: string, toIP: string) {
  console.log(`Lowering TTL to 60 seconds...`);
  await updateDNSTTL("example.com", 60);
  console.log("Waiting for old TTL to expire (300 seconds)...");
  await sleep(300_000);
 
  console.log(`Switching from ${fromIP} to ${toIP}...`);
  await updateARecord("example.com", toIP);
  console.log("Traffic switched. Monitoring...");
 
  // Monitor new server for 5 minutes
  await monitorHealth(toIP, 300_000);
 
  console.log("Deployment successful. Restoring TTL...");
  await updateDNSTTL("example.com", 3600);
}

Use Case 2: GeoDNS for Global Applications

GeoDNS returns different IP addresses based on the client's geographic location, directing users to the nearest server.

// Route53 geolocation routing
// US users → us-east-1 server
// EU users → eu-west-1 server
// APAC users → ap-southeast-1 server
 
// AWS SDK for Route53 geolocation records
import { Route53Client, ChangeResourceRecordSetsCommand } from "@aws-sdk/client-route53";
 
async function createGeoRecord(region: string, ip: string) {
  const client = new Route53Client({ region: "us-east-1" });
 
  await client.send(new ChangeResourceRecordSetsCommand({
    HostedZoneId: "Z1234567890",
    ChangeBatch: {
      Changes: [{
        Action: "CREATE",
        ResourceRecordSet: {
          Name: "api.example.com",
          Type: "A",
          TTL: 300,
          Region: region,
          ResourceRecords: [{ Value: ip }],
        },
      }],
    },
  }));
}

Use Case 3: Service Discovery with DNS

DNS SRV records enable service discovery in microservices architectures, allowing services to find each other without hardcoded addresses.

// Discover available API servers via SRV records
async function discoverService(service: string, protocol: string, domain: string) {
  const records = await dns.resolveSrv(`_${service}._${protocol}.${domain}`);
 
  // Sort by priority, then weight
  records.sort((a, b) => a.priority - b.priority || b.weight - a.weight);
 
  return records.map(r => ({
    host: r.name,
    port: r.port,
    priority: r.priority,
    weight: r.weight,
  }));
}
 
// Usage
const servers = await discoverService("http", "tcp", "example.com");
// [{ host: "api1.example.com", port: 443, priority: 10, weight: 80 },
//  { host: "api2.example.com", port: 443, priority: 10, weight: 20 }]
 
// Client-side load balancing based on weights
function selectServer(servers: ServiceRecord[]): ServiceRecord {
  const totalWeight = servers.reduce((sum, s) => sum + s.weight, 0);
  let random = Math.random() * totalWeight;
  for (const server of servers) {
    random -= server.weight;
    if (random <= 0) return server;
  }
  return servers[0];
}

Best Practices for Production

Lower TTL before migrations: Before changing DNS records for a migration, lower the TTL to 60-300 seconds at least one TTL period before the change. This ensures caches expire quickly after the change.
Use multiple name servers: Configure at least 2-3 NS records with geographically distributed servers. This ensures DNS availability even if one server fails.
Enable DNSSEC: DNS Security Extensions (DNSSEC) adds cryptographic signatures to DNS records, preventing DNS spoofing and cache poisoning attacks. Major TLDs support DNSSEC, and most registrars make it easy to enable.
Use CAA records: Specify which Certificate Authorities can issue certificates for your domains. This prevents unauthorized certificate issuance.
Monitor DNS resolution: Set up monitoring for your DNS resolution times and record values. Services like Pingdom, DNSViz, or custom monitoring can alert you to DNS issues before they affect users.
Implement DNS failover: Use health-check-based DNS failover to automatically route traffic away from unhealthy servers. Cloudflare, AWS Route53, and other providers offer this feature.
Separate DNS from your hosting provider: Using an independent DNS provider (like Cloudflare, Route53, or NS1) ensures that a hosting provider outage doesn't take down your DNS as well.
Document your DNS records: Maintain documentation of all DNS records, their purpose, and their expected values. This is invaluable during incident response and for onboarding new team members.

Common Pitfalls and Solutions

Pitfall	Impact	Solution
Forgetting to lower TTL before migration	Old IP cached for hours after migration	Lower TTL 24-48 hours before planned changes
CNAME at zone apex	Root domain can't use CNAME with other records	Use ALIAS/ANAME records or CNAME flattening
No reverse DNS (PTR) for mail server	Emails rejected or marked as spam	Configure PTR records matching your mail server's HELO
DNSSEC misconfiguration	Domain becomes unreachable	Test DNSSEC setup with DNSViz before enabling
Single point of failure (single NS)	DNS outage takes down all services	Use 2+ geographically distributed NS servers
Overly long TTL for dynamic records	Stale records served from cache	Use 300s TTL for A/AAAA, 3600s for MX/TXT

Performance Optimization

// DNS prefetching in HTML (browser optimization)
// <link rel="dns-prefetch" href="//api.example.com">
// <link rel="preconnect" href="https://api.example.com">
 
// Node.js: set DNS cache at the application level
import { Resolver } from "dns";
 
class DNSCache {
  private cache = new Map<string, { addresses: string[]; expiry: number }>();
  private resolver = new Resolver();
 
  async resolve(hostname: string): Promise<string[]> {
    const cached = this.cache.get(hostname);
    if (cached && cached.expiry > Date.now()) {
      return cached.addresses;
    }
 
    const addresses = await new Promise<string[]>((resolve, reject) => {
      this.resolver.resolve4(hostname, (err, addrs) => {
        if (err) reject(err);
        else resolve(addrs);
      });
    });
 
    this.cache.set(hostname, {
      addresses,
      expiry: Date.now() + 60_000, // Cache for 60 seconds
    });
 
    return addresses;
  }
}

Comparison with Alternatives

Approach	Speed	Security	Complexity	Use Case
Traditional DNS (UDP)	Fast	Low (no encryption)	Low	Most websites
DNS over HTTPS (DoH)	Moderate	High (encrypted)	Medium	Privacy-sensitive applications
DNS over TLS (DoT)	Moderate	High (encrypted)	Medium	Enterprise networks
DNS over QUIC (DoQ)	Fast	High (encrypted)	High	Cutting-edge browsers
Multicast DNS (mDNS)	Very fast	None	Low	Local network discovery
DNS-SD (Service Discovery)	Fast	Low	Medium	IoT and local services

For most applications, traditional DNS with DNSSEC provides the best balance of performance and security. Use DoH or DoT when privacy is a primary concern.

Advanced Patterns

Split-Horizon DNS

Split-horizon DNS serves different responses to internal and external clients. Internal clients get private IP addresses while external clients get public addresses.

// Internal DNS server configuration
const internalZone = {
  "api.example.com": "10.0.1.100",    // Internal IP
  "db.example.com": "10.0.2.50",      // Internal IP
};
 
const externalZone = {
  "api.example.com": "93.184.216.34", // Public IP
};
 
function resolveSplitHorizon(domain: string, clientIP: string): string {
  const isInternal = clientIP.startsWith("10.") ||
                     clientIP.startsWith("192.168.") ||
                     clientIP.startsWith("172.16.");
 
  const zone = isInternal ? internalZone : externalZone;
  return zone[domain] || "NXDOMAIN";
}

DNS-Based Canary Deployments

// Route a percentage of traffic to canary servers
function weightedDNSResolve(domain: string): string {
  const records = [
    { ip: "10.0.1.1", weight: 95, version: "stable" },
    { ip: "10.0.1.2", weight: 5, version: "canary" },
  ];
 
  let random = Math.random() * 100;
  for (const record of records) {
    random -= record.weight;
    if (random <= 0) return record.ip;
  }
  return records[0].ip;
}

Testing Strategies

# Manual DNS testing tools
dig example.com A +short          # Quick A record lookup
dig example.com ANY +noall +answer # All records
dig @1.1.1.1 example.com         # Query specific resolver
dig example.com +trace            # Full resolution trace
nslookup example.com              # Cross-platform lookup
 
# Check propagation across providers
dig @8.8.8.8 example.com A       # Google
dig @1.1.1.1 example.com A       # Cloudflare
dig @9.9.9.9 example.com A       # Quad9
 
# Reverse DNS lookup
dig -x 93.184.216.34
 
# Test DNSSEC
dig example.com +dnssec +short
delv example.com A

// Automated DNS testing
import dns from "dns/promises";
 
describe("DNS Configuration", () => {
  it("resolves A records correctly", async () => {
    const addresses = await dns.resolve4("example.com");
    expect(addresses).toContain("93.184.216.34");
  });
 
  it("has correct MX records", async () => {
    const mx = await dns.resolveMx("example.com");
    expect(mx[0].exchange).toBe("aspmx.l.google.com");
    expect(mx[0].priority).toBe(10);
  });
 
  it("has SPF record configured", async () => {
    const txt = await dns.resolveTxt("example.com");
    const spf = txt.find(r => r[0].startsWith("v=spf1"));
    expect(spf).toBeDefined();
  });
 
  it("has CAA record for Let's Encrypt", async () => {
    const caa = await dns.resolveCaa("example.com");
    const le = caa.find(r => r.issue === "letsencrypt.org");
    expect(le).toBeDefined();
  });
});

Future Outlook

DNS continues evolving to meet modern internet demands. DNS over HTTPS (DoH) and DNS over TLS (DoT) are becoming mainstream, encrypting DNS queries to prevent surveillance and manipulation. Encrypted Client Hello (ECH) extends this privacy to the TLS handshake itself.

Oblivious DNS over HTTPS (ODoH) adds a proxy layer so that even the DNS resolver cannot see the client's IP address. These privacy-focused developments are reshaping how DNS operates while maintaining backward compatibility with the existing infrastructure.

Conclusion

DNS is the invisible backbone of the internet. Understanding how resolution works, knowing the record types, and following best practices for TTL management, security, and reliability will make you a more effective developer and infrastructure engineer.

Key takeaways:

DNS translates human-readable domain names to IP addresses through a hierarchical system
Resolution involves browser cache → OS cache → recursive resolver → root → TLD → authoritative NS
TTL determines how long records are cached — lower before migrations, higher for stability
Use A/AAAA for IP mapping, CNAME for aliases, MX for email, TXT for verification
Enable DNSSEC to prevent DNS spoofing
Use multiple geographically distributed name servers
Monitor DNS resolution and set up failover for critical services
Consider DNS over HTTPS for privacy-sensitive applications

Master DNS, and you'll have a solid foundation for everything you build on the internet.

Minh Vo

Slaying code & making it lit fr fr 🔥 tagline