<aside> 🧭

Module 02 · Resource Records, Zone Files & Reading a Domain

Module 01 gave you the shape of a record and exactly one type. This module gives you the rest of the types, the file they are written in, and — in Part D — the working recipes for the job you are actually handed: "here is a domain, tell me what exists under it and where it points".

🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)

Prerequisite: Module 01. You already know how to read a dig response, what the aa flag means, how TTLs count down, and how to tell NXDOMAIN from NODATA — all four are used constantly here.

</aside>

Part A · The anatomy of a record

A1 · The five fields, and why DNS thinks in sets

<aside> 🥚

The analogy. Think of a box of six eggs. You do not buy one egg out of the box — you buy the box. Every egg in it has the same date on the label, and when you replace it you replace the whole box.

DNS works the same way. That is why all the records of one type share a TTL, and why an automation script that "adds one record" through an API can silently throw the other five away.

</aside>

<aside> 📖

Official docs: RFC 1035 §3.2 — RR definitions · RFC 2181 §5 — Resource Record Sets · RFC 9499 — DNS Terminology

</aside>

Every record, of every type, has the same five fields. You met them in Module 01:

seamless.se.        60      IN      A       52.77.52.233
│                   │       │       │       └── RDATA - the value, format depends on TYPE
│                   │       │       └────────── TYPE  - what kind of record
│                   │       └──────────────── CLASS - always IN in practice
│                   └─────────────────────── TTL   - seconds this may be cached
└──────────────────────────────────── NAME  - the owner name

What Module 01 did not tell you is that DNS almost never handles one record at a time.

<aside> 🔑

The RRset is the real unit of DNS. An RRset is every record sharing the same owner name, class and type. When seamless.se has six MX records, those six are one RRset. DNS moves, caches, replaces and signs whole RRsets — never individual records inside one.

Three consequences follow directly from that, and they explain behaviour that otherwise looks arbitrary:

  1. Every record in an RRset must have the same TTL. They expire together because they are cached as one object. If you configure different TTLs, the server picks one and silently discards the others
  2. You cannot add or delete "one record". You replace the whole set. This is why provider consoles make you edit a multi-line text box rather than a single value, and why a careless API call that sends one A record wipes out the other five
  3. There is no order. The set is unordered; any rotation you see is the server or resolver shuffling on the way out </aside>

<aside> ⚠️

This is the single most expensive misunderstanding in DNS automation. A script that "adds an A record" through an API which takes the full RRset, but only sends the new value, has just deleted every other address for that name. It will look like it worked. It returns success. The outage arrives when the traffic that used to reach the other five servers stops.

</aside>

🧪 Exercise A1.1 — Find an RRset with more than one member and check the TTLs

dig +noall +answer seamless.se MX

🎯 Interview questions — Records and RRsets