Active Directory coexistence

DTM runs alongside Active Directory, not as a replacement for the DNS role on a domain controller. The supported pattern: AD keeps its own zones, DTM is authoritative for your application and traffic-management zones, and the two are wired together with conditional forwarding. (First contact with DTM in an established AD estate? Start with the gentler on-ramp, adopt DTM one zone at a time, where the DCs stay in front and forward a single new zone to DTM.) The API examples below send a bearer token as $DTM_TOKEN; the API overview shows how to capture one.

Why coexistence, not replacement

Windows domain controllers and domain-joined clients register their records using GSS-TSIG secure dynamic update (RFC 3645), a Kerberos-authenticated mechanism DTM does not implement, so the AD-integrated zones must stay on the DCs. DTM adds its value on the zones AD does not own: health-checked load balancing, region-aware and cross-region failover, weighted canary and blue/green shaping, and standards-based dynamic DNS for non-Windows hosts. See known limitations for the exact boundary.

DTM does support the mechanics AD relies on day to day: SRV records (the _ldap._tcp / _kerberos._tcp / _gc._tcp class, authoritative and via RFC 2136 dynamic update), A/AAAA/CNAME/PTR/NS/TXT/MX, RFC 2136 dynamic DNS (optionally TSIG-signed), AXFR, reverse zones with automatic PTR management, and scavenging of stale dynamic records.

Topology

• Domain controllers stay authoritative for the AD zones: the AD domain (for example corp.example.com) and _msdcs.<forest-root>. DC and client registration is completely unchanged; they keep registering into the DCs.
• DTM is authoritative for your traffic-management zones (for example apps.example.com) and does the load-balancing and failover work there.
• Clients resolve against DTM. DTM conditionally forwards the AD zones back to the DCs and serves everything else.

Forward the AD zones to the DCs

Add conditional forwarders for the AD domain and its _msdcs zone. DTM uses longest-suffix matching, so these win over the default forwarder:

curl -sk -X POST https://dtm.internal:8443/api/v1/forwarders \
  -H "Authorization: Bearer $DTM_TOKEN" \
  -H "X-DTM-CSRF: 1" \
  -H "Content-Type: application/json" \
  -d '{"domain": "corp.example.com.", "upstreams": ["10.0.0.10:53", "10.0.0.11:53"], "comment": "AD domain -> DCs"}'

curl -sk -X POST https://dtm.internal:8443/api/v1/forwarders \
  -H "Authorization: Bearer $DTM_TOKEN" \
  -H "X-DTM-CSRF: 1" \
  -H "Content-Type: application/json" \
  -d '{"domain": "_msdcs.corp.example.com.", "upstreams": ["10.0.0.10:53", "10.0.0.11:53"], "comment": "AD _msdcs -> DCs"}'

Or as code, with the Terraform provider:

resource "dtm_forwarder" "ad_domain" {
  domain    = "corp.example.com."
  upstreams = ["10.0.0.10:53", "10.0.0.11:53"]
  comment   = "AD domain -> DCs"
}

resource "dtm_forwarder" "ad_msdcs" {
  domain    = "_msdcs.corp.example.com."
  upstreams = ["10.0.0.10:53", "10.0.0.11:53"]
  comment   = "AD _msdcs -> DCs"
}

After this, an AD lookup such as _ldap._tcp.dc._msdcs.corp.example.com is answered by the DCs, while app1.apps.example.com is answered (and load-balanced) by DTM.

Tip

Prefer a stub zone if you want DTM to follow the DCs’ NS set automatically as domain controllers are added or removed, instead of maintaining a static upstream list: POST /api/v1/stub-zones with {"domain": "corp.example.com.", "hints": ["10.0.0.10:53", "10.0.0.11:53"]}. DTM periodically refreshes the zone’s NS records from the hints.

Non-Windows dynamic registration

Linux hosts, network appliances, and Kubernetes ExternalDNS can register into DTM-authoritative zones directly over RFC 2136 dynamic update, including SRV records for service discovery. Require signed updates by setting dynamic_dns.require_tsig: true (unsigned updates are then rejected), and let DTM’s scavenging remove stale records. See dynamic DNS registration for the generic host and DHCP workflow, forwarding, blocklist and dynamic DNS for the settings, and the AKS + ExternalDNS recipe for Kubernetes.

What DTM does not do here

• GSS-TSIG / Windows secure dynamic update: DCs and domain-joined clients register into the DCs, never into DTM.
• AD replication, LDAP, or directory services: DTM is a DNS server, not a directory. It only serves and forwards DNS.
• Automatic _msdcs delegation management: you point the forwarder (or stub zone) at the DCs explicitly, as shown above.

Questions about an AD topology not covered here? Email [email protected].