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.

A and AAAA: the address records

A maps a hostname to a 32-bit IPv4 address, which RFC 1035 defines simply as a host address. The most common mistake is asymmetry: creating the record for www but not the apex, or the reverse, so one form of the address resolves and the other does not. A close second is the stale A record left pointing at a decommissioned host after a migration, which produces it-works-for-me reports for as long as the old TTL survives in other people's caches.

AAAA is the IPv6 counterpart, mapping a hostname to a 128-bit address. It is defined in RFC 3596 rather than RFC 1035, and published alongside the A record for dual-stack reachability. Its trap is worse. Clients on IPv6 networks generally prefer the AAAA answer, so publishing one for a host whose IPv6 stack is not serving the site, or is firewalled, gives a subset of users slow or failed connections while the site looks perfectly healthy over IPv4. Publishing AAAA is a commitment to operate IPv6 properly, not a free extra.

CNAME, the zone apex, and the ALIAS workaround

A CNAME declares that a name is an alias and gives its canonical name. It is the right tool for pointing www at a platform-supplied hostname, or a subdomain at a SaaS endpoint, because the provider can change the underlying addresses without involving you.

The rule that catches everyone is that a CNAME cannot coexist with any other data at the same name. RFC 2181 frames it as an exclusive choice: a name has a single CNAME, or one or more non-CNAME records, or nothing. RFC 1912 states it in a line, that a CNAME record is not allowed to coexist with any other data. Because every zone apex must carry SOA and NS records, a CNAME can never sit at the apex, and that is a constraint of the protocol rather than of your provider. The same rule explains a quieter failure: a CNAME on a name that also needs MX or TXT records silently breaks them, because the CNAME wins and the other data is ignored.

Providers that appear to offer an apex CNAME are doing something else. ALIAS, ANAME and CNAME flattening are proprietary features in which the provider resolves the target itself and serves the resulting A and AAAA addresses from its own servers, so the apex appears to hold ordinary A and AAAA records. ANAME was an IETF Internet-Draft that expired in 2019 and was never published as an RFC; there is no standardised apex alias, and the draft itself notes that these proprietary mechanisms hinder serving the same data from multiple providers. Moving DNS host means finding that host's equivalent, or discovering it has none.

MX and TXT: the two records that break mail

MX records name the mail exchangers for a domain, each with a preference value; lower numbers are tried first. Preferences are an ordered fallback list, not weights and not percentages. Servers at 10 and 20 do not split mail evenly, they send everything to the first while it is reachable.

The defining MX mistake is pointing one at a CNAME. RFC 2181 states that the name used as the value of an NS record, or part of the value of an MX record, must not be an alias; doing it anyway causes extra queries and prevents address records being returned in the additional section. Two related traps: an IP address in the target field, where a hostname is required, and stale MX records for a decommissioned provider left alongside the new ones, quietly delivering a fraction of your mail to a dead server.

TXT records carry arbitrary text, and in practice carry almost nothing but policy and verification data: SPF, DKIM keys, DMARC policy, and ownership tokens. The most damaging mistake is publishing more than one SPF record. SPF requires that a domain must not have multiple records that would cause an authorization check to select more than one; only TXT records beginning with v=spf1 are candidates, and two or more produce a permerror. This is exactly what happens when a business adds a second mail or marketing vendor and pastes a second v=spf1 string alongside the first; the fix is a single record combining the include mechanisms. Note also that the terms triggering DNS lookups are capped at ten in total, which stacking vendors will exceed, and that long DKIM keys must be split into multiple strings within one record, never into multiple records.

One syntax trap belongs with MX in particular. In zone-file syntax a name without a trailing dot is not fully qualified and the zone origin is appended, so a target entered as mail.provider.com becomes mail.provider.com.example.com and all inbound mail fails. Most web control panels normalise this, but any interface accepting raw zone-file syntax, and any API, applies the rule.

NS and SOA: the records that define the zone itself

NS records identify the authoritative nameservers for a zone, and two sets exist: the delegation NS records published by the parent, meaning the registry, set through your registrar, and the NS records inside your own zone. They should agree. When they do not, the result is a lame delegation in which resolvers get inconsistent answers depending on which set they consulted. The alias prohibition that governs MX applies here too, so an NS target must not be a CNAME. Glue is only required when a nameserver's hostname sits inside the zone being delegated, and RFC 1912 warns that adding it just to make sure creates a maintenance problem the next time those addresses change.

SOA marks the start of a zone of authority, carrying the primary nameserver, the responsible party's email address written with the @ replaced by a dot, a serial number, and the refresh, retry, expire and minimum timers. There is one per zone and it is usually generated for you. Two fields cause real trouble. A serial that goes backwards stops secondary servers picking up changes, which is why RFC 1912 recommends the YYYYMMDDnn convention. And MINIMUM is the most misread value in DNS: RFC 1035 described it as a floor on exported TTLs, but RFC 2308 redefined it as the negative caching TTL. Set it high, and a record you have definitely created still returns NXDOMAIN.

CAA, SRV and PTR: the records with one specific job

CAA lets a domain holder declare which certificate authorities may issue TLS certificates for the domain. It is checked by the CA before issuance, and has been mandatory for publicly trusted CAs since 8 September 2017, when the CA/Browser Forum passed Ballot 187. The issue tag authorises named CAs, issuewild governs wildcards separately, and iodef gives the CA an endpoint for reporting requests that violate your policy. A policy set at the apex is inherited by subdomains unless overridden lower down. The common mistake is omitting a CA you depend on, often the automated one behind a CDN or hosting platform, and finding out when a renewal fails. The second is assuming browsers enforce CAA. They do not.

SRV records advertise the hostname and port of a service, so clients can locate a protocol without hard-coded ports. The format is an underscore-prefixed service and protocol label, then priority, weight, port and target; clients must try the lowest-numbered priority they can reach, weight distributes load among equal priorities, and a target of a single dot means the service is explicitly unavailable. SIP and VoIP, XMPP, LDAP and Microsoft services all use them. Mistakes cluster in three places: a CNAME in the target field, which the specification prohibits by requiring address records and no alias; malformed labels, such as _sip.tcp instead of _sip._tcp; and confusing weight with priority, so a supposedly balanced pair sends everything to one server.

PTR is the reverse-DNS record, mapping an IP address back to a hostname under in-addr.arpa or ip6.arpa. Its main use is mail, since many receiving systems check that a sending IP has a PTR record and that the name it returns resolves back to the same address. The mistake is near-universal on first encounter: you cannot create a PTR record in your own zone. Reverse zones are delegated to whoever controls the IP block, so reverse DNS is requested from your hosting provider, cloud vendor or ISP.

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.

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.