DNS From First Principles

Note: This is sample placeholder content created to demonstrate the blog. Replace it with your own writing.

For most of my career I treated DNS the way most engineers do: as a black box that "just works" until it doesn't. It wasn't until I had to debug a split-horizon setup on a customer network that I actually slowed down and read the relevant RFCs. This post is the explanation I wish I'd had earlier — short, grounded, and focused on the parts that matter for security work.

What DNS Actually Solves#

The Domain Name System is, at its core, a distributed, eventually-consistent database that maps human-readable names to machine-usable data. The most famous mapping is name → IP address, but the system carries a lot more than that (mail exchangers, name server delegations, text records, service discovery hints, cryptographic proofs).

Two design pressures shape everything about DNS:

1. The namespace is huge and changes constantly. No single server could hold it.
2. Lookups happen on the hot path of almost every connection. Latency matters.

The result is a hierarchical, heavily cached system where authority is delegated downward from the root, and where every participant is allowed to remember what it learned for a while.

The Resolution Flow#

When you type https://example.com into a browser, the part DNS cares about is example.com. Before any TLS handshake, before any TCP connection, the browser needs an IP address. Here's the path that request usually takes.

The Stub Resolver#

Your application doesn't talk DNS itself. It hands the name to a stub resolver inside the operating system (glibc's getaddrinfo, musl's resolver, the Win32 getaddrinfo API). The stub resolver reads /etc/resolver.conf or the system's network configuration to find a recursive resolver — usually the one advertised by DHCP, or a manually-set one like 1.1.1.1 or 8.8.8.8.

The Recursive Resolver#

The recursive resolver (also called a caching resolver or recursor) is the part that does the actual walking. If it already has the answer cached, it returns it immediately. If not, it performs an iterative query starting at the root:

1. Ask a root server: "where is .com?"
2. Ask a .com TLD server: "where is example.com?"
3. Ask the authoritative server for example.com: "what is the address of example.com?"

Each step returns a referral — a pointer to the next server closer to the answer — rather than the answer itself. The recursor caches every referral and every answer with a TTL.

Authoritative Servers#

Authoritative servers are the source of truth for a zone. They don't recurse; they answer from their own data or refuse. A single zone is usually served by multiple authoritative name servers for redundancy, and modern setups hide them behind services like Cloudflare, Route 53, or NS1.

A common mental shortcut: the recursive resolver asks questions on behalf of clients; the authoritative server answers questions about zones it owns. A single piece of software (BIND, Unbound, Knot) can do either job, but in production they're almost always deployed as separate roles.

Record Types#

DNS records are typed. The type tells you what kind of data the record carries. Here are the ones I find myself reaching for most often:

Type	Purpose	Example value
A	IPv4 address for a name	93.184.216.34
AAAA	IPv6 address for a name	2606:2800:220:1:248:1893:25c8:1946
CNAME	Canonical name — an alias to another name	www.example.com → example.com
MX	Mail exchanger (with priority)	10 mail.example.com
TXT	Arbitrary text (SPF, DKIM, domain verification)	"v=spf1 -all"
NS	Authoritative name servers for a zone	a.iana-servers.net
SOA	Start of authority — zone metadata	serial, refresh, retry, expire, minimum
PTR	Reverse lookup — IP → name	34.216.184.93.in-addr.arpa → example.com

CNAME deserves a footnote: a name with a CNAME record cannot have any other record type. This is why you can't put a CNAME at the apex of a zone (the bare example.com) under the strict reading of the original RFCs — though providers offer "flattening" or ALIAS/ANAME pseudo-records to work around it.

Querying DNS Yourself#

dig is the tool I reach for first when something feels off. It's verbose, predictable, and ships with most macOS / Linux systems. A few patterns I use weekly:

# Default A-record lookup against the system resolver.
dig example.com

# Ask a specific resolver (here: Cloudflare's 1.1.1.1).
dig @1.1.1.1 example.com

# Short answer only — great for scripting.
dig +short example.com AAAA

# Follow the delegation chain manually. This shows every
# referral from the root down to the authoritative answer.
dig +trace example.com

# Pull TXT records — useful for verifying SPF / DKIM.
dig +short TXT example.com

A typical +short reply is just the data:

$ dig +short example.com
93.184.216.34

A full dig reply includes the header, the question section, the answer, authority, and additional records, along with a status line. Pay attention to status: NOERROR versus status: NXDOMAIN — the first means "the name exists, here's the answer (or the lack of one)"; the second means "the name does not exist anywhere in this zone's authority."

Security Considerations#

DNS was designed in a world where the network was assumed to be broadly cooperative. That assumption has not held for decades, and the security story around DNS is largely a story of retrofitting authenticity and confidentiality onto a protocol that originally had neither.

DNS Spoofing and Cache Poisoning#

A spoofing attack is when an attacker tricks a victim into accepting a forged DNS response. The classic Kaminsky attack (2008) demonstrated how an off-path attacker could poison a recursive resolver's cache by racing forged replies against legitimate ones, exploiting the predictability of transaction IDs and source ports. Modern recursors randomize both, which raises the cost but doesn't eliminate the underlying problem.

The structural fix is DNSSEC (RFC 9364), which signs records cryptographically so a resolver can verify that an answer genuinely came from the zone's operator and wasn't tampered with in flight. DNSSEC deployment is uneven — many TLDs support it, many individual zones don't — but it's worth understanding because the chain of trust (root → TLD → zone) is a clean example of how to do hierarchical signing.

DoH and DoT#

Even with DNSSEC, plain DNS is unencrypted. Anyone on the path between you and your resolver can see what names you're looking up. Two protocols address this:

• DNS-over-TLS (DoT) (RFC 7858) runs DNS over TLS on port 853.
• DNS-over-HTTPS (DoH) (RFC 8484) runs DNS over HTTPS, typically on port 443.

DoT is the cleaner choice for system-wide configuration — it's a dedicated port, easy to firewall, easy to monitor. DoH is the better choice when you need DNS to look like ordinary web traffic to get through a restrictive network, which is why browsers default to it for their own internal resolution.

Neither DoT nor DoH authenticates the contents of the answer — they authenticate the transport. You still need DNSSEC for that. The two are complementary, not substitutes.

A Practical Hardening Checklist#

When I audit a network's DNS posture, the questions I work through are roughly:

1. Do the recursive resolvers in use support DNSSEC validation, and is it enabled?
2. Are stub resolvers using DoT or DoH where the network allows it?
3. Are authoritative zones signed with DNSSEC, and is the DS record published in the parent?
4. Are SPF, DKIM, and DMARC TXT records present and aligned for mail-sending domains?
5. Are PTR records in place for outbound mail servers? (Many receivers will reject mail without one.)
6. Are TTLs reasonable? Very long TTLs make emergency changes painful; very short ones turn DNS into a stealth control plane.

Closing Notes#

DNS is one of those systems where the fundamentals — hierarchy, delegation, caching, TTLs — explain almost everything you'll see in practice. Once those click, debugging weird resolution behavior goes from "I'm guessing" to "I'm following the chain." The security extensions (DNSSEC, DoT, DoH) make much more sense once you can separate transport integrity from data authenticity from confidentiality on the wire.

If you want to go deeper, the canonical references are RFC 1034 and RFC 1035 for the original protocol, the DNSSEC RFC bundle for signing, and the PowerDNS documentation for a well-written operational view from a real authoritative + recursive stack.