# DNS record monitoring: what to track and how to review changes By Track.Name Canonical URL: https://staging.track.name/blog/dns-record-monitoring DNS record monitoring compares observed DNS answers over time and highlights changes to the records you follow. Start with nameservers and the records supporting your website and email. Keep the record name, type, value, query source and timestamp together, then confirm unexpected changes before deciding whether they need action. ## Start with the records your services depend on Make a list of the names people and applications actually use: the main website, its `www` hostname, company email and any important service hostnames. Match each name to the person responsible for that service. This gives a DNS change alert somewhere useful to go. The basic record types serve different purposes. A and AAAA records hold IPv4 and IPv6 addresses; CNAME points to another name; MX identifies mail exchange servers; TXT carries text used by several verification and email-authentication systems. NS identifies nameservers. See the [DNS record reference](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/) for the individual formats. Use the inventory to decide what to observe. A website check alone does not verify the email configuration. A check of the root domain does not automatically tell you what is published at every subdomain. Keep the initial scope explicit. Write down the record names and types covered, what is outside the list and why. That makes later alerts easier to interpret and prevents a small monitor from being mistaken for a complete audit of the domain. ## Save a baseline with enough detail to compare it A baseline is a successful observation you can compare with later results. For each query, preserve the full name, record type, returned values, TTL, response status, source and timestamp. Record the entire returned set when a name has several values. Keep your desired configuration alongside the observed answer, with a clear label for each. One tells you what the team intended to publish; the other tells you what a particular query returned. A difference between them is a reason to investigate, not a reason to overwrite either record. When reviewing an alert, compare like with like. Check whether both observations used the same hostname, type and query source. Treat a reordered set of identical values differently from an added or removed value. Note a failed query separately from a successful query with a changed answer. You do not need a complex system to start. A structured change log with the old set, new set and observation times is more useful than two screenshots with no query details. ## Allow for caching when you investigate propagation A DNS edit is not visible to every observer at the same moment. TTL, or time to live, controls how long a record may be cached. Cached results help explain why queries made through different resolvers can temporarily disagree after an update. [Cloudflare's TTL documentation](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/) describes that relationship and notes that local caching can also affect when a change is experienced. For a planned migration, record the intended change time and the previous TTL before making the edit. Keep querying the same record through the same source so you have a consistent comparison, and add another source when you need to investigate disagreement. Label which answer came from where. Avoid writing 'DNS has propagated everywhere' based on a handful of successful checks. A more defensible completion note names the sources checked and the times when each returned the expected answer. That is specific evidence someone else can review if a user still reports a problem. ## Distinguish missing data from a failed lookup An empty-looking result can describe different conditions. `NXDOMAIN` indicates that the queried name does not exist in the DNS response. `NODATA` describes a valid name with no records of the requested type. `SERVFAIL` means the server could not complete the query because of a problem. These distinctions are defined in [RFC 9499, DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.html#section-3). Keep these outcomes separate in your monitoring notes. If a query failed, mark the observation unavailable and retain the last successful result with its timestamp. Do not convert a retrieval failure into a claim that someone deleted a record. The same discipline applies to domain availability. A DNS response and a registration record answer different questions; a missing web address is not sufficient proof that the domain can be registered. When that is your question, use the [registration monitoring workflow](/blog/taken-domain-monitoring). For service troubleshooting, record whether the problem affects one query type or several. This gives the service owner a more useful starting point than a generic 'DNS broken' message. ## Use a repeatable checklist for unexpected DNS changes When a change was not on the schedule, preserve the evidence before editing anything. A hurried rollback can make the sequence harder to understand or replace a legitimate change with an outdated configuration. 1. Confirm the exact domain, hostname and record type in the alert. 2. Compare the previous and current value sets, including observation times. 3. Repeat the query and record its response status. 4. Check the change calendar, deployment notes and DNS provider's available audit history. 5. Ask the responsible service owner whether the change was expected. 6. Test the affected service and record the actual symptom, if any. 7. Decide with the authorised owner whether to keep, correct or revert the configuration. For an owned domain, use the provider account you normally trust when investigating access or configuration changes. Avoid relying on links from an unfamiliar alert email. If you only observe a domain you do not control, your available action is to confirm and document the public change. Close the investigation with the outcome and evidence. An alert that remains unexplained should stay marked as unresolved, even when the website currently loads. ## Example: checking an email-provider migration Suppose a small company plans to move its email service. This hypothetical team records the existing MX answers, the intended replacement values and the person approving the switch. It checks the new provider's setup instructions before editing its DNS. After the change, one query source returns the new MX set while another still returns the previous set. The team keeps both observations and their timestamps, reviews the caching context and repeats the checks. It tests the actual mail service separately instead of treating an MX result as proof that every mailbox works. An alert later shows an unexpected third value. The team compares the change with its provider configuration and migration notes before deciding what to do. The investigation has a concrete question: does the published set match the approved setup? That question scales to website migrations and portfolio reviews. Maintain an intended configuration, collect comparable observations and attach each unexplained difference to a person who can resolve it. ## Pair DNS monitoring with checks of the actual service DNS monitoring is one view of a domain. Keep website responses, certificate observations and registration events alongside it so you can compare the timing when something changes. Avoid treating any single green indicator as proof that the whole service works. For a public website, follow DNS results with a request to the expected page and check the destination and response. For a certificate issue, review the hostname and certificate evidence. For email, use your approved service checks in addition to the DNS record comparison. Our [website uptime monitoring guide](/blog/website-uptime-monitoring) explains how to define what a successful web check means. Together, these records should help you answer a concrete incident question: what changed, when was it observed, and which user-facing service was affected? ## Frequently asked questions ### Which DNS records should I monitor first? Start with the nameservers and records supporting your important services: website addresses or aliases, mail exchanges and relevant TXT records. List the exact hostnames and record types so the coverage is clear. ### Does a DNS change always mean an incident? No. Compare the change with the intended configuration, scheduled work and provider history. Confirm the observation and test the affected service before deciding whether the change needs correction. ### Why do DNS checks sometimes return different answers? Caching and the query source can affect which answer you observe. Save the source and timestamp, compare equivalent queries and investigate persistent differences rather than declaring one global propagation time. ## Sources - [Cloudflare DNS record types](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/) - [Cloudflare Time to Live documentation](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/) - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.html)