Azure DNS: configuring public and private zones, automation

Azure DNS fails silently: where the bottlenecks of zones and records are

Name resolution failure rarely looks like a complete outage: usually some clients still open the service, while others get a denial or go to an old address.

In Azure DNS, a record lives in a specific zone, and as soon as an edit is made manually in one console, the second zone — public or private — remains in its previous state. The gap accumulates unnoticed, then manifests at once as service unavailability for a particular segment.

Conflict between public and internal name resolution is the second bottleneck of a zone.

If the internal perimeter uses an external name, traffic goes outside, and divergence between records across perimeters turns into authentication failures and checks that do not pass for all networks.

Add orphan records here: addresses of decommissioned nodes whose names still point to a node taken out of service, and residual CNAMEs after migrations.

Manual edits in multiple consoles cause an accumulation of record errors that is invisible neither in monitoring nor in the change process.

Each record has its own TTL, its own values, its own author — and after a couple of months nobody can say which version matches the actual topology.

While the zone responds, the problem is not considered an incident, although the impact of an error in a record is the same as that of a failed release.

This is most noticeable with large TTLs: the old answer lives in resolver caches longer than the rollback takes, and service recovery stretches over hours.

Below we examine how this is closed — from a single source of truth for zones to checks that catch divergence before it becomes an availability failure.

What a well-built zone scheme delivers: speed, failures, control

A well-built zone scheme rests on one principle: public and private zones are described in one place and in one format, not assembled across management consoles.

A record changes through mandatory validation, and after apply it looks the same for everyone: name, type, TTL, resource binding, virtual network association.

This creates a single source of truth for names. Divergence between "how it is configured in the console" and "how it is written in the documentation" goes away as a class — there is nothing left to reconcile.

Reaction time to a record change is measured in minutes: the edit passes validation and applies automatically, without an approval chain and manual input.

A separate class of failures is divergence between public and private zones. A service inside the network resolves to a stale address because the record was updated only in one zone, while the second remained at its previous value.

When both zones in Azure DNS are generated from one description, such a failure becomes technically impossible, not "unlikely by agreement."

Recovery after a failure also stops being improvisation. The zone description is stored in a repository under version control, so the configuration is brought up by reapplying, not from the on-call engineer's memory.

Post-recovery reconciliation is automatic: name resolution checks from different networks confirm that the zones have returned to a working state.

Control is added by the same description: role-based access separation, a change log with author and reason, and checks that catch conflicting records before apply. Zone management becomes a routine, predictable operation, not a one-off feat with an unpredictable result.

Public and private Azure DNS zones: choosing the mode

In Azure DNS, the zone mode determines not convenience but who can resolve the name at all. A public zone answers queries from any resolvers and allows domain ownership verification.

A private zone lives inside linked virtual networks: outside, such names do not exist, but internal services get stable addresses and do not go outside.

Comparison of options

We choose based on the name resolution map: what queries from where, which networks are linked to the zone, whether automatic node registration is needed.

Then the process is described as code — otherwise manual record edits quickly diverge between external and internal perimeters.

Implementation stages: from zone audit to handover of runbooks

The order of work is fixed: each stage ends with a verifiable artifact, without which the next step makes no sense. In Azure DNS this is especially important — a record error is not visible immediately, but when some services stop resolving names.

1. Audit zones and records. Export all zones and records, verify A, CNAME, MX, and TXT types, TTL values, look for dangling links and duplicates. Separately record who makes changes now — manually via console or script.

2. Domain scheme. Consolidate the map: public and internal zones, delegation points, virtual network associations, who has the right to create records. The scheme is approved before changes in production zones.

3. Configuring records and access. Create zones and records strictly per the scheme, bring TTLs to unified templates, assign roles with least privilege, and enable change logging.

4. Automation. Create typical records via templates, changes pass through infrastructure as code with validation in a test zone before apply.

5. Name resolution validation. Compare responses from inside the network and outside against the reference export, wait for record propagation, separately test rollback to previous name servers.

6. Documentation handover and training. Hand over the change runbook, zone map, and rollback procedure, review typical tasks with the team on live examples.

After that, edits follow the runbook, not the engineer's memory: the change is reproducible, rollback is tested, and zone state matches documentation.

What remains with you: zones, records, policies, diagrams, runbooks

We do not leave behind a configured portal tied to a contractor. Everything that describes your public and private zones is in your repository and is deployed from it.

Zone state is rebuilt from scratch on a clean subscription, and the documentation explains not only what is configured but why exactly so.

• Zone and record configuration. Public zones with a full set of A, AAAA, CNAME, MX, and TXT and correct delegation via NS at the registrar; private ones — linked to virtual networks with automatic record registration enabled.
• Infrastructure descriptions in code. Modules from which zones are assembled repeatably: a run does not create duplicates or overwrite TTLs of records managed by another team.
• Relationship diagram. Diagram: what is delegated, which networks are linked to private zones, where the zone ends and the load balancer or external service begins.
• Access policies. Read and edit roles by team, access to private zones only from inside the network, edits bypassing the repository closed at the permissions level.
• Change runbook. Who approves a new record, in which branch it appears, what checks it passes before apply, and how an erroneous change is rolled back with one run.
• On-call shift instructions. Step-by-step check when a name is unavailable: delegation, resolver cache, record state — without searching for the responsible person in messengers.
• Inventory report. What was in the zones before work: dangling records, name conflicts, ownerless records.

Case: separating public and internal zone perimeters

The client came with a typical picture: one zone in Azure DNS served both external services and internal systems. Records of internal nodes lay in the same zone as public ones — an edit to the internal service address went into external resolution. This leaked topology outside and turned a routine change into an operation with a downtime window.

What was

Internal services resolved by public names, so the traffic route depended on the external resolver. An error in one record brought down both perimeters at once — the failure class was shared.

A routine record change took up to two hours of approvals, and work was scheduled in a night window.

What we did and what became

The perimeters were separated: the public zone remained for external services, and internal systems moved to a private zone visible only from the linked virtual network. The response began to depend on where the query came from, not on who last edited the record.

Changes went through a managed repository with syntax validation and change preview — a record enters the zone only after review.

• Downtime during planned change: from ~40 minutes to zero — edits apply without interrupting resolution.
• Incidents due to record overlap: from 5–6 per quarter to zero over the observed period.
• Time to change a record: from ~2 hours to minutes, including review.
• Rollback: return the previous version of the zone file instead of a manual edit in the console.

Separately fixed TTL for internal records — now the old record does not "stick" in cache for hours after an address change.

How does a private zone differ from a public one in the same domain?

The same domain name can be served by two zones: a public one — it answers any resolver from the internet, and a private one — it is visible only to linked virtual networks. Records in them are independent: an edit in the public zone changes nothing inside.

In Azure DNS these are two separate objects, and this is where the main confusion arises during maintenance.

Engineering subtlety: a private zone with a name already occupied by the public one cannot be linked to a network while the public zone still has a set of NS delegation records. The requirement is deliberate — otherwise external domain delegation breaks.

Then the fate of records is decided: with automatic registration enabled, machine addresses appear in the private zone automatically, but after decommissioning a machine they remain as garbage that must be cleaned up.

During name resolution, a client from a linked network receives an answer from the private zone, and if the record is not there — the query goes the usual path.

Therefore an internal name can suddenly resolve to a public address: the private zone did not give anything extra, there simply was no required record in it.

Divergences arise predictably: a record was changed in one zone and forgotten in the second; a decommissioned node remained in the private zone and returns a non-working address; the cache holds the old answer longer than the switchover takes. This is treated not by on-call vigilance but by a runbook.

We maintain both zones in one registry as a single entity, check the name with two resolvers — outside and inside the network — and align record lifetimes with the switchover scenario. Then divergence is caught by a check, not by post-failure investigation.

Common technical questions: delegation, cache, rollback

Changes in DNS almost never break at the moment of apply — difficulties begin at the intersection with resolver cache, delegation, and access separation.

Below are the concerns that most often surface before starting work on Azure DNS: how long to wait for edits to take effect, how to migrate without a downtime window, and what to do if a record went to the wrong place.

Can delegation be migrated without downtime?

Yes, through parallel operation of both sides. First we bring up the zone at the new location with all records and compare responses, then change the name server records at the registrar.

While the previous servers respond, the domain continues resolving, and divergence during the transition is closed by two-way synchronization.

How does partial record migration work?

We split the zone into meaningful blocks — web, mail, service subdomains — and migrate one at a time, comparing responses at each step. This localizes failure to one block and does not affect the rest of the zone, while migration timelines remain predictable.

What happens if a change is erroneous?

Rollback happens at the record level: previous values are saved, the return is one operation taking effect according to the same lifetime. Bulk edits are made with templates and scripts so rollback is reproducible, not assembled manually under pressure.

How to restrict access to internal zones?

Private zones are linked to specific virtual networks, so from an external network the name simply does not resolve. We assign rights with roles at the zone level, separating read and write, and maintain change history so that each value has a visible author and time.

Let's discuss your zone: we'll build the diagram and migration plan

To base the assessment on facts rather than guesses, it is enough to send a list of domains, the current name resolution provider, a list of internal zones, and access requirements between teams. This is enough to see the full picture and avoid follow-up questions during the analysis.

In response you receive:

• a zone diagram in Azure DNS — public and private, with subscription and virtual network associations;
• a delegation map: where the zone is exposed externally and where name resolution remains inside the perimeter;
• a staged record migration procedure, with rollback points at each step;
• a list of records edited manually — mail, verification, service records;
• scope of work and responsibility split between our engineers and your team;
• timelines by stage and conditions under which migration can be stopped without losing name resolution;
• an automation proposal: what we move into configuration-as-code description and what remains manual.

Then — a short review of the scheme with your team, clarification of private zone boundaries, and starting with the least coupled domain. Describe the task in a convenient form — we'll return with an estimate and plan.