DNS Change Checklist Before You Touch Production
DNS problems often become harder to diagnose because teams make more edits while they are already unsure what the current truth is. The safest first step is always to document the intended change and capture the current authoritative state before touching anything.
After the change is made, compare authoritative answers with responses from multiple public resolvers. If the authoritative data is correct but public answers differ, you are dealing with propagation or caching. If the authoritative data is wrong, keep the focus there before making more downstream assumptions.
Nameserver delegation, TTL expectations, and related records such as MX, TXT, CAA, or AAAA should also be part of the review when the change affects certificates, email, or service routing. Many DNS incidents come from partial migrations rather than from one obviously broken record.
A disciplined DNS checklist saves time because it reduces panic edits. Once you know what changed, what should answer, and which layer is disagreeing, the problem becomes much easier to solve calmly.
Also see Help Docs, About, Editorial Policy, Privacy Policy, and Terms.