Introduction to DNS

Every protocol covered so far in this module — FTP, SMTP, POP3, IMAP — has quietly assumed you already have an IP address for the server you want to reach. Nobody actually types 93.184.216.34 into a mail client. They type mail.example.com, and something turns that name into the address IP actually needs to route a packet. That something is the Domain Name System, and its entire job rests on a small, fixed set of record types, each one answering a different kind of question about a domain.

This article is about those record types and the file format that defines them — not about the step-by-step lookup process a resolver goes through to find an answer. That resolution walk, root servers through authoritative servers, belongs to its own module later in this course. What matters here is simpler and comes first regardless: what a DNS record actually is, what shape it has on disk, and which of the dozen-odd types you'll actually touch in practice.

Zones and zone files

A DNS zone is the portion of the domain namespace that one organization administers directly — example.com and everything under it, say. The records for that zone live in a zone file, a plain text file an authoritative name server (software like BIND or PowerDNS) loads and serves answers from. A simplified zone file looks like this:

$ORIGIN example.com.
$TTL 3600

@       IN  A       93.184.216.34
www     IN  CNAME   example.com.
mail    IN  A       93.184.216.35
        IN  MX  10  mail.example.com.
        IN  NS      ns1.example.com.
        IN  NS      ns2.example.com.

$ORIGIN sets the domain every unqualified name in the file is relative to, and $TTL sets a default caching lifetime for any record that doesn't specify its own. @ is shorthand for the zone's own root — example.com itself, with no subdomain. Every other line is one resource record: a name, a class, a type, and data whose shape depends entirely on which type it is. That trailing dot after example.com. matters more than it looks — it marks a fully qualified domain name, anchored at the DNS root, as opposed to a name still relative to $ORIGIN; leaving it off a name that should have it is a genuine, common zone-file mistake.

The common shape every record shares

RFC 1035 defines one format that every DNS resource record follows, regardless of type:

NAME    TTL    CLASS    TYPE    RDATA

NAME — the domain name this record applies to.
TTL — Time To Live, in seconds: how long a resolver may cache this answer before it's required to ask again.
CLASS — almost always IN (Internet); other classes exist in the standard but see essentially no real-world use.
TYPE — which of roughly a dozen record types this is: A, AAAA, MX, CNAME, TXT, NS, and several others this module doesn't cover individually because they're rarely hand-authored (SOA, PTR, SRV, and the DNSSEC-related types among them).
RDATA — the actual payload, whose format is entirely type-specific: an IP address for A, a domain name for CNAME, a priority number plus a hostname for MX, and so on.

That last point is the one worth internalizing before reading the individual record articles: the record type isn't a label slapped onto generic data, it's a contract about what shape the data itself takes. Trying to force an IP address into a CNAME record, or a domain name into an A record, isn't just wrong practice — the resolver literally cannot parse it as the wrong shape.

TTL: the caching lifetime attached to every answer

Every record carries its own TTL, and that number is doing real work in production, not just documentation. A resolver that already has a cached answer within its TTL window doesn't re-query the authoritative server at all — which is most of what makes DNS fast in practice, since the overwhelming majority of lookups for popular domains are served from a cache somewhere between the asking client and the authoritative server, not from a fresh query.

That caching has a direct, practical consequence the moment a record changes. Lower a record's TTL from an hour to five minutes before changing its value, wait for the old, longer TTL to fully expire everywhere, then make the change — and the new value propagates within minutes. Skip that step and change the value first, and any resolver still holding the old answer under its previous, longer TTL will keep serving stale data for however long that TTL had left to run, regardless of what the zone file says right now.

A very low TTL isn't free, at scale

Dropping a busy domain's TTL to something tiny — a few seconds — to "stay flexible" means every resolver worldwide re-queries far more often, which multiplies query volume against the authoritative servers and, for a high-traffic domain, can turn a minor operational convenience into a real load problem on the DNS infrastructure itself. A short TTL ahead of a planned change is a deliberate, temporary trade-off; a permanently tiny TTL on a record that rarely changes is usually just unnecessary load.

The record types this module covers

Six of the record types actually worth hand-authoring get their own dedicated article, in the order a working domain typically needs them:

A record — a domain name to an IPv4 address, the most common record type there is.
AAAA record — the same job, for an IPv6 address.
MX record — which mail server accepts email for this domain, tying directly back into SMTP's delivery process.
CNAME record — an alias, pointing one name at another name rather than at an address directly.
TXT record — arbitrary text, used in practice mostly for domain verification and email authentication.
NS record — which name servers are authoritative for this zone in the first place.
SOA record — the zone's own metadata: its primary server, its version number, and the timers that decide how long a wrong answer survives.
PTR record — the lookup run backwards, mapping an address to a name.
SRV record — a service's host and port, with priority and weight for failover.
CAA record — which certificate authorities are permitted to issue certificates for this domain.

Reading records yourself

dig is the standard tool for querying DNS directly and seeing exactly what a name server returns, bypassing any local cache with +trace or a specific server flag when needed:

dig example.com A

;; ANSWER SECTION:
example.com.        86400   IN      A       93.184.216.34

;; Query time: 24 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)

The answer section reproduces the exact record shape from the zone file above: name, TTL (here 86400 seconds, a full day), class, type, and the data itself. Each of the following six articles uses dig the same way, against the record type it covers, so getting comfortable reading this output now pays off six times over.