Override records

An override record lets you put Hayami DTM in front of one name in a zone that DTM otherwise forwards. Every other name in the zone keeps resolving exactly as it does today; only the name you override is answered by DTM, with the same health-checking, load-balancing, and failover it applies to an ALIAS record.

It is the same engine, aimed at a different problem: surgical adoption. You don’t recreate the zone, re-delegate it, or migrate every record. You override a single name, prove it, and move on.

Why it matters

Most zones already exist and already resolve, whether through Azure-provided DNS, an on-prem resolver, or another authoritative server that DTM forwards to. You rarely want to take ownership of the whole zone just to make one name health-aware and region-balanced.

An override record does exactly that: DTM answers that one name with health, load balancing, and cross-region failover, and forwards everything else untouched. No big-bang cutover, no zone to rebuild: adopt DTM one name at a time.

Set one up

Override records are managed from all three surfaces: the REST API, the Terraform provider (dtm_override_record), and the web UI (write actions need the admin role). Because an override changes how an existing name resolves for every client, the UI write flow is deliberately guardrailed: the form previews where the name resolves right now, the confirmation restates the concrete effect before you commit, “create disabled” is offered as a reversible first step, and deleting an override means typing its FQDN. It also warns when the FQDN sits inside a DTM-authoritative zone, where an override would never be consulted. Terraform remains the recommended steady-state owner; see the ownership rule.

An override is keyed by an exact FQDN and a target mode:

• linked targets are hostnames that DTM keeps resolved and health-checked for you, just like an ALIAS record.
• static targets are fixed A/AAAA addresses you control directly.

Example: override one name in a forwarded zone

This overrides api.corp.example (leaving the rest of corp.example forwarded) and points it at two regional endpoints with health-aware failover:

curl -X POST https://<dtm>/api/v1/overrides \
  -H "Authorization: Bearer <token>" \
  -H "X-DTM-CSRF: 1" \
  -H "Content-Type: application/json" \
  -d '{
    "fqdn": "api.corp.example.",
    "type": "A",
    "target_mode": "linked",
    "ttl": 30,
    "values": [
      { "value": "api-ne.contoso.com", "region": "northeurope" },
      { "value": "api-we.contoso.com", "region": "westeurope" }
    ],
    "lb_policy": { "method": "region" },
    "health_check_template": {
      "protocol": "https", "port": 443, "path": "/healthz",
      "interval_seconds": 5
    }
  }'

For the Terraform equivalent, see ALIAS, GSLB and overrides.

• A linked target (hostnames, as above) is resolved, health-checked, and region-balanced just like an ALIAS, so DTM follows the backends and fails over automatically.
• A static target pins fixed A/AAAA addresses instead; use it when the override should answer with addresses you control directly.
• health_check_template is optional and accepts the full set of probe types, including authenticated probes, so you can override a name that points at auth-gated backends.

How it behaves

• Only the overridden name changes. Every other name in the zone keeps resolving exactly as before; DTM forwards it untouched.
• TTL is whatever you set on the override, independent of the forwarded zone’s TTLs, so clients fail over quickly.
• When targets degrade, unhealthy ones are dropped from the answer and traffic shifts to the remaining healthy targets, including across regions.
• Removing the override hands the name straight back to the forwarded zone, so adoption is reversible.

Good to know

• An override applies to a single name, not a whole zone, and that’s the point.
• It uses the same health-checking, load-balancing, and failover engine as ALIAS records; the difference is scope, not capability.

Need a hand? Email [email protected].