Change management
What is DNS change management?
DNS change management is the practice of validating a DNS change before it is applied, requiring approval where the risk warrants it, applying it in a recorded way, verifying the result resolves publicly, and keeping an auditable record of who changed what and why. It matters because DNS fails without an error message — a wrong record is usually valid DNS.
Every other risky thing an MSP does has ceremony around it. Firewall changes go through a change board. Server patching has a maintenance window. Backups get tested. DNS gets done at nine o'clock at night, in a provider portal, by whoever is free, with no second pair of eyes and no record beyond a line in a ticket that says DNS updated.
That would be survivable if DNS announced its mistakes. It does not. DNS returns an error when a record is malformed, never when it is merely wrong — and almost every outage-causing DNS change is perfectly well-formed.
How a change moves
Most of them exist because somebody, somewhere, skipped one at nine o’clock at night. Click along the rail.
DNSMentor reads every zone the account holds and every record in them. No agent, no zone transfer, no CSV. The credential is stored encrypted and stripped out of anything that gets logged or exported.
Templates cover the jobs you do weekly — Microsoft 365 in one action rather than nine. Where AI proposes records it shows its reasoning and its sources, and a person still has to look at it and press the button.
Not against the change in isolation — against the zone the change would produce. That is how a second SPF record gets caught: the record you typed is perfectly valid, and it is the one already there that makes it fatal. 27 rules block outright. The rest have to be read and accepted by name.
A diff of what the zone looks like now against what it would look like after — including the records you did not touch that stop resolving because of the ones you did.
Configurable per organisation and per engineer. A senior who has demonstrated the skill applies unsupervised. Somebody in their first week does not. The same platform, adapting to who is using it, rather than one setting for everybody.
The zone is read again immediately before the write, so a change somebody else made in the portal while this one sat in approval is not silently clobbered. If the provider rejects it, you get the provider’s own words, not a generic failure.
“The provider accepted it” and “the world can see it” are two different claims, and DNSMentor never merges them. Applied is one status. Live is another. Plenty of outages live in the gap between the two.
What changed, why, what was checked, who approved it and whether it is live — written out of the audit record rather than from memory at the end of the day. Paste it into the ticket.
The audit trail
Every entry is sealed against the one before it. Edit any field below and verify the chain — it will tell you exactly which entry was touched, and everything after it stops being trustworthy too. This is the same construction the product uses, running here in your browser.
Tip: try changing rejected to approved on entry 3, or putting a different name on entry 4.
Two-person approval is easy to describe and annoying to live with, which is why most teams switch it off. DNSMentor makes it survivable by making it proportionate.
A senior who has demonstrated the skill applies unsupervised. Somebody in their first week does not. One setting for everybody is what makes approval workflows get disabled.
A TXT record for a vendor verification is not an MX cutover. Policy can differ by record type, so the ceremony lands where the consequence is.
MX values always require a human to verify the target against the mail provider's own console. No skill level and no configuration removes it.
DNS change management is the practice of putting a controlled process around DNS record changes: validating a change before it is applied, requiring review or approval where the risk warrants it, applying it in a recorded way, verifying that the result is actually live in public DNS, and keeping an auditable record of who changed what and why. It exists because DNS changes are high-consequence and, unlike most systems, fail without producing an error.
Because DNS is usually the exception. Firewall changes go through a change board, server patching has a maintenance window, and backups are tested — but DNS is typically changed directly in a provider portal by whoever is free, with no second pair of eyes and no record beyond a line in a ticket. It is simultaneously the highest-consequence and lowest-ceremony change most MSPs make.
At minimum: automated validation of the proposed change against the existing zone, a clear statement of what will differ afterwards, an approver who is not the author for high-risk record types such as MX and NS, application through a recorded mechanism rather than a shared login, independent verification that the change resolves publicly, and a durable audit entry linking the change to a person and a reason.
You need evidence that changes are authorised, recorded and reviewable. DNSMentor produces this automatically: every action is written to a hash-chained audit trail where each entry is sealed against the previous one, so any alteration breaks the chain and verification reports exactly where. The trail is exportable per client, and training records show which engineers were competent to make the changes they made.
Yes, within DNSMentor any applied change can be reversed from the record of what it changed. The important caveat is DNS caching: a rollback is published immediately but resolvers hold the previous answer for the length of its TTL, which is why DNSMentor warns you to lower TTLs before a planned migration rather than at the moment of cutover.
Half an hour, your estate, your worst zone. If the checks find nothing you did not already know, we have wasted half an hour of your time and none of your money.
No card. No trial clock. UK-hosted, and we will tell you which providers we have actually proven before you ask.
Last updated