Editing the DNS zone for one site without disturbing the others
Screen walkthrough with on-screen captions, no narration. Plays on this page, muted, no sign-in needed. Every name, address and figure on screen is an example.
Editing a DNS zone is a small action with an unusually wide blast radius. On a single site it is a mistake you notice in minutes. On a network of thirty, it is a mistake you notice when a client calls about mail, and by then you have forgotten you touched anything.
Know which zone you are in
The zone editor lists every zone the account can see, and zone names look alike in a hurry, particularly when your naming convention is doing its job. Before changing a value, confirm three things:
- The zone name is the site you meant, character for character.
- The record you are editing is the one that serves that purpose, not a similar one left over from a migration.
- Nothing else in the estate depends on this record. Shared mail routing and shared nameserver records are the usual surprises.
This sounds fussy until the first time you edit the mail record of the wrong client.
The records worth understanding before you touch any of them
| Record | What it decides | Getting it wrong looks like |
|---|---|---|
| A | Which address the name answers on | The site is the wrong site, or nothing at all |
| CNAME | That one name follows another | A subdomain that goes somewhere unexpected |
| MX | Where mail for the domain is delivered | Mail vanishes quietly, with no error anybody sees |
| TXT | Verification and mail policy | Mail is accepted but treated as suspicious |
The asymmetry is worth internalising: an A record mistake is loud and you fix it. An MX or TXT mistake is quiet, and quiet mistakes are the expensive ones.
Change one thing, then stop
The discipline that costs nothing and saves whole evenings: make one change, save, verify, and only then make the next. Batching four edits into one save means that when something breaks you have four suspects and no way to separate them.
Verification means asking the internet, not re-reading your own form. What you typed and what is being served are two different facts, and only the second one matters. How to confirm the difference is set out in Diagnostics.
Give propagation the respect it deserves
A saved record is not an effective record. Resolvers hold the old value for as long as the record's lifetime allows, so the honest sequence before a planned change is:
- Lower the record lifetime well in advance, and wait out the old one.
- Make the change.
- Verify from more than one vantage point.
- Put the lifetime back once you are satisfied.
Skipping the first step is why some changes appear to work for you and not for the client. The ordering for a move that depends on this is in Launch Playbooks.
What not to do in the zone editor
Two habits cause most of the damage. The first is deleting a record you do not recognise. Unknown records are usually somebody else's verification or mail policy, and removing them breaks something you were not thinking about. Leave them and find out what they are.
The second is fixing a nameserver problem inside the zone. If the domain is not using your nameservers, editing the zone here changes a file nobody is reading. That distinction, and how to tell which situation you are in, is covered in Nameservers and DNS.
Record what you changed
One line per edit: zone, record, old value, new value, date. It takes ten seconds and it is the difference between a rollback and an archaeology project. The same habit applied estate-wide is described in Running Your Estate.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.