What a zone file line contains
Every DNS record, whatever its type, is the same five things in the same order: an owner name, a time-to-live, a class, a type, and the data. Written out in the classic zone-file form it looks like this.
The five parts
| Part | Example | Notes |
|---|---|---|
| Owner | www.example.com. | The name the record is about. The trailing dot means fully qualified; without it the zone's origin is appended. |
| TTL | 3600 | Seconds a resolver may cache the answer. Often omitted, in which case the zone default applies. |
| Class | IN | Internet. In practice always IN; the alternatives are museum pieces. |
| Type | A | What kind of data follows. This is what people mean by "record type". |
| Data | 203.0.113.10 | The payload, whose shape depends entirely on the type. |
Almost every confusing DNS problem is a misunderstanding about one of those five, and most often it is the TTL or the trailing dot. The DNS record decoder splits a line into these parts and names each one, which is usually enough to see what is wrong.
A and AAAA: addresses
An A record maps a name to a single IPv4 address; an AAAA record maps it to an IPv6 address. Both can exist at the same name, and several of each can exist at once: a name with four A records is a crude but entirely standard way of spreading load, because resolvers rotate through the set.
The thing worth knowing is that A records say nothing about hosting in the sense people usually mean. An address may belong to a content delivery network, a reverse proxy or a shared host serving thousands of unrelated sites. Inferring a relationship between two domains because they share an address is one of the most common errors in this field, and behind a large CDN it is almost always wrong.
NS: delegation
NS records name the authoritative nameservers for a zone. They appear twice, in two different places, and only one of them is decisive: the copy in the parent zone is what resolvers follow, and the copy inside the zone itself is informational. When the two disagree, the parent wins and the zone's own claim is ignored.
This is the mechanism behind delegation, which has its own page. Nameservers and delegation covers what happens when the parent has no NS records at all: the state in which a domain is fully registered and resolves to nothing whatsoever.
MX: mail routing
An MX record names a host that accepts mail for the domain, with a preference number in front of it. Lower numbers are tried first, and equal numbers are load-balanced. The host named must itself resolve to an address, and it must be a name rather than an address: an MX pointing directly at an IP is invalid, and is rejected inconsistently enough that it usually appears to work until it does not.
Absent MX records do not mean mail is impossible: the standard falls back to the A record at the same name. This is why a domain with no mail configuration at all can still generate delivery attempts against its web server, and why a name intended never to send or receive mail wants an explicit null MX and an SPF record refusing everything.
TXT: verification and policy
TXT records hold arbitrary text, which in practice means they hold everything that needed a home and did not justify a type of its own. Three families dominate.
- Mail policy. SPF, DKIM selectors and DMARC all live in TXT records, and together they decide whether mail claiming to be from the domain is accepted. DMARC in particular is the record that tells receiving servers what to do when the other two fail.
- Service verification. Every provider that ever needed to confirm domain control asked for a TXT record, and most of them are never removed. The accumulated set is an unusually candid inventory of which services an operator has used — a toolchain, never a holder. Who is registered is a separate question, answered by the whois record and increasingly not answered at all.
- Certificate issuance. The ACME challenge that issues most certificates on the
web places a temporary TXT record, which is why an apparently pointless
_acme-challengeentry appears and disappears.
There is a length trap here. A single TXT string cannot exceed 255 characters, so longer values, DKIM keys in particular, are split into several quoted strings that are concatenated on reading. A key that has been split at the wrong point is syntactically fine and functionally dead.
CNAME: aliases, and the apex problem
A CNAME maps one name to another name. The resolver receives the alias, then starts again on the target. That indirection is useful and has one hard consequence: a name holding a CNAME may hold no other records at all.
Which is why a CNAME cannot exist at the apex of a zone. The apex necessarily holds SOA and NS records, so it cannot also hold a CNAME, and a provider that appears to offer one is doing something else underneath: flattening the alias at query time and answering with addresses. That mechanism works, but it is provider-specific rather than part of DNS, and it does not survive a move to a different provider.
SOA and TTL: the zone parameters
The SOA record is the zone's statement about itself: the primary nameserver, an administrative mailbox, a serial number, and four timers governing how secondaries refresh and how long a negative answer may be cached. It is the least-read record in most zones and the one that explains the most surprising behaviour, because the last of those timers decides how long "this name does not exist" is remembered. That timer is also why a domain that has been deleted keeps answering as though it were never registered for the whole of its redemption window: delegation is withdrawn at deletion, and the negative answer is then cached like any other.
Which brings the TTL back into focus, because caching is where DNS expectations break. A record with a TTL of 86400 seconds may be served from a resolver's cache for a day after you change it, and there is no way to force the cache to forget. The only real answer is planning: lower the TTL to a few minutes, wait for the old TTL to expire, then make the change, then raise it again. Skipping the first step is the reason so many migrations appear to half-work for a day.
