← Learn··Updated 21 May 2026·3 min read

What is DNS?

A short reference on the Domain Name System — the hierarchy, common record types, how a recursive resolver actually looks up a name, and the caching that keeps the whole thing usable.

Networking
#networking
#dns
#protocols

The one-sentence definition

DNS — the Domain Name System — is the protocol and infrastructure that translates human-readable names like mart.traagel.dev into the IP addresses that networking actually uses. Specified in RFC 1034 and RFC 1035 in 1987, still mostly unchanged in shape forty years later.

The hierarchy

DNS is organised as a tree, read right to left:

flowchart TD
    R["Root .<br/>(13 logical name servers, anycasted globally)"]
    T1["TLD: .dev<br/>(operated by Google Registry)"]
    T2["TLD: .com<br/>(operated by Verisign)"]
    AUTH["Authoritative for traagel.dev<br/>(operated by the domain owner)"]
    R --> T1
    R --> T2
    T1 --> AUTH

Every lookup ultimately walks the tree: the root tells you which servers know about .dev, the .dev servers tell you which servers know about traagel.dev, and the traagel.dev servers give you the actual record. In practice a recursive resolver caches each step, so most lookups never go all the way to the root.

The record types you actually meet

Record What it means
A Maps a name to a single IPv4 address
AAAA Maps a name to a single IPv6 address (four As because it is four times the size of an A record)
CNAME Aliases one name to another (cannot coexist with other records at the same name)
MX Mail-exchanger — who handles email for this domain, with a priority value
TXT Free-form text, conventionally used for SPF, DKIM, DMARC, domain ownership verification, ACME challenges
NS Which authoritative name servers are responsible for a zone
SOA Start of authority — admin metadata for a zone (serial number, TTLs, contact)
CAA Certificate authority authorisation — restricts which CAs can issue certs for the domain
PTR Reverse lookup — IP back to name

CNAME is the one most often misconfigured. It cannot exist alongside other records at the same name, which is why you cannot put a CNAME on a zone apex (the apex always has SOA and NS records). DNS providers work around this with synthetic record types like ALIAS or ANAME that look like CNAMEs but are resolved at the provider's side.

How a recursive lookup actually runs

When your laptop asks "what is the A record for mart.traagel.dev?" the lookup runs in roughly this order:

  1. The OS asks the local stub resolver (e.g. systemd-resolved or the OS DNS client).
  2. The stub resolver asks the configured recursive resolver (your ISP, 1.1.1.1, 8.8.8.8, or your homelab's Pi-hole).
  3. The recursive resolver checks its cache. If it has the answer with a fresh TTL, it returns immediately.
  4. Cache miss → the recursive resolver asks a root server: "who knows about .dev?" The root server returns the .dev NS records.
  5. Recursive asks a .dev server: "who knows about traagel.dev?" The .dev server returns the traagel.dev NS records.
  6. Recursive asks an authoritative traagel.dev server: "what is the A record for mart.traagel.dev?" The authoritative server returns the answer.
  7. Recursive caches every step it learned along the way, returns the answer to the stub, which returns it to the application.
sequenceDiagram
    participant App as Application
    participant Stub as Stub resolver (OS)
    participant Rec as Recursive resolver<br/>(e.g. 1.1.1.1)
    participant Root as Root server<br/>(.)
    participant TLD as .dev TLD server
    participant Auth as traagel.dev<br/>authoritative server

    App->>Stub: A? mart.traagel.dev
    Stub->>Rec: A? mart.traagel.dev
    alt cache hit
        Rec-->>Stub: cached A record
    else cache miss
        Rec->>Root: A? mart.traagel.dev
        Root-->>Rec: refer to .dev NS
        Rec->>TLD: A? mart.traagel.dev
        TLD-->>Rec: refer to traagel.dev NS
        Rec->>Auth: A? mart.traagel.dev
        Auth-->>Rec: A 203.0.113.42 (TTL 300)
        Note right of Rec: cache the answer<br/>plus each NS hop
        Rec-->>Stub: A 203.0.113.42
    end
    Stub-->>App: 203.0.113.42

Steps 4-6 are why caching exists. Doing them on every connection would be unworkable; in practice the recursive's cache absorbs the vast majority of lookups.

TTL — the load-bearing field

Every DNS record carries a TTL ("time to live"), in seconds, that says how long a resolver may cache the answer. A 300-second TTL means downstream resolvers will keep that answer for five minutes; a 86400-second TTL is a full day.

TTL is a trade-off: low TTL gives you fast failover and short propagation time when you change records, but each cache miss costs another full lookup; high TTL is friendly to the infrastructure but means stale answers persist longer when you update.

DNS over UDP, mostly

Classic DNS runs over UDP on port 53 for queries that fit in 512 bytes, falling back to TCP for longer responses. Modern variants — DNS over HTTPS (RFC 8484) and DNS over TLS (RFC 7858) — wrap the same protocol in an encrypted transport so that intermediaries cannot see or modify the queries.

A short caveat

DNS is famously cache-coherent only by convention. A change made at the authoritative server will not become globally visible until every recursive resolver's cache for that name has expired and been re-fetched. Counting on "I updated the record so everyone can see it now" is a common source of debugging mistakes — for the next TTL window, "everyone" depends on whose cache they hit.