A DNS zone can look like a short list of labels and values, yet each row answers a different question. An A record gives an IPv4 address. An MX record names the systems that accept mail. A CAA record limits which certificate authorities may issue certificates. Trouble starts when a change is evaluated as one isolated row even though the service depends on several records, provider settings, and cached answers. Reading DNS well means understanding both the individual types and the rules that govern how they may coexist.
Production zones combine address records, aliases, mail routing, delegation, service discovery, and policy data. Those records are related but not interchangeable. A web migration may change A and AAAA while leaving MX untouched. Moving DNS providers changes the authoritative NS delegation and usually the SOA data, even if every application answer remains the same. Adding a mail platform can require MX, SPF, DKIM, and DMARC work at several names. A useful review therefore starts with the service being changed, then traces every DNS record that service expects.
The most reliable evidence is a combination of the authoritative answer, one or more recursive answers, and a written description of the intended service. The authoritative server shows what the zone currently publishes. Recursive resolvers show what clients may still receive from cache. The service description explains whether the result is correct. DomScan can supply live DNS results and prior DomScan observations, but those observations are not a complete audit log of every zone edit. They are useful checkpoints for questions such as when a value was first or last seen.
Quick path: Use the DNS Lookup API to inspect the current record set. If the answer is unexpected, compare it with prior DomScan observations in DNS History and check the authoritative zone before concluding that a change occurred at a particular time.
Why record types matter in practice
A DNS resource record has an owner name, type, class, TTL, and type-specific data. The type tells the resolver how to interpret the data. The value `192.0.2.10` makes sense in an A record, but not as the exchange field of an MX record, which must name a host. Priority fields also have meaning only for types that define them, such as MX and SRV. DNS control panels often hide this structure behind forms, so a record can look plausible in the interface while expressing the wrong relationship on the wire.
Coexistence rules are a common source of mistakes. A name that owns a CNAME is an alias and should not also carry ordinary data such as A, AAAA, MX, or TXT records. An MX record points to a hostname, and that target needs usable address records rather than another alias. The zone apex must retain SOA and NS data, which is why a conventional CNAME cannot replace the apex. Some managed DNS products offer flattening or provider-specific aliases at the apex, but those features are not CNAME records as seen by a resolver.
- A and AAAA answer where traffic should go.
- CNAME answers which other hostname should answer on behalf of this name.
- MX and TXT often work together in modern mail operations.
- Authoritative context and history matter when a DNS answer changes unexpectedly.
How the main record types work
A and AAAA records return IPv4 and IPv6 addresses. CNAME redirects the lookup from one name to another canonical name. MX records rank inbound mail exchangers by preference value, where lower numbers are tried first. TXT is a general text carrier used by protocols and verification systems, including SPF, DKIM, and DMARC, although each of those protocols places its record at a specific name and defines its own syntax. NS records identify authoritative servers for a zone or delegation. SOA records describe zone authority and include the serial and timing values used by secondary servers.
Other types solve narrower problems. CAA publishes certificate-authority restrictions. SRV records describe a service endpoint with priority, weight, port, and target. PTR supports reverse mapping from an address-derived name to a hostname. DNSSEC adds record types such as DNSKEY, DS, and RRSIG so resolvers can validate signed data. These types should be reviewed in their protocol context. A CAA answer does not prove that every existing certificate was issued correctly, and a PTR name does not prove that an IP address is trustworthy.
Record names also define scope. A wildcard such as `*.example.com` can answer for otherwise nonexistent names, but it does not replace explicit records and it does not automatically cover deeper labels in every case. Delegating `app.example.com` with NS records creates a zone cut and moves authority for that subtree. Records below the cut must be managed in the child zone, while the parent retains the delegation. Many puzzling DNS incidents come from editing the right-looking name in the wrong zone.
Where teams usually get it wrong
Provider setup pages are usually written as if their service owns the hostname. Copying them literally can replace a record another service needs, create a second SPF record, or put an alias at a name that already has verification TXT data. The safer approach is to compare the requested record with the entire existing RRset at that name. For mail, also inspect the related names such as `_dmarc`, DKIM selectors, and the envelope sender domain. One green check in a vendor dashboard does not establish that the combined configuration is sound.
Another mistake is treating TTL as a property of the service rather than of a cached RRset. A low TTL does not clear answers already cached under the old, higher value. Different record types at the same name may also have different TTLs, so an A change and a TXT change can become visible on different schedules. Document the previous value, previous TTL, intended value, and rollback condition before a cutover. That gives support and engineering a concrete window for expected disagreement.
A more reliable operating model
Give every important hostname a service owner and an intended record pattern. For example, an application hostname may allow A and AAAA, while a verification name may allow only a provider TXT record. Review changes against that pattern rather than against a generic notion of valid DNS. Keep registrar delegation, authoritative DNS, and application routing as separate responsibilities even if one vendor supplies all three. This separation makes it clear whether an incident belongs to the registrar, the DNS host, the network, or the application team.
A practical workflow
Start a change by querying the exact name and type from the current authoritative servers. Record every value in the RRset, not just the first answer returned by a tool. Check the parent delegation if NS is involved, and inspect DNSSEC DS data at the parent before moving signed zones. Then prepare the new RRset, its TTL, a validation query, and a rollback value. If the change touches mail or certificates, include the protocol-specific checks that use the record rather than stopping at a successful DNS response.
After publication, query the authoritative servers directly and then query the recursive resolvers that matter to the service. A correct authoritative answer with an old recursive answer usually indicates caching. Different answers between authoritative servers point to a zone distribution or provider problem. A correct DNS answer with a failing application points beyond DNS. Keeping those cases separate prevents repeated zone edits from making an unrelated outage harder to diagnose.
Not every record needs the same alert. Changes to apex addresses, login hosts, MX, NS, DS, CAA, and mail-authentication TXT records can alter availability or trust and deserve prompt review. A short-lived verification TXT record may only need an expiry note. Wildcards need special attention because they can make an undeclared hostname appear configured. The alert policy should follow the service impact of the record, not the visual size of the edit.
What good monitoring looks like
A useful DNS alert includes the queried name, type, previous observed RRset, current RRset, authoritative server, observation time, and expected owner. It should distinguish additions from removals and preserve multiple values. For MX and SRV, the priority and weight belong with the target. For SOA, serial changes can show that a zone version moved even when the record under investigation did not. Without those details, an alert often creates another round of lookups before anyone can assess it.
History needs careful wording. A passive observation system can show that one answer was seen on Monday and another on Thursday. It cannot prove the exact edit time or rule out an intermediate value that nobody queried. Resolver caches can also preserve an older answer after the authoritative zone changed. Treat observations as evidence points, then confirm important timelines with provider audit logs, change tickets, and authoritative data where available. The distinction matters during incident response and legal review.
Where DomScan helps
DomScan's DNS Lookup API returns live records across common types, while DNS History shows record sets and events derived from DomScan observations. Domain Profile can add normalized RDAP registration context when the question extends beyond the zone. Use these views to compare evidence, but keep the limits clear: a live lookup is a point-in-time result, and observation history is not a provider change log. For a production edit, the authoritative DNS host remains the source for who changed what and when.
Independent references: Review RFC 1035 and Cloudflare DNS TTL Reference for baseline details and neutral operational guidance.
When a record looks wrong, write down the question it is supposed to answer. Is this name meant to route web traffic, receive mail, delegate authority, prove control, or publish policy? That question usually identifies the right type, the records that must coexist with it, and the team that owns the fix.