HayamiYour Tuesday afternoon, fixed
DTM is one product, but teams reach for it for very different reasons. Here are the ten we hear most, and what each one looks like in practice.
Region outages · Canary releases · One name at a time · Active Directory · DNS as code · Private Endpoints · Authenticated probes · Retire the pets · DR drills · Ephemeral environments
Survive a region outage without waking anyone up
North Europe degrades and the failover plan is a wiki page: someone edits records by hand, waits for TTLs, and hopes they picked the right IPs. Azure gives you nothing that health-checks and steers private traffic across regions: Traffic Manager is internet-facing only, and Azure Private DNS will point at a dead IP until a human changes it.
With DTM, the plan is the default behavior. Probes fail within seconds, the unhealthy backends drop out of the answer, and every client quietly resolves to the surviving region. No runbook, no record edits, no 2am page. When the region comes back, traffic drifts home on its own.
Canary and blue/green, driven from your pipeline
Cutting over between blue and green behind private endpoints usually means editing DNS by hand at deploy time, or standing up a gateway per app just to get weighted routing. There is no way to say “send 10 percent to the new build” for a private name, let alone from CI.
DTM makes the canary part of your deployment automation, controlled by the same IaC that ships the build. One Terraform apply (or one REST call) sends 10 percent of clients to the new build; the next makes it 50, then all of it. A weight of zero keeps the old build warm and health-checked, ready for an instant rollback. Health checks still gate every answer, so a failing canary drops out on its own. Answers are cached by resolvers, so treat the split as steps, not precise percentages, and keep TTLs low.
Adopt it one name at a time
Your DNS estate already works, and re-homing whole zones to make one API endpoint resilient is exactly why “do nothing” keeps winning. So don’t migrate.
Point DTM at your existing zone as a forwarder, override the one name that keeps paging you, and give that name health checks and cross-region failover this afternoon. Every other name resolves exactly as it did yesterday, and removing the override hands the name straight back: adoption is reversible in one call. When you’re ready for more, bring zones in properly with the dry-run import.
Runs alongside Active Directory
Your domain controllers own the AD zones, and nothing is allowed to put domain join, logons, or client registration at risk. So any tool that wants to take over your DNS is a non-starter, and the application zones never get health checks or failover.
DTM does not touch the AD zones. The domain and its service records stay authoritative on your DCs, Windows registration carries on exactly as before, and DTM conditionally forwards those zones straight to the domain controllers. Everything else is DTM’s: the application zones get health-checked load balancing, cross-region failover, and canary weights, and non-Windows hosts (Linux, Kubernetes) register in with standard dynamic DNS. This is coexistence by design: DTM is not a replacement for the DNS role on a domain controller, and never needs to join the domain.
More ways teams use DTM
DNS and traffic policy as code, drift-free
Records, health checks, failover order and canary weights live in a repo, ship through a pull request, and apply with a plan you can read. Out-of-band edits show up as drift and the next apply puts them back, a scoped CI role keeps pipelines least-privileged, and the audit log records the rest. Service-account tokens and secrets are write-only, minted at apply time and never written to Terraform state.
Private Endpoint DNS that stays correct by itself
DTM watches your subscription (read-only, always) and keeps privatelink records matched to your actual Private Endpoints. Tag a VM or scale set with a name and it appears in DNS on the next discovery cycle, and disappears when the VM does.
Health-check the backends behind auth
Stop exposing an anonymous health endpoint just so something can probe it. DTM probes sign in like a real client: OAuth2, mutual TLS, or the VM’s own Azure identity with no credential stored anywhere. If the probe cannot authenticate and get a healthy answer, the backend gets no traffic.
Retire the pet DNS servers
Export your zones from Windows DNS or BIND (any standard zone file works), preview the diff, import, and point your VNets at the cluster: clients get normal DNS from day one. What changes is everything around it: no single point of failure, zero-downtime rolling upgrades, sign-in with Microsoft Entra ID, and an audit trail for every change.
DR you can rehearse, not just document
Most of the DNS chapter of your DR runbook becomes DTM’s default behavior. DTM schedules its own backups, with an off-node copy in your storage account; restore is staged, then promoted atomically with a rollback copy kept. Drill it quarterly in minutes.
DNS for environments that live for a day
An environment that creates itself should name itself. Records are born in the same Terraform apply as the VMs they point to, AKS services publish their own names with standard tooling, and when the environment dies, its DNS dies with it.
See it against your own traffic
Start with one name this afternoon, or deploy the full cluster.
Questions? Email us.