Security

DTM runs entirely inside your own Azure subscription and VNet, so your DNS data never leaves your environment. On top of that boundary, it layers the controls below. This page is about the product; how Hayami operates as a vendor (what customer data we hold, how we build and ship, how we handle reports) is described at Security at Hayami.

Protections in place

• Private-VNet boundary. DTM is deployed into your VNet; there is no external service in the DNS or management path. Restrict the management surfaces at the network layer (NSG / firewall) as described in Deploy.
• TLS on the API. The REST API and management surfaces are served over HTTPS. Point clients at a certificate you trust; see TLS certificates for the certificate lifecycle and how to bring one from your own CA. DNS-over-TLS (port 853), if enabled, is standard server-authenticated TLS: resolvers verify DTM’s certificate and are never asked for a client certificate.
• Role-based access control. Three roles (readonly, editor, admin) are enforced by the API and, through it, the Terraform provider. The web UI is stricter: its write controls are admin-only, so an editor sees every page read-only and makes changes through the API or Terraform. Assign the least privilege each user or integration needs. See users and access.
• Entra ID single sign-on. Centralise authentication with your tenant and derive DTM admin access from an Entra app role. See Entra ID SSO.
• Authenticated dynamic updates. RFC 2136 dynamic updates and zone transfers (AXFR) can require TSIG authentication, and AXFR can be restricted to an IP allowlist. Key names are matched case-insensitively, with or without the trailing dot, so keys named by standard tooling (nsupdate, dnssec-keygen) interoperate. See forwarding and the Terraform config.
• Write-only secrets. Secrets you submit (TSIG keys, health-probe tokens, client secrets and keys, OTLP export headers) are stored write-only: the API and UI never return them, and they are redacted in the audit log.
• Safe outbound probing. Health-check probes using OAuth2, mutual TLS, or Managed Identity require HTTPS and verify the backend’s certificate by default (an admin can relax verification cluster-wide, an audit-logged setting; the HTTPS requirement itself cannot be relaxed). A probe whose only credential is a static header is not blocked from plain HTTP, so configure those with https. Outbound probe and forwarding targets are screened so DTM does not connect to cloud-metadata endpoints, and loopback targets are rejected when configured. See authenticated health probes.
• Encrypted forwarding. Forwarders can reach their upstreams over DNS over TLS or DNS over HTTPS with verified certificates, and an encrypted upstream never silently falls back to plaintext. See encrypted upstreams.
• Hardened OS access. The Marketplace image ships SSH locked down for break-glass use only: key-based authentication only, root login disabled, and logins restricted to the admin username you chose at deployment. The NSG does not open the SSH port; day-to-day operation goes through the UI, API, and Terraform, never the shell.
• API rate limiting. The API applies per-client rate limits to blunt credential-stuffing and burst abuse.
• Auditing. Every change is recorded in a queryable audit log. See users and access.
• Cross-site request forgery protection. State-changing admin operations (such as backup and restore) require an explicit request header, so they cannot be triggered by a browser cross-site.

Operator responsibilities

Security is shared. On your side:

• Restrict the management ports. Expose the API (8443), UI (8080), and cluster port (7946) only to trusted sources; never to the public internet. Set the deployment’s adminAddressPrefix parameter to your management subnet or CIDR rather than leaving the whole-VNet default; the NSG then denies the management ports to every other in-VNet source. See network access.
• Keep secrets in Key Vault. Store the cluster’s secrets and TLS material in Azure Key Vault (the deployment does this) and grant nodes least-privilege access. Rotate credentials on your normal schedule; see rotating secrets.
• Encrypt the data disk. Enable Azure Disk Encryption (or dm-crypt) on the node data volume as defence in depth for data at rest.
• Protect your Azure account. Enable multi-factor authentication on the subscription and Key Vault; account takeover outweighs any software risk.
• Stay current. Apply DTM and OS updates promptly. See rolling upgrades.

Reporting a vulnerability

Please report security issues privately to [email protected]. Do not open a public issue for a security report.

We aim to acknowledge a report within 48 hours, and to send a status update at least every 5 business days until it is closed. A target fix date follows once the scope of the issue is clear.

Testing scope. Hayami operates no hosted DTM service: DTM runs inside your own Azure subscription, so a customer deployment is yours, and not something we can authorise third-party testing against. The only assets in scope for unsolicited security testing are the public sites hayami.io and docs.hayami.io.

The full vulnerability disclosure policy, including the safe-harbour terms for good-faith research, is the page our security.txt files reference.

Fixed vulnerabilities are published on Security advisories, which also describes how you are notified when a release addresses a security issue.