Migrating from BIND 9

BIND has run the internet’s DNS for decades, and if your zones live in it today, they work. What changes with DTM is the operational story around the same zone data: health-checked answers, a fully meshed cluster with no single point of failure, a web UI, a REST API and Terraform, Entra ID sign-on, and an audit trail. This guide maps named.conf constructs to their DTM equivalents, then walks a cutover you can rehearse and reverse.

General import mechanics (any source, dry-run preview, SOA requirements) are on Migrating to Hayami DTM; this page is the BIND-specific layer on top.

Construct map

In named.conf	In DTM
zone { type master; file ... }	Import the zone file (Zones then Import, dry run first): migration guide
allow-update + key (dynamic updates)	RFC 2136 dynamic DNS with per-zone TSIG keys: dynamic DNS
allow-transfer + also-notify	Outbound AXFR with an IP allowlist, optional per-zone TSIG, and DNS NOTIFY targets: configuration reference
forwarders { } (global)	The default forwarder: forwarders and stub zones
zone { type forward; }	A conditional forwarder or stub zone (longest-suffix match): forwarders and stub zones
zone { type slave; } (BIND as secondary)	See the boundary below: DTM does not pull zones as a secondary
Response-policy zones (RPZ) blocking	The DNS blocklist: forwarding and blocklist
logging { } channels	Structured logs plus Prometheus metrics and Azure Monitor: observability
rndc + hand-edited zone files	Web UI, REST API, or the Terraform provider, with every change in the audit log

Two boundaries to plan around, honestly

No secondary zones. DTM acts as a standards-complete primary (outbound AXFR, NOTIFY, TSIG) but has no zone type that pulls a read-only replica from an external primary, and IXFR is not supported. Two consequences: the classic “run the new server as a secondary of the old one, then promote it” ramp is not available (use the parallel run below instead), and any zone that must stay mastered elsewhere is reached by forwarding, not replication. Details: zone-transfer interop.

No views. DTM serves one consistent view of each zone. If you use BIND view blocks for split-horizon answers, either keep that zone on BIND and forward to it for the audiences that need it, or restructure so the divergent names live in separate zones. Override records intercept a name for all clients, so they substitute for views only when the goal is “different answer than the forwarded zone”, not “different answer per client”.

The cutover, step by step

1. Export nothing: the files are already on disk. Find the zone-file directory in named.conf; those files import as-is.
2. Dry-run import each zone and read the diff before committing (how). Fix anything the preview flags.
3. Parallel-run. DTM now serves the same data on its own IPs while BIND remains the production path. Point a test client (or one low-stakes subnet) at the DTM node IPs and compare answers:

   for n in 10.0.250.4 ns1.corp.internal; do
     dig app.corp.internal @$n +short
   done

4. Move dynamic updates. Repoint DHCP servers or update scripts at DTM with the new TSIG keys (dynamic DNS). Do this before the cutover so records keep registering during it.
5. Cut clients over. Repoint what hands out resolver addresses (VNet DNS settings, DHCP options, on-prem conditional forwarders) from the BIND IPs to the DTM node IPs. TTL prep applies as usual: lower long TTLs a day ahead so stragglers drain fast.
6. Keep BIND as a read-only mirror during the soak. This is the reversal ramp: make the old BIND server a secondary of DTM for the migrated zones (DTM speaks outbound AXFR and sends NOTIFY on changes), so it keeps serving current data to anything you missed, and rollback is repointing clients back:

   zone "corp.internal" {
     type slave;
     primaries { 10.0.250.4; 10.0.250.5; 10.0.250.6; };
   };

   Configure the mirror to accept NOTIFY from every DTM node address: each node sends NOTIFY for the writes it accepted itself.
7. Decommission once the query logs on BIND go quiet: remove the secondary zones, then the server. The quarterly maintenance pass is a good first health rhythm for the new cluster.

Tip

Nothing in steps 1 to 4 touches production resolution, and step 6 means even the cutover itself is reversible in one repoint. Rehearse 1 to 3 in an afternoon before scheduling anything.

Need a hand? Email [email protected].

Last validated: 2026-08-06