Skilled Coder Blog
Twitter
|
Newsletter
Technology Explained

How DNS Works from Start to Finish

  1. You type a website like example.com into your browser and hit Enter.

  2. The browser wants to load the website: but it needs the IP address of that domain (e.g., 93.184.216.34) to connect to the server.

  3. So, it asks: “What’s the IP address of example.com?” This question starts the DNS (Domain Name System) lookup.

Step-by-step Resolution Begins:

  1. First, the browser checks if it already has the IP saved in its DNS cache (from a previous visit).

  2. If not, it asks the operating system (like Windows, macOS, or Linux): “Hey, do you know the IP?”

  3. If the OS doesn’t know, it sends the question to a DNS Resolver: usually provided by your ISP, or something like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1.

Now the Real Lookup Begins:

  1. The resolver checks its own cache. If no luck, it starts asking other DNS servers, starting from the top:

1. Root Server

  1. The resolver first asks a Root DNS Server: “Who handles domains that end with .com?”

    • There are 13 sets of root servers globally.
    • They don’t give final answers: just directions.

2. TLD Server

  1. The root server replies: “Ask the TLD (Top-Level Domain) server for .com domains.”

    • TLD = the last part of the domain, like .com, .net, .org, .in, etc.
    • Each TLD has its own DNS servers.

  2. So now the resolver contacts a .com TLD server, and asks: “Hey, where can I find example.com?“

3. Authoritative DNS Server

  1. The TLD server responds: “Ask the authoritative DNS server for example.com: it has the actual IP.”

    a. This server is usually managed by your hosting provider (like GoDaddy, AWS Route53, Cloudflare, etc.)

  2. The resolver now finally asks the authoritative server: “What is the IP address of example.com?”

  3. And finally, this server replies with the correct IP: “It’s 93.184.216.34.”

  4. The resolver sends the IP back to your operating system.

  5. Your OS sends it to the browser.

  6. Now the browser knows where to connect and makes an HTTP request to that IP address: and the website loads.

  7. The resolver stores (caches) this IP for a while: so the next time you (or someone else nearby) visits example.com, it doesn’t have to look it up again.

  8. The caching is controlled by a setting called TTL (Time To Live): the site owner decides how long others should remember the IP.

  9. There are different types of DNS records:

  • A - IP address of a domain
  • CNAME - Alias to another domain
  • MX - Mail server
  • TXT - Misc info like SPF, verification, etc.
NOTE: The content below is additional technical knowledge and not necessary for basic understanding. Feel free to stop here if you're looking for just the essential process.

DNS Technical Deep Dive

DNS Record Types in Detail

DNS supports numerous record types, each with specific purposes:

  1. A Record:

    • Maps hostname to IPv4 address
    • Format: example.com. 3600 IN A 93.184.216.34
    • Multiple A records enable round-robin load balancing
    • Often has relatively short TTL for flexibility

  2. AAAA Record:

    • Maps hostname to IPv6 address
    • Format: example.com. 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
    • Modern sites implement both A and AAAA for dual-stack support

  3. CNAME Record:

    • Creates alias pointing to another name
    • Format: www.example.com. 3600 IN CNAME example.com.
    • Cannot coexist with other records for same name
    • Cannot be used at zone apex (root domain)

  4. MX Record:

    • Specifies mail servers for domain
    • Includes priority value (lower numbers = higher priority)
    • Format: example.com. 3600 IN MX 10 mail.example.com.
    • Multiple MX records provide mail server redundancy

  5. TXT Record:

    • Stores arbitrary text data
    • Used for domain verification, SPF, DKIM, DMARC
    • Format: example.com. 3600 IN TXT "v=spf1 include:_spf.example.com ~all"
    • Maximum 255 characters per string (can be chunked)

  6. NS Record:

    • Delegates zone to authoritative nameservers
    • Format: example.com. 86400 IN NS ns1.example.com.
    • Typically set at registrar level
    • Minimum of two NS records recommended for redundancy

  7. SOA Record:

    • Start of Authority - contains administrative information
    • Only one SOA record per zone
    • Contains serial number, refresh intervals, negative caching TTL
    • Format: example.com. 86400 IN SOA ns1.example.com. admin.example.com. ( 2023121501 ; serial 7200 ; refresh 3600 ; retry 1209600 ; expire 3600 ) ; minimum TTL

  8. SRV Record:

    • Specifies service location (port and hostname)
    • Used for VoIP, IM, and other services
    • Format: _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
    • Includes priority, weight, port, and target fields

  9. CAA Record:

    • Certificate Authority Authorization
    • Restricts which CAs can issue certificates
    • Format: example.com. 3600 IN CAA 0 issue "letsencrypt.org"
    • Helps prevent unauthorized certificate issuance

  10. PTR Record:

    • Reverse DNS lookup (IP to name)
    • Format: 34.216.184.93.in-addr.arpa. 3600 IN PTR example.com.
    • Used for reputation systems and verification

DNS Protocol Technical Details

DNS operates primarily over UDP with TCP fallback:

  1. Message Format:

    • 12-byte header containing query ID, flags, and counts
    • Question section with QNAME, QTYPE, and QCLASS
    • Answer section containing resource records
    • Authority section with NS records
    • Additional section with related records
    • Maximum UDP packet size: 512 bytes (traditional) or 4096 bytes (EDNS0)

  2. Query Types:

    • Standard query: One question, expects direct answer
    • Inverse query: Requests data matching specific answer (deprecated)
    • Recursive query: Asks resolver to complete full resolution
    • Non-recursive (iterative) query: Just wants best available information

  3. Response Codes:

    • NOERROR (0): No error condition
    • FORMERR (1): Format error in query
    • SERVFAIL (2): Server failure
    • NXDOMAIN (3): Name does not exist
    • NOTIMP (4): Not implemented
    • REFUSED (5): Query refused
    • Additional codes for DNSSEC and extensions

  4. UDP vs TCP:

    • UDP for standard queries (port 53)
    • TCP for zone transfers and responses >512 bytes
    • DNS over TLS (DoT): TCP port 853
    • DNS over HTTPS (DoH): TCP port 443

DNS Infrastructure Organization

The global DNS system is a distributed hierarchical database:

  1. Root Zone:

    • Maintained by IANA (Internet Assigned Numbers Authority)
    • 13 logical root server clusters (A through M)
    • Each cluster has multiple physical servers using anycast
    • Over 1000 physical servers worldwide
    • Root zone file managed through controlled process
    • Changes to root zone require multiple approvals

  2. TLD Organization:

    • gTLDs: Generic TLDs (.com, .org, .net) managed by registry operators
    • ccTLDs: Country-code TLDs (.us, .uk, .jp) managed by country authorities
    • New gTLDs: Recently added extensions (.app, .blog, .xyz)
    • Special-use TLDs: Reserved for specific purposes (.localhost, .test)
    • IDN TLDs: Internationalized domain names (e.g., .网址, .рф)

  3. Registrar-Registry Model:

    • Registry: Maintains authoritative database for TLD
    • Registrar: Accredited entity that sells domains to public
    • Separation of concerns for competition and security

DNS Resolution Mechanisms

DNS resolution can follow different paths:

  1. Recursive Resolution:

    • Client sends query to recursive resolver
    • Resolver takes full responsibility for finding answer
    • Performs multiple queries to different nameservers
    • Returns complete answer to client
    • Most client-facing resolvers operate recursively

  2. Iterative Resolution:

    • Client or resolver receives referrals to next nameserver
    • Must follow chain of referrals itself
    • Root and TLD servers typically offer iterative responses
    • More efficient for DNS infrastructure
    • Used between DNS servers

  3. Forwarding:

    • Resolver forwards query to another resolver
    • May cache response before returning to client
    • Common in enterprise environments
    • Can create resolution chains

DNS Caching System

Caching happens at multiple levels for performance:

  1. Cache Hierarchy:

    • Browser cache: Shortest duration, user-specific
    • Operating system cache: Shared by all applications
    • Local network cache (router/gateway)
    • ISP resolver cache: Shared by many customers
    • Public resolver cache (8.8.8.8, 1.1.1.1)

  2. TTL Mechanics:

    • Defined per record in seconds
    • Specifies maximum time to cache
    • Actual cache duration may be shorter (resolver policy)
    • TTL counter decrements while cached
    • Zero TTL prevents caching entirely

  3. Negative Caching:

    • Caching of NXDOMAIN responses
    • Prevents repeated queries for non-existent domains
    • Controlled by SOA record’s minimum TTL
    • Important for performance and DDoS mitigation

  4. Cache Poisoning Protections:

    • Query ID randomization
    • Source port randomization
    • Case randomization in queries
    • DNSSEC validation

DNSSEC (DNS Security Extensions)

DNSSEC adds cryptographic authentication:

  1. Digital Signatures:

    • Each DNS record or set has digital signature (RRSIG)
    • Signatures created with zone’s private key
    • Verified using zone’s public key (DNSKEY)
    • Chain of trust from root to leaf zones

  2. Trust Anchor:

    • Root zone DNSKEY is starting point of trust
    • Distributed to resolvers via trusted channel
    • DS (Delegation Signer) records link parent to child zone keys

  3. Record Types:

    • DNSKEY: Public key for zone
    • RRSIG: Signature covering specific records
    • DS: Delegation signature linking to child zone
    • NSEC/NSEC3: Authenticated denial of existence

  4. Zone Signing Process:

    • ZSK (Zone Signing Key): Signs actual records
    • KSK (Key Signing Key): Signs DNSKEY records
    • Key rotation procedures for security
    • Automated signing systems

DNS Performance Optimization

Various techniques improve DNS performance:

  1. Anycast Routing:

    • Same IP address announced from multiple locations
    • BGP routing sends query to nearest instance
    • Reduces latency and provides load balancing
    • Improves resilience against DDoS attacks
    • Used by root servers, TLD servers, and public resolvers

  2. Response Rate Limiting:

    • Detects and limits abnormally high query rates
    • Prevents amplification attacks
    • Implemented at authoritative nameservers
    • Dynamic thresholds based on query patterns

  3. Prefetching:

    • Proactive resolution before actual need
    • Implemented in browsers and resolvers
    • Reduces perceived latency
    • Based on links, DNS records in HTML, historic patterns

  4. DNS Query Minimization:

    • Reveals only necessary parts of query to each nameserver
    • Improves privacy
    • Reduces information leakage
    • Standardized in RFC 7816

DNS-Based Services and Extensions

DNS has evolved beyond simple name resolution:

  1. GeoDNS:

    • Returns different answers based on client location
    • Directs users to nearest server
    • Implemented using DNS provider’s proprietary systems
    • Uses Edns-Client-Subnet extension for accuracy

  2. DNS-Based Load Balancing:

    • Rotates between multiple IP addresses
    • Health-checking removes failed servers
    • Weighted responses direct traffic proportionally
    • Low TTLs allow quick adjustments

  3. DNS Firewalls:

    • Block access to malicious domains
    • RPZ (Response Policy Zones) define blocking rules
    • Used for security and content filtering
    • Implemented at resolver level

  4. Dynamic DNS:

    • Allows frequent updates to DNS records
    • Used for home networks with dynamic IPs
    • Update clients use protocols like RFC 2136 or proprietary APIs
    • Enables hosting services on changing IP addresses