Deploy a single node in the Azure portal

The Single node (evaluation) plan deploys one DTM node into a subnet of your existing VNet. Use it to evaluate DTM, for a lab, or for a small estate where one authoritative DNS server is enough. It has no failover: if the node stops, clients that use it for DNS get no answers. For production, deploy two nodes in one region instead.

The deployment template is free. The node is billed per VM-hour by the Hayami DTM virtual machine offer, plus your normal Azure costs for the VM, disk and networking. Your first deployment may ask you to accept the Hayami DTM virtual machine offer’s terms.

Before you start

Read Before you start on the deploy page. For this plan you need:

• Owner, or Contributor plus User Access Administrator, on the target resource group. The deployment creates role assignments, so Contributor alone fails. See Deployment permissions.
• An existing VNet in the region you deploy to. The wizard does not create a VNet.
• One free private IP for the node, either in an existing subnet or in a new subnet the wizard creates.

Open the plan in the portal

1. Open the Hayami DTM Cluster listing and select Get it now.
2. Choose the Single node (evaluation) plan and select Create. The Azure portal opens the wizard.

Basics

Field	What to enter
Subscription	The subscription that holds your VNet.
Resource group	A new, dedicated resource group is recommended. See a dedicated resource group per region.
Region	The region of the VNet you deploy into.
Resource name prefix	Names the node’s resources. Default dtm-node-01. Choose a stable name: the node’s private IP is the long-lived resolver address.

Virtual machine

Field	What to enter
VM size	D2s_v5 is the recommended floor. See Sizing and storage.
Availability zone	Default No zone placement (regional). A zone that does not offer the chosen VM size fails the deployment, and the zone cannot be changed later.
SSH public key	Paste your SSH public key (ssh-ed25519 or ssh-rsa). The wizard has no password option: the OS has no password login. This is not the DTM admin password, which is generated in Key Vault at first boot.
OS admin username	Default dtmadmin. This login is for break-glass access only; you run DTM from its web console.
Serve the Terraform provider from the cluster	Default No. Choose Yes only if you will manage DTM with Terraform: the endpoints that serve the provider are unauthenticated.

Networking

Field	What to enter
Existing virtual network	Your VNet in the chosen region. The list shows each VNet’s address space.
Subnet	Use an existing subnet (default) or Create a new subnet.
Subnet (existing)	The subnet the node takes its IP from.
New subnet name and CIDR	Shown when you create a subnet. Defaults dtm-subnet and 10.50.250.0/27, carved out of your VNet’s address space.
Static private IP	A free IP inside the subnet; there is no default. Clients send their DNS queries here.
DNS client CIDR	Default VirtualNetwork, which is recommended: it covers your VNet, peered VNets and networks behind a VPN or ExpressRoute gateway. Enter a CIDR only to restrict DNS to one client range.
Admin CIDR	Default VirtualNetwork. The range that can reach the web console (8080) and API (8443). Restrict it to your operator or jump box subnet where you can.

No public IP address is created. You can change both CIDRs after deployment by editing the node’s network security group (NSG) rules.

Upgrades

The Upgrades step has one checkbox, Grant the node’s managed identity the Network Contributor role on the cluster subnet now. It is off by default. Turn it on when the VNet is in another resource group, unless your network team grants the role. Without it, the Lifecycle stable-IP swap cannot join the subnet.

Key Vault

The deployment creates a Key Vault for the cluster’s admin password and replication encryption key. The node reads it at first boot with its own managed identity. Choose how the node reaches it under Network access:

• Private endpoint (recommended) (default): public access to the vault is disabled and the deployment adds a private endpoint in the node’s subnet. Under Private DNS zone, keep Create a new zone, or choose Use an existing zone if your organisation manages privatelink.vaultcore.azure.net centrally, as an Azure landing zone does. Azure cannot link a VNet to two zones with the same name, so creating a second one would fail.
• Service endpoint: the vault keeps its public endpoint behind a firewall that admits only the node’s subnet. The subnet must already exist with the Microsoft.KeyVault service endpoint enabled, and you tick a box to confirm it. A subnet this deployment creates cannot have it yet.
• Public: the vault’s public endpoint is open; access is still limited by Azure RBAC to the node’s identity. For evaluations only.

See Key Vault network access for the trade-offs.

Review and create

Select Review + create, check the summary, then Create. The deployment takes a few minutes; the node is ready to serve shortly after the VM boots.

What the deployment creates

• One DTM VM from the Hayami DTM image, with a data disk (deleted with the VM), a network interface on a static private IP, and a system-assigned managed identity with the role grants in What the managed identity can do.

• A network security group on the node’s network interface:

  Allows	Port	From
  DNS, DNS over TLS, DNS over HTTPS	53, 853, 443	DNS client CIDR
  Web console and API	8080, 8443	Admin CIDR
  Cluster replication	7946 (TCP, UDP)	The node’s subnet: the new subnet’s CIDR, or the existing subnet’s address ranges

  It also denies the console, API, cluster replication (7946) and SSH (22) to the rest of the VNet, so SSH is closed by default.

• A Key Vault. With the private option, also a private endpoint and, unless you chose an existing zone, a private DNS zone linked to the node’s VNet.

• A new subnet, only if you chose to create one.

The deployment never creates a VNet, a public IP or a VNet peering.

After the deployment

Open the deployment’s Outputs. They give the node’s private IP, its web console and API addresses, and a recoverAdminAccessCommand.

1. Sign in for the first time with the password that command retrieves.
2. Verify the node is serving.
3. Point your clients at the node’s IP, then follow the Quickstart to create your first zone and records.

Day 2

• Upgrades: a portal deployment updates through the Lifecycle page’s stable-IP swap. The page shows a curl command for the swap. See Path A for the swap procedure. On a single node the swap is refused with 400, because it needs at least two alive nodes. The command’s comment says to add "accept_outage": true to the request body to proceed. Doing so accepts a DNS outage on that node.
• OS patching: see OS patching.
• Grow the cluster: add nodes to the same cluster, or promote the pilot to a production cluster.