How DNS Works: A Deep Dive

Every network connection starts with a name lookup. When you type a URL into your browser, the first thing that happens - before any HTTP request, before any TLS handshake - is a DNS query. The Domain Name System translates human-readable domain names like infishark.com into the IP addresses that routers actually use to deliver packets.

DNS is often described as the phone book of the internet. That analogy captures the basic function but misses the complexity. DNS is a globally distributed, hierarchical, cached database that handles billions of queries per day. Its design decisions - particularly around caching and the lack of built-in authentication - have deep security implications.

What DNS Does

At its core, DNS maps names to numbers. Your browser needs to connect to infishark.com, but the network stack needs an IP address like 104.21.48.1. DNS provides that mapping.

But DNS does more than simple name-to-IP translation. It handles mail routing (MX records), service discovery (SRV records), domain verification (TXT records), canonical name aliasing (CNAME records), and reverse lookups (PTR records). It is the backbone infrastructure that makes human-friendly naming possible on a network that speaks only in numbers.

The Resolution Chain

When your device needs to resolve a domain name, the query passes through several layers:

Step 1: Stub Resolver. Your operating system has a built-in stub resolver. When an application calls getaddrinfo() or similar, the stub resolver checks its local cache first. If the answer is cached and not expired, it returns immediately. If not, it forwards the query to a configured recursive resolver.

Step 2: Recursive Resolver. This is typically run by your ISP or a public service like Google (8.8.8.8), Cloudflare (1.1.1.1), or Quad9 (9.9.9.9). The recursive resolver does the heavy lifting. It checks its own cache, and if the answer is not there, it walks the DNS hierarchy on your behalf.

Step 3: Root Servers. The recursive resolver starts at the top of the hierarchy by querying a root server. There are 13 root server identities (a.root-servers.net through m.root-servers.net), but each identity is served by multiple physical servers distributed globally via anycast. The root server does not know the final answer - it only knows which servers are authoritative for each top-level domain (TLD).

Step 4: TLD Servers. The root server directs the resolver to the TLD server for .com, .org, .net, or whatever TLD the domain uses. The TLD server knows which nameservers are authoritative for each domain registered under that TLD.

Step 5: Authoritative Server. Finally, the resolver queries the domain's authoritative nameserver, which holds the actual DNS records. This server returns the definitive answer - the IP address (or other record) for the requested name.

The recursive resolver caches the answer and returns it to the stub resolver, which caches it locally and returns it to the application. The entire chain might take 50-200 milliseconds on a cache miss, but subsequent lookups return from cache in under a millisecond.

sequenceDiagram
    participant App as Application
    participant Stub as Stub Resolver
    participant Rec as Recursive Resolver
    participant Root as Root Server
    participant TLD as TLD Server - .com
    participant Auth as Authoritative NS
    App->>Stub: Resolve infishark.com
    Stub->>Stub: Check local cache - miss
    Stub->>Rec: Query infishark.com
    Rec->>Rec: Check cache - miss
    Rec->>Root: Who handles .com?
    Root->>Rec: Try a.gtld-servers.net
    Rec->>TLD: Who handles infishark.com?
    TLD->>Rec: Try ns1.infishark.com
    Rec->>Auth: A record for infishark.com?
    Auth->>Rec: 104.21.48.1 - TTL 300
    Rec->>Rec: Cache with TTL 300
    Rec->>Stub: 104.21.48.1
    Stub->>Stub: Cache locally
    Stub->>App: 104.21.48.1

Figure 1 - The full DNS resolution chain from application to authoritative nameserver

DNS Record Types

DNS supports many record types, each serving a different purpose:

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

AAAA record maps a domain name to an IPv6 address (the four A's stand for four times the address length of an A record).

CNAME record creates an alias from one name to another. For example, www.infishark.com might be a CNAME pointing to infishark.com. The resolver follows the CNAME chain until it reaches an A or AAAA record.

MX record specifies the mail server responsible for accepting email for the domain. MX records include a priority value so domains can have primary and backup mail servers.

TXT record holds arbitrary text data. It is widely used for domain verification (Google, Microsoft), email authentication (SPF, DKIM, DMARC), and other metadata.

NS record identifies the authoritative nameservers for a domain. These are what TLD servers return to recursive resolvers.

SOA record (Start of Authority) contains administrative information about the zone, including the primary nameserver, the administrator's email, serial number, and timing parameters for zone transfers.

PTR record provides reverse DNS lookup - mapping an IP address back to a domain name. Used for email server verification and network diagnostics.

Caching and TTL

Caching is fundamental to DNS performance. Without caching, every DNS lookup would require a full walk of the hierarchy - root, TLD, authoritative - adding hundreds of milliseconds to every connection. Caching happens at every level: the stub resolver, the recursive resolver, and sometimes even the application itself.

Each DNS record includes a TTL (Time to Live) value in seconds. When a resolver caches a record, it stores it for exactly TTL seconds, then discards it. A TTL of 300 means the record is cached for 5 minutes. A TTL of 86400 means 24 hours.

Low TTLs allow rapid changes (useful for failover and load balancing) but increase query load on authoritative servers. High TTLs reduce load but mean changes propagate slowly. Most production domains use TTLs between 300 and 3600 seconds.

Negative caching is equally important. When a domain does not exist (NXDOMAIN response), that result is also cached based on the SOA record's minimum TTL. Without negative caching, a typo like infishrk.com would generate a full resolution walk every time someone retried it.

graph TD
    subgraph "DNS Caching Layers"
        A[Application cache - browser] -->|miss| B[Stub resolver cache - OS]
        B -->|miss| C[Recursive resolver cache - ISP/public]
        C -->|miss| D[Full resolution walk]
        D --> E[Root servers]
        E --> F[TLD servers]
        F --> G[Authoritative servers]
    end
    subgraph "TTL Behavior"
        H[Record returned with TTL=300] --> I[Cached for 300 seconds]
        I --> J{TTL expired?}
        J -->|No| K[Return from cache]
        J -->|Yes| L[Discard and re-query]
    end
    subgraph "Negative Caching"
        M[NXDOMAIN response] --> N[Cached per SOA minimum TTL]
        N --> O[Prevents repeated lookups for typos]
    end

Figure 2 - DNS caching layers and TTL-based expiration including negative caching

DNSSEC - Signing the Answers

Standard DNS has no authentication. When your resolver receives an answer, it has no way to verify that the answer actually came from the authoritative server and was not modified in transit. This makes DNS vulnerable to poisoning attacks, where an attacker injects false records into a resolver's cache.

DNSSEC (DNS Security Extensions) adds digital signatures to DNS responses. The authoritative server signs its records with a private key, and the resolver verifies the signatures using the corresponding public key. The public keys are themselves signed by the parent zone, forming a chain of trust up to the root zone.

DNSSEC does not encrypt DNS queries or responses - it only authenticates them. An eavesdropper can still see what domains you are looking up. But they cannot modify the responses without breaking the signatures.

Adoption of DNSSEC has been slow. Signing zones requires operational complexity, and many resolvers do not validate signatures. But for domains that do deploy it, DNSSEC provides strong protection against cache poisoning and man-in-the-middle modification of DNS responses.

DNS Privacy - DoH and DoT

Traditional DNS queries are sent in plaintext over UDP port 53. Anyone on the network path - your ISP, a coffee shop's WiFi operator, an attacker on the local network - can see exactly which domains you are resolving.

DNS over HTTPS (DoH) wraps DNS queries inside HTTPS requests to port 443. The queries are encrypted by TLS and look identical to regular HTTPS traffic from the outside. This prevents both eavesdropping and modification.

DNS over TLS (DoT) encrypts DNS queries using TLS on port 853. It is easier to identify (and block) than DoH because it uses a dedicated port, but it is simpler to implement and does not require HTTP infrastructure.

Both protocols solve the privacy problem but shift trust from your network operator to your DNS provider. If you use Cloudflare's DoH resolver, Cloudflare sees all your DNS queries instead of your ISP. This is a trade-off, not an absolute improvement.

DNS and Network Security

DNS is the first step in virtually every network connection, which makes it a high-value target for attacks and a powerful tool for network control.

DNS hijacking redirects DNS responses to point to a different server. Captive portals use this legitimately - when a device connects to a network and makes a DNS query, the captive portal's DNS server returns its own IP address instead of the real one, forcing the browser to load the portal page. The BLEShark Nano's evil portal feature uses exactly this technique.

DNS spoofing/poisoning injects false records into a resolver's cache. The classic Kaminsky attack exploited the predictability of DNS transaction IDs to race legitimate responses and inject false answers. Modern resolvers use source port randomization and DNSSEC validation to defend against this.

DNS tunneling encodes arbitrary data in DNS queries and responses, creating a covert communication channel. Because DNS traffic is rarely blocked entirely, tunneling can bypass firewalls and captive portals. Detection requires analyzing query patterns - DNS tunnels generate abnormally long domain names and high query volumes.

Understanding DNS at this level is essential for anyone working with network security tools. Every interception technique, every redirect, every man-in-the-middle attack either starts with or depends on DNS behavior.