DNS Records Explained

What you are actually changing when you edit DNS

A DNS zone is the complete set of records for your domain, held on the authoritative nameservers a resolver will eventually ask. Every record has a name, a type, a TTL, and a value. Editing one changes what those servers hand out from that moment. Nothing is pushed anywhere.

That explains a failure more common than it should be: editing records in a registrar's DNS panel while the domain's nameservers point at a different provider. The edits save cleanly and nothing changes, because you have edited a zone nobody is reading. Confirm which nameservers are delegated for the domain before you start debugging a record.

Every record is the same shape with a different value

A record has a name, a class, a type, a TTL, and a value. Class is a historical field, always the internet class in ordinary use, and most panels never show it. Name, type and TTL behave identically whatever the record is. Only the value differs, and only in grammar: an address for A, a preference number and a hostname for MX, a priority, a weight, a port and a target for SRV, free text for TXT, whose meaning is set by whatever reads it rather than by DNS. Learn the shape, and an unfamiliar type asks one question only.

One rule cuts across every type. In zone-file syntax a name without a trailing dot is not fully qualified, so the zone origin is appended: a mail target entered as mail.provider.com becomes mail.provider.com.example.com, and inbound mail fails. Most control panels normalize that; raw zone-file interfaces and APIs do not.

The zone and the delegation are one level apart

Two sets of NS records exist for every domain. The delegation is the set the registry publishes in the parent zone, telling resolvers which servers are authoritative for your domain; you set it through your registrar. The zone is everything inside it — the SOA, your own copy of the NS records, and every record you have created — and it sits on whichever DNS host those nameservers belong to.

Changing nameservers changes the delegation and nothing else: not your records, not the registrar, not the registrant, and not the renewal date. Point a domain at a new DNS host before rebuilding the zone there, and the site and the mail go down the moment resolvers pick up the new delegation, because the old zone file is not migrated for you. The two sets should agree; when they do not, the result is a lame delegation, in which resolvers give inconsistent answers depending on which set they consulted.

That distinction decides who can fix a problem: a wrong delegation only at the registrar, a wrong record only at the DNS host.

Most zones need four or five of the eleven types

Eleven record types is not a checklist. A working site with hosted mail needs address records for the names people visit, an alias for www or a platform subdomain, MX records aimed at the mail provider, and a few TXT records carrying SPF, DKIM and DMARC. The SOA and the in-zone NS records are generated for you. That is four or five types doing the work.

The rest exist for specific jobs, and can be ignored until one is yours. CAA constrains which certificate authorities may issue for the domain. SRV is how SIP, XMPP, LDAP and Microsoft services locate a server. PTR is reverse DNS for a sending mail server, and does not live in your zone at all. AAAA belongs to sites that genuinely operate IPv6. A wildcard answers for names you have not listed.

Adding a type you do not need is not free: an AAAA record for a host whose IPv6 stack is not serving the site breaks it for the clients that prefer that answer while the site looks healthy over IPv4, and a CAA policy omitting the automated authority behind your CDN breaks a renewal months later.

TTL, and why propagation is a myth

TTL is a per-record field, set by the authoritative server, telling a caching resolver how many seconds it may reuse an answer before asking again. RFC 2181 defines it as a 32-bit unsigned value between zero and 2,147,483,647 seconds, and requires every record in a single record set to share the same TTL.

The claim that DNS propagation takes 24 to 48 hours is folklore, and it is expensive folklore. DNS does not propagate, because nothing is pushed anywhere. Authoritative servers update essentially instantly; what takes time is the expiry of answers already cached by resolvers, and the upper bound on that delay is the TTL that was in force on the old record when each resolver cached it. The figure is a rule of thumb inherited from an era of much longer default TTLs, and believing it makes people wait when they should be diagnosing.

The consequences are predictable:

• If the old A record carried a 300-second TTL, the change is fully live within five minutes of the last resolver that cached the old value.
• If it carried an 86,400-second TTL, no amount of impatience shortens it, and lowering the TTL after the change does nothing for resolvers already holding the old answer.
• Different users seeing the change at different times is normal rather than a fault; they sit behind different resolvers with different cache states, and resolvers may clamp very long or very short TTLs to their own bounds.

Negative caching runs on a separate clock. When a resolver asks for a record that does not exist, the NXDOMAIN or NODATA answer is itself cached, governed by the SOA MINIMUM field. This is why a newly created record can appear missing while being perfectly live: the resolver cached the absence. RFC 2308 notes that values of one to three hours work well and that values exceeding a day are problematic.

How to migrate without an outage

Because the only clock that matters is the TTL already in force, a migration is planned backwards. Lower the TTL on the records you intend to change. Wait out the old TTL, so every cache holding the record has picked up the short value. Make the change. Raise the TTL again once things have settled. A record sitting at a day needs a day of waiting before the short value is universal, and skipping that step is what turns a five-minute change into an afternoon of partial outage. Advice from the 1990s does not help here: RFC 1912 recommends minimum TTLs of three days or more, with one to two weeks on NS and MX records, which reflects the bandwidth economics of 1996 rather than modern operations.

Two further rules prevent most migration incidents. Build the new zone completely at the new provider before pointing anything at it, because changing nameservers does not move your records. And if the domain is signed with DNSSEC, remove the DS record at the registrar and wait out its TTL before moving, then re-sign afterwards; a signed zone whose keys no longer match the published DS record fails closed rather than degrading gracefully.

Reading a symptom back to the record behind it

Troubleshooting starts from a symptom, not a record. Identify which name and type it implicates, then whether the record is wrong or merely stale.

• The site loads the wrong thing, or nothing. Address records for the name in the address bar, or the alias in front. Check the apex and www separately; asymmetry is the usual shape of this fault.
• Mail is not arriving. The MX records. If mail arrives but is rejected or filed as spam, look at the TXT policy records instead, or the reverse record held by whoever owns the sending address.
• A certificate will not issue. CAA, at that name or any level above it short of the root, since the search climbs the tree.
• One subdomain fails while the rest of the zone is fine. Either the name is genuinely absent, a resolver cached the fact that it was, or an alias on that name is suppressing other data there.
• Nothing works, mail included. Stop reading records. A whole-zone failure points at the delegation, an expired domain, or DNSSEC failing closed.

Then the second question. A wrong record looks wrong when you query the authoritative nameservers directly; a stale one looks correct there and wrong through a resolver, and corrects itself when the old TTL expires. Settling that first prevents the secondary incident: editing a good record over and over while waiting out a cache.

What a public DNS lookup will and will not show you

A public lookup tool queries a resolver, or several, and reports what came back. That tells you what those resolvers currently hold, which is useful for confirming a change has taken effect and for spotting a cache still serving an old value. It is not a view of your zone.

What it will not show falls into three groups. First, records your authoritative servers hold that nobody has asked for yet: absence from a lookup tool is not absence from the zone. Second, anything served by a split-horizon configuration, where a zone deliberately returns different answers to internal and external queries so that staff on the corporate network reach an internal address while the public sees another. A public lookup only ever sees the external view. Third, and most often mistaken for a DNS fault, caching close to the user: operating systems, browsers and home routers all cache answers, and a hosts file entry overrides DNS entirely. When a change is correct on a public checker but wrong on one laptop, the problem is that laptop.

To see what your zone actually contains, query the authoritative nameservers listed in the domain's delegation directly rather than a resolver. That answer is the record as published, unfiltered by anyone's cache, and it is the only view that reliably distinguishes a misconfigured record from a merely stale one.