Deploy into a hub-and-spoke network

This guide is for a team adding DTM to an existing hub-and-spoke network, including an Azure landing zone: a connectivity subscription with the hub virtual network (Azure Firewall or a network virtual appliance, gateways, central Private DNS zones), and application landing zones as spokes. It uses the same terms as the Cloud Adoption Framework.

DTM is an authoritative DNS server that health-checks the backends behind its answers. It runs on private IPs only, so placing it is a routing and DNS question, not an internet-exposure one. Start with the decision tree, then read the sections it points you to.

Find your starting point

1. Is outbound traffic forced through a central firewall or NVA? (a 0.0.0.0/0 route on spoke subnets)

Yes: DTM’s outbound traffic goes through that firewall, including the health checks it sends to backends in other spokes. Add the rules in outbound from the DTM nodes and read routing through a central firewall. Do not add a NAT gateway to the DTM subnet (why).
No, the DTM subnet has no outbound path: subnets in virtual networks created with current Azure API versions are private by default (no default outbound access). Region discovery, tag registration and Private Endpoint automation need outbound HTTPS, so see NAT gateways for when one fits.
No, the subnet has default outbound access: it works, but Microsoft recommends an explicit outbound method, so plan one.

2. How do workloads resolve DNS today?

The VNet DNS setting points at the firewall’s DNS proxy: use pattern 2.
Azure-provided DNS, with an Azure DNS Private Resolver for on-premises and forwarding: use pattern 3.
Custom DNS servers (domain controllers or DNS VMs): forward the zones DTM owns from them, as in pattern 4. You can also point the VNet DNS setting at DTM later (pattern 1).
You can change the VNet DNS setting to DTM: pattern 1 has the fewest moving parts.

3. Do you need answers to depend on the client's region?

Yes: clients must reach DTM directly, or through one forwarder per region. See which patterns keep per-region answers.
No (failover only): every pattern works. Health checks and cross-region failover do not depend on where the query came from.

4. One region or several?

One region: place the cluster in a shared-services spoke.
Several regions: run one cluster with nodes in each region’s shared-services spoke (per-region placement), as long as every node can reach every other node.

Where to place DTM

Every node in a cluster must reach every other node on port 7946 (TCP and UDP) and on TCP 8443. Clients must reach the nodes on port 53. Beyond that, placement follows your landing zone’s own rules.

Placement	Reached by	Peering and routing it needs	Trade-off
Shared-services spoke	Spokes through the hub; on-premises through the hub’s gateway	Spoke peered to the hub; spoke-to-spoke traffic routed through the hub firewall	The usual home for shared platform services; one more firewall hop for DNS
The hub	Every peered spoke directly; on-premises through the gateway	None beyond the existing hub peerings	Shortest path, but many landing zones keep the hub for connectivity resources only
Per-region spokes	Each region’s spokes through that region’s hub	As above in each region, plus node-to-node reachability between regions	Clients query a nearby node, and answers can follow the client’s region

A shared-services spoke (recommended)

Put the DTM subnet in a spoke for shared platform services, peered to the hub. Spokes are not transitively peered, so a workload spoke reaches DTM through the hub firewall or NVA:

the firewall must allow 53 (UDP and TCP) from your spokes and on-premises ranges to the DTM subnet;
each spoke’s peering to the hub, the DTM spoke’s included, must allow forwarded traffic, so traffic the hub firewall forwards is accepted;
to reach on-premises, the DTM spoke’s peering uses the hub’s gateway (use remote gateways), as your other spokes do.

The hub

Placing the nodes in the hub removes the firewall hop for spokes that are peered to it. Check your landing zone’s policy first: many restrict the hub to connectivity resources, and DTM then shares the hub’s change process and failure domain.

Per-region spokes (multi-region)

For a multi-region estate, place nodes in a shared-services spoke in each region and join them into one cluster. The nodes replicate peer to peer, so the two regions must route to each other on 7946 (TCP and UDP) and TCP 8443, through global peering or your hubs, with any firewall in the path allowing both in both directions. On the four-node, two-region Marketplace plan, the NSG already allows 7946 from both regions’ subnets. See deployment for the cluster-boundary rule: estates that cannot route to each other need a separate cluster each.

How DNS queries reach DTM

DTM answers the zones it owns, and sends every other name to its default forwarder, normally Azure-provided DNS (168.63.129.16). Azure-provided DNS answers from the Private DNS zones linked to the DTM nodes’ VNet, which matters for Private Endpoints (see Private DNS zones). The Private Resolver page has the full commands for patterns 1, 3 and 4.

Pattern 1: VNet DNS points at DTM

Set each spoke VNet’s DNS servers to the DTM node IPs. Clients query DTM directly, so DTM sees each client’s own address. Nothing sits between the client and DTM except routing, so this is the pattern with the fewest moving parts.

Pattern 2: Azure Firewall DNS proxy

Spoke VNets point their DNS setting at the firewall’s private IP. The firewall proxies the queries to its configured DNS servers. Set those to the DTM node IPs, so the firewall forwards to DTM. Microsoft requires the DNS proxy when network rules use FQDNs, so that the firewall and its clients resolve names the same way.

DTM sees the firewall’s address, not the client’s.

Pattern 3: Azure DNS Private Resolver

VNets stay on Azure-provided DNS, and a forwarding ruleset sends the zones DTM owns to the DTM node IPs through the resolver’s outbound endpoint. On-premises clients reach the same rules through the inbound endpoint. DTM sees the outbound endpoint’s address.

Pattern 4: forwarders you already run

On-premises DNS servers, or domain controllers in Azure, conditionally forward the zones DTM owns to the DTM node IPs. DTM sees each forwarder’s address.

Which patterns keep per-region answers

DTM decides a client’s region from the address the query arrives from. Behind a forwarder, that address is the forwarder’s, so every client behind one forwarder gets that forwarder’s region. Health checks and cross-region failover are unaffected. See region-aware routing sees the forwarder, not the client.

Pattern	Address DTM sees	Per-region answers
1. VNet DNS points at DTM	The client	Yes
2. Firewall DNS proxy	The firewall	Only with a firewall per regional hub, each forwarding to DTM
3. Private Resolver	The outbound endpoint	Only with a resolver per region
4. Your own forwarders	Each forwarder	Only with forwarders in each region

In patterns 2 to 4, each forwarder’s address must be in a subnet mapping for its region. Region discovery maps the VNets in its discovery scopes, so include the hub’s subscription if the forwarders live there. Add on-premises forwarders as manual mappings.

Network rules

Inbound to the DTM nodes

The Marketplace deployment creates an NSG with these rules and attaches it to each node’s network interface. If your landing zone also puts an NSG on the subnet, Azure evaluates both, so that one must allow the same traffic.

Port	Protocol	From	Template rule
`53`	UDP, TCP	DNS clients: spokes, on-premises ranges, and the firewall DNS proxy, resolver endpoint or forwarders that query DTM	`dnsClientAddressPrefix`
`853`	TCP	DNS-over-TLS clients, if enabled	`dnsClientAddressPrefix`
`443`	TCP	DNS-over-HTTPS clients, if enabled	`dnsClientAddressPrefix`
`8443`	TCP	Administrators, automation and Prometheus scrapers (REST API and `/metrics`), and the other DTM nodes	`adminAddressPrefix`, with an explicit deny for the rest of the network; from v1.0.5, the other DTM nodes through `allow-api-cluster`
`8080`	TCP	Administrators (web UI)	`adminAddressPrefix`, with an explicit deny for the rest of the network
`7946`	UDP, TCP	The DTM nodes only, including the other region’s nodes	The cluster’s subnets, with an explicit deny for the rest of the network
`22`	TCP	Nobody	Denied; see break-glass OS access

Both address-prefix parameters default to the VirtualNetwork service tag. Microsoft defines that tag as the VNet’s own address space, peered VNets, connected on-premises ranges, and the prefixes in user-defined routes. In a hub-and-spoke estate it can therefore cover far more than one VNet.

Narrow adminAddressPrefix to your management range. The nodes call each other’s API on 8443 (a node repairing its database confirms a ready peer there first). From v1.0.5 the NSG allows that from the same sources as replication traffic (allow-api-cluster, priority 111), so the narrower prefix does not cut those calls off. On a cluster deployed before v1.0.5, keep the DTM node subnets inside the prefix, for example with a supernet that covers both, or add the rules by hand (see known limitations).

The DNS rule only allows: it has no matching deny (see in-VNet segmentation of DNS ports).

If you deploy with the Terraform samples, their NSG differs from the Marketplace one in places; compare its rules with this table.

Firewalls in the path need the same 53 rule for DNS traffic they route to the DTM subnet, and, for a multi-region cluster, 7946 (TCP and UDP) and TCP 8443 between the node subnets. The nodes use 8443 to reach each other’s API: a node repairing its database confirms a ready peer there first, and the peer-reachability diagnostics probe it.

Outbound from the DTM nodes

The first rows are what a running cluster needs; the rest apply only to features you turn on.

Destination	Port	Needed for
Your backends, the targets of your health checks	Each check’s port	Health checks. Every node probes every backend, so in hub-and-spoke these usually cross the hub firewall. Without the rule, every probe fails and the backends drop out of the answers.
Your DNS upstreams, if they are not Azure-provided DNS	`53` (or `853` / `443` for encrypted upstreams)	Forwarders and stub zones you configure
The Ubuntu package mirror (`azure.archive.ubuntu.com` on Azure)	`80` TCP	Operating-system security updates, which the image installs automatically
`management.azure.com`	`443` TCP	Region discovery, tag registration and Private Endpoint automation, when enabled
`login.microsoftonline.com`	`443` TCP	Entra ID sign-in to the console, when configured
`<region>.monitoring.azure.com`	`443` TCP	Azure Monitor custom metrics, when enabled
The logs ingestion endpoint you configure (`<dce>.<region>-1.ingest.monitor.azure.com`)	`443` TCP	The query log to Log Analytics, when enabled (changed in v1.0.6). Behind Azure Monitor Private Link, this is the data collection endpoint in your AMPLS, reached through its private endpoint.
`<account>.blob.core.windows.net`	`443` TCP	Scheduled backups to Blob storage, when configured
Your Event Grid topic endpoint and webhook URLs	`443` TCP	Notifications, when configured
OAuth2 token URLs	`443` TCP	Health checks that sign in with OAuth2
`<vault>.vault.azure.net`	`443` TCP	A node’s first boot, only when the cluster Key Vault is `Public` or `ServiceEndpoint`; the default `Private` mode uses its private endpoint

Two Azure platform addresses need no rule: Azure-provided DNS (168.63.129.16) and the instance metadata service (169.254.169.254), which supplies the nodes’ managed-identity tokens. Microsoft documents that 168.63.129.16 is not subject to user-defined routes, and that NSGs affect these addresses only through the AzurePlatformDNS and AzurePlatformIMDS service tags.

Without the management.azure.com path, the Azure integrations time out rather than fail with a permission error. A node can still obtain a valid token, because the metadata service needs no egress, so the Cluster permissions card shows a timeout although no role is missing.

Routing through a central firewall

With a 0.0.0.0/0 user-defined route to the hub firewall on the DTM subnet, the outbound destinations above leave through the firewall. On Azure Firewall, allow them with application rules for the FQDNs, or with network rules for the AzureResourceManager and AzureActiveDirectory service tags.

Keep routing symmetric. If spokes reach DTM directly (DTM in the hub, or a direct peering) but the DTM subnet routes their prefixes back through the firewall, a stateful firewall sees only one direction and drops the replies. Route both directions through the firewall, or neither.

NAT gateways

The Marketplace deployments create no NAT gateway and no public IP, and in a hub-and-spoke estate you should not add a NAT gateway to the DTM subnet:

With a 0.0.0.0/0 route to your firewall, the NAT gateway carries no traffic. Microsoft documents that traffic does not pass through a NAT gateway when a user-defined route sends 0.0.0.0/0 to a network virtual appliance or a virtual network gateway. It adds cost and confusion, nothing else.
Without that route, the NAT gateway becomes the subnet’s internet path and bypasses your firewall, its inspection and its logs. That breaks the landing zone’s central-egress design, and is often denied by policy.

If your estate needs NAT for scale, it belongs on the hub firewall’s subnet, as a firewall design choice.

A NAT gateway is the right answer for a standalone VNet with no central egress, such as a proof of concept or an isolated estate. Without one, a new subnet has no outbound path at all.

Private DNS zones and Private Endpoints

In a landing zone, the privatelink.* Private DNS zones usually live centrally in the connectivity subscription. They are linked to the hub VNet, and Azure Policy keeps the Private Endpoint records in them.

Point the deployment at your Key Vault zone. By default the Marketplace deployment creates its own privatelink.vaultcore.azure.net zone for the cluster Key Vault and links it to the node VNets. Azure refuses to link one VNet to two zones with the same name, so in a landing zone pass your central zone’s resource ID in keyVaultPrivateDnsZoneId instead. See Key Vault network access.
Link the central zones to the DTM nodes’ VNet. DTM forwards names it does not own to Azure-provided DNS, which answers from the zones linked to the VNet the query comes from. Without the link, clients that resolve through DTM get public addresses for Private Endpoints.
Choose one owner per privatelink.* zone. DTM’s Private Endpoint automation can keep these zones itself. A zone DTM hosts is authoritative on DTM: a direct query for a privatelink.* name that DTM does not hold gets NXDOMAIN from DTM, not the central zone’s record. If Azure Policy already maintains your central zones, keep them and leave the automation off. Turn it on only for zones you want DTM to own.
Moving a zone you own into DTM: the migration guide imports an Azure Private DNS zone directly.

Verify

From a VM in a workload spoke:

dig @<dtm-node-ip> <a-name-in-a-DTM-zone>
dig <a-name-in-a-DTM-zone>   # through the VNet's normal DNS path

Then check the Cluster permissions card on the Lifecycle page: a timeout on a Resource Graph or Private Endpoint row means no outbound path to management.azure.com, not a missing role.

Need a hand? Email [email protected].

Privacy policyTerms of use