Configuring Azure DNS: where manual zone management causes failures
In practice, Azure DNS configuration often comes down to the portal: records are added by hand, changes are made directly in production, and the change history remains in chat threads and someone's memory. While there are ten services, this is tolerable.
When there are several zones and different teams work on them in parallel, a change becomes irreversible: a second engineer overwrites the first engineer's result, and there is no way to restore the previous state — there is nothing to compare against.
A separate problem is stale records. A service has moved to a new load balancer, a staging environment has been decommissioned, an address has been released, but pointers to the old address remain in the zone: someone forgot, someone did not know that this was their area.
Clients and internal services continue to follow the outdated route until the TTL expires, and some requests go to someone else's resource and return an unexpected response.
The most unpleasant part is how this manifests. Name resolution failures look like application errors: there are outages, but not for everyone and not always, they are difficult to reproduce, and troubleshooting starts with the code, not with the zone.
Private zones linked to not all virtual networks produce different behavior in neighboring subnets — from one service the name resolves, from another it does not.
The cost is service downtime that users notice, and hours spent searching for the cause in the wrong place.
We will break down how this is addressed: how zones are moved to code-based description, alias records are created, and private zones are linked to networks so that name resolution stops being a manual operation.
The effect of managed zones: speed of changes and a class of failures that disappears
A change in a managed Azure DNS zone takes effect within minutes: the change travels along the same route as the rest of the configuration and does not require waiting for a maintenance window.
The time to apply changes stops depending on which on-call engineer is at the panel right now — the record set is deployed the same way both day and night, and the differences between staging and production remain only in variable values.
Automatic failover is built on alias records: they point not to a hard-coded address but to a service with health checks.
While the node responds, traffic goes to it; if it stops, the zone returns the address of the backup path without manual intervention or a call to the on-call engineer. Previously, such a move took tens of minutes and depended on someone noticing the problem in time.
A separate effect is the audit trail of changes. Every record change is logged: who changed what and when, and which branch the configuration came from.
This eliminates the classic argument "it was always like that": the zone history reads like a journal, and reverting to a previous revision takes one operation instead of restoring from memory.
The share of manual errors drops primarily by abandoning edits through the panel.
Records are described declaratively and are checked for conflicts and duplicates before applying, so a typo in an address, a missing dot at the end of a name, or an incorrect record TTL stop being a source of incidents — they are caught by automated validation, not by users.
In total, this moves the zone from a "handle with care" mode into an ordinary managed resource where changes are predictable in timing and reversible.
Zone placement patterns: public, private, hybrid
The placement pattern is chosen based on who should see the names.
A public zone serves external services and domain ownership verification; a private zone serves requests between nodes and managed services inside the network; a hybrid pattern covers the case when the storefront faces outward, while databases and internal interfaces resolve only from inside the perimeter.
| Option | When it fits | Restrictions |
|---|---|---|
| Public zone | External services, domain verification, records for partners | Names are visible from the internet; internal addresses must not be published |
| Private zone | Requests between nodes and managed services inside the network | Resolves only from linked virtual networks; from outside there is no name |
| Hybrid pattern | Some names outward, some only internally | Identical names in two zones must be separated, otherwise the answer depends on the query point |
Aliases to external services, load balancers, and distribution endpoints work on top of any of the patterns: the record references a resource, and the address is substituted automatically, so changing the entry point does not require manually editing the zone and does not leave "stuck" names.
A key detail of the hybrid pattern is linking the private zone to virtual networks. Without it, the name simply does not resolve, and an extra link exposes internal names to neighboring environments, so the list of networks is fixed and checked with every topology change.
Workflow: from record inventory to handover of management
We structure the workflow so that no switch remains without a rollback point. First we capture the current state of zones in Microsoft Azure, then we build a dependency map, and only after that do we change records — one at a time, with validation at each checkpoint.
Sequence
- Zone audit. We export all zones and compare the record set with actual traffic: where static addresses duplicate an alias to an external service, where TTL is too high and the resolver cache keeps the old value for days. The output is a list of discrepancies for each zone.
- Service dependency map. We mark which applications and external contractors read the zone, who references the apex, and whose internal names resolve through the private zone. The map shows what will break if a record goes away.
- Pattern design. We categorize records by purpose: alias to the load balancer instead of static addresses, private zones for internal services, and node auto-registration rules.
- Configuration. We migrate records in stages, after lowering the TTL beforehand, so that an address change happens predictably rather than stretching over a day.
- Validation at checkpoints. We compare responses from several resolvers, separately checking private name resolution from inside the network and behavior when the target service is unavailable.
- Switchover plan. We fix the order of changing NS records, the work window, the responsible person, and the rollback criterion — by which signal we return to the previous configuration.
- Change acceptance and handover. Access roles instead of shared credentials, zone configurations in the repository, and a short guide for typical changes. We accept the result together with your team so that the zones can be maintained without us afterward.
Handover package: zone configurations, diagrams, change procedures
Changes in DNS live longer than the contractor: zones, records, and permissions remain in your tenant — and the knowledge must remain with them.
That is why we hand over not portal access but a reproducible set of artifacts that an engineer on your team can use to reproduce the current state and make a change without us.
- Zone configurations as code: public and private zones, alias records to resources, links to virtual networks — the state is restored from the repository, not from memory.
- Name resolution diagram: where internal names end and external ones begin, and how this affects requests between services.
- Record ownership map: each zone and critical record has an owning team and communication channel, so that during an incident no one has to look for who is to blame.
- Access policies: who reads zones, who changes them, where credentials are stored, and what to do when an employee leaves.
- Roles for changes: read access is open to engineers, changes go through an approved channel with review; portal changes outside the procedure do not pass.
- Change procedure: steps from request to publication, validation in a non-production zone, the apply window, and the rollback procedure.
- Log and acceptance checklist: what is checked after each change, where the history is stored, and who records the reason for the change.
Handover is complete when your team independently adds a record, verifies its resolution, and rolls back the change. This is the criterion by which we deliver the work.
Implementation case study: change timelines, share of manual errors, failures
Azure DNS zones lived in a web panel: an engineer edited a record by hand and attached a screenshot to the ticket. One change cycle — from request to confirmation — took an average of two days and involved three approvers.
What cost more was not speed but predictability. About a third of on-call shift requests were due to manually made changes: a typo in a record name, a lost record set, or a pointer deleted by mistake. There was no change history, so recovery stretched over hours.
What we changed
Zones moved to the repository and are described declaratively: alias records reference resources directly rather than intermediate names, private resolution zones are linked to their virtual networks, and any change passes validation before applying. A change became a merge request — with an author, history, and one-pass rollback.
- Time to make a change: two days → 20 minutes.
- Share of incidents from manual changes: a third of requests → isolated cases.
- Recovery time: hours → minutes, rollback to the previous state.
"Keeping records in the repository turned out to be calmer than in the panel: you can see who changed the zone and why. There is nothing left to argue about in planning meetings," — infrastructure lead on the customer side.
What remains is to clean up the old zones that did not make it into the first wave of migration. We migrate them without stopping name resolution.
How does DNS delegation differ from zone migration?
Domain delegation changes who is responsible for the names: records are edited at the registrar to indicate which name servers serve the zone.
Zone migration is moving the record set itself between name servers or accounts, and the point that the parent zone refers to may remain the same.
This leads to the difference in work: in the first case, the request route changes; in the second, only the content served along that route changes.
The scope of responsibility in delegation is broader: we begin to authoritatively serve the entire zone — the SOA record, the set of name servers, all subdomains, and ownership verification records.
During migration, we are responsible for the completeness of the migrated set: if a mail domain record or ownership verification record is lost, the domain will continue to resolve, but email and external services will fail. Therefore migration is always accompanied by comparing the export before and after.
Confusing these tasks in a plan is dangerous because their order is reversed in meaning.
First the zone is brought up in the new location and checked by querying from external resolvers, then the caching period is lowered, and only after that are the name servers changed at the registrar.
If you delegate before the zone is ready, the domain returns empty answers for the entire lifetime of the previous record in provider caches. If you migrate the records but do not delegate, requests still go to the old name servers, and no one will see the changes.
Rollback for these stages is also different. Delegation is rolled back by returning the previous name servers at the registrar — the action takes minutes, but propagation takes hours.
Migration is rolled back by restoring the previous record set, and here the zone export taken before the changes saves you.
In Azure DNS, both operations are performed with different tools, so in the work plan we separate them as distinct stages with their own checkpoints and completion decisions.
Technical concerns: private zones, aliases, limits
Before the first change in a production zone, the same five questions come up — from isolating private zones between networks to permissions to change records. Below are short answers so you can address this during planning rather than at the moment of migration.
Can one zone serve several networks?
Yes: virtual network links are added to one private zone. Name auto-registration is enabled on only one — otherwise machine records overwrite each other — and separate subzones are used for isolation.
How do you migrate an already deployed zone?
Export to a zone file, import into Azure DNS, compare SOA, NS, and previous CNAMEs. One day before the switchover, we lower the TTL, change the NS at the registrar, and keep the old zone available for rollback until traffic converges.
Why use an alias if there is CNAME?
An alias references a resource, not a name: the address is picked up automatically when the resource is recreated, and it is allowed at the zone apex, where CNAME is prohibited. The restrictions are Azure resources only and the overall limit on record sets and requests.
Who gets permission to make changes?
We assign the role to a specific zone, not to the subscription. Changes go through the infrastructure description in the repository, a delete lock is placed on the zone, and all changes with their author are visible in the activity log.
What happens to a zone during a region failure?
Public zones are global and are not tied to a region. For private zones, the network link is regional — resolution at the affected site will disappear, so we keep links in the backup region in advance.
Let's discuss the task: we'll review your zone pattern and come back with a plan
Configuring Azure DNS rarely comes down to adding a couple of records: the zone pattern, delegation, and the connection of public and private zones to services matter more.
To make the zone pattern review take one conversation rather than a week of back-and-forth, it helps to gather a few inputs in advance — based on them, we will come back with an estimate and a work plan.
- List of domains and zones: what is public, what is private, where each zone is currently hosted, and who manages delegation.
- Current record table: A, CNAME, TXT, MX, and everything that must remain unchanged after migration.
- Where alias records are needed: zone apex, load balancer, content delivery endpoint — and which resource each of them should track.
- Private zones and their links to virtual networks: which names resolve only internally and which networks should see the same zone.
- Switchover order: which environment we consider test, in which window changes are allowed, and how quickly rollback will be required.
- Access: subscription, role in the management panel, login to the registrar for changing name servers, and access to the environment where the target services live.
If some data is missing, that is not a reason to postpone the conversation: gaps in the pattern are usually the source of risk. Describe the task in free form, and we will come back with a scope estimate, work order, and clear timelines.