Using the web UI

The web UI is the point-and-click surface for administering DTM. It covers nearly everything the REST API does, so it is a good way to get familiar with DTM before automating with Terraform.

The UI serves HTTPS on port 8080 with the managed UI certificate (self-signed at first boot); see TLS certificates to install one your browsers trust.

Signing in

Open the UI in a browser and sign in with your DTM username and password, or with Sign in with Microsoft if Entra ID SSO is configured. Your role determines what you can do: the UI’s write controls are admin-only, while readonly and editor users see everything without edit affordances (editor accounts make their changes through the API or Terraform instead).

Navigation

The left navigation gives you:

• Dashboard - at-a-glance cluster and DNS status.
• Zones - your authoritative zones; open a zone to manage its records.
• Health Checks - health-check status across your backends.
• Forwarders - default and conditional forwarders, stub zones, and forwarder hardening.
• Overrides - override records: admins create, edit, enable/disable, and delete them here, behind guardrails that preview the name’s current resolution path and restate the effect before you commit.
• Blocklist - the DNS blocklist.
• Nodes - cluster members and their status.
• Tools - an ad-hoc DNS query tester and reachability checks against the node the UI is talking to. Query results name the pipeline stage that decided the answer (blocklist, cache, authoritative, override, conditional forwarder, or default forwarder), and the UDP/53 reachability row sends a real DNS query, so ok means the peer actually answered DNS.
• Diagnose - read-only configuration and cluster-health checks, plus a downloadable support bundle: a single redacted zip of config, diagnostics, and cluster state to attach when you escalate to support.
• Audit Log - the audit log of changes.
• Users - user and role management (admin only).
• Lifecycle - cluster version and update status, node swaps, and (from v1.0.7, admin only) a Restart service card that restarts DTM on the node the console is connected to; see restart a node’s service. When the published version information is older than the release a cluster runs, the page says so and offers no upgrade.
• Settings - subnet mappings, discovery scopes (with review-and-apply of discovered changes), TSIG keys, backup and restore, and other cluster settings.

Create a zone

1. Go to Zones and choose Create Zone.
2. Enter the zone name as an FQDN (for example example.internal.) and a default TTL.
3. Save. The zone shows as active immediately and reaches the other nodes within moments.

A zone can carry a deletion lock, shown as a padlock on the zones list. The zone detail page has a Lock/Unlock toggle; while locked, the zone refuses deletion from every surface (UI, API, and Terraform), so deleting it is a deliberate two-step. See deletion locks.

Add a record

1. Open a zone and choose Add Record.
2. Set the name (relative to the zone, or @ for the apex), the type (A, AAAA, CNAME, TXT, ALIAS, and so on), and a TTL. MX and SRV records carry priority/weight/port metadata the form does not collect yet; the form offers but refuses them, so create those via POST /api/v1/zones/{id}/records or the dtm Terraform provider.
3. Add one or more values. For A/AAAA records these are backend addresses; for an ALIAS record, choose type ALIAS and enter downstream hostnames.
4. Save.

Configure load balancing and health checks

When a record has more than one value, configure how DTM chooses between them:

1. On the record, open the Load balancing section and choose a method: round-robin, failover, latency, region, geo-failover, or weighted (with per-value percentages). Client affinity is configured through the API or Terraform and shown read-only on the record page.
2. Open the Health check section and choose a probe: TCP, HTTP, or HTTPS, with a port, path, interval, and timeout. See health checks.
3. For an HTTPS probe against an auth-gated backend, the Authentication selector adds OAuth2, mutual TLS, or Azure Managed Identity credentials, plus an optional CA pin, without exposing a public /healthz. See authenticated health probes. The record page summarises the configured method (never the secrets).
4. Save. DTM begins probing the values and returns only healthy ones.

Tip

Stored probe secrets are never displayed again. When you edit a record or a health check, each secret field loads blank with a “leave blank to keep” hint: leave it blank to keep the stored value, or type a new one to rotate it.

View health and cluster status

• Health Checks shows each backend’s current health state, ordered worst first so a failing check is at the top. A summary bar counts unhealthy, degraded, pending, and healthy checks, and filter chips narrow the page to one status; the live badge updates never reorder or refilter the list under you. Checks that gate records are created from the record form; record-less monitor-only checks (status metrics only, no DNS effect) are created through the API and can be edited and deleted here.
• Nodes lists every cluster member the cluster can see, with its status (alive), region, and version. A member that fails drops off the list. Use it to confirm the cluster is whole, for example before a rolling upgrade. Removing a node from here asks you to type its name and spells out the consequences first, and the removal is recorded in the audit log; follow the order in removing nodes.
• Dashboard summarises query volume, zone and record counts, and cluster health. Its Failing health checks table groups what is failing by zone, then by record or override, with each failing target under it, the node and the last error; each record links to its own page. A check that belongs to no record is listed under Not attached to any record. The table shows up to 10 rows and links to the Health Checks page for the rest. (Changed in v1.0.7.)

Configure forwarding and the blocklist

• Forwarders manages the default forwarder, conditional forwarders, and stub zones. Each conditional forwarder and stub zone has a Test button that queries its upstreams directly (bypassing the cache and the resolution pipeline) and interprets the result per upstream, so the one dead upstream in a list is obvious; a bare NXDOMAIN reads as “the upstream answered, but has no record for this name” rather than a failure. See forwarders and stub zones. The same page’s Hardening card (admin only to change) holds the forwarder hardening settings: the default forwarder’s name allowlist and the per-client rate limit on forwarded queries. It used to live on Settings, and old links to it there redirect to the card.
• Blocklist manages the suffix-matched denylist.

Manage users and settings

• Users (admin only) is where you add users, set roles, and disable accounts. Your own row has no Delete action (the server refuses self-deletion), and the last enabled admin can be neither deleted nor disabled, so an organisation cannot lock itself out.

• Settings covers region mappings and discovery scopes (including management-group scopes: a picker lists the groups the identity can see, expands one into readable and unreadable member subscriptions with an optional verified probe, and you confirm the set you are authorising), TSIG keys, backup and restore, the region-discovery backend, delete guardrails, the discovery review flow (discovery detects; you apply: a status line shows pending drift, including management-group membership changes, Review changes opens the diff, and Apply re-discovers and writes; removals are only offered from a complete observation), transport protocols (DoT and DoH), tag-based VM registration, service accounts (admin only: create with an optional zone scope, show-once token, revoke), and other configuration.

  Changed in v1.0.7. A left-hand index lists the settings in seven groups: Azure discovery; Logs and troubleshooting; Backup and data safety; DNS serving; Zone transfers and updates; Access and security; and Automation and cluster tuning. Selecting a card shows its whole group, so related settings sit side by side, and a Filter settings box above the index narrows it to the cards whose name, group, keywords or help text match. Every card says where its setting applies: Cluster-wide, This node only (naming the node the console is connected to), or Applies after restart. Settings that have a page here carry an “i” icon whose help text ends in a Learn more link to it. Two cards are renamed: Subnet Mappings is now Region Mappings, with an “Address range (CIDR)” column, and Azure Subnet Discovery is now Azure VNet Discovery. The API and Terraform names are unchanged.

• Audit Log shows a filterable log of who changed what: filter by user, action, resource, and a From / Until date range. The NDJSON export link honours the active filters, dates included, so “export what I am looking at” does what it says.

Note

Override records carry extra confirmation friction in the UI by design: an override changes how an existing name resolves for every client, so the form previews the current resolution path and the confirmation restates the effect before anything is saved. ALIAS records, by contrast, are created from the normal record form. For steady-state management, prefer Terraform; see override records.