title: Dante Domain Manager — Enterprise Dante Network Management description: Deep reference for Dante Domain Manager (DDM): multi-VLAN routing, domain architecture, user authentication, audit logging, server deployment, and commissioning in enterprise AV installations. tags: [networking, dante, ddm, dante-domain-manager, vlan, multicast, enterprise-av, audinate, audio-networking] created: 2026-05-05 status: current review_by: 2027-05-05

Dante Domain Manager — Enterprise Dante Network Management

This article covers DDM architecture and deployment in depth. For a Dante overview including basic network design, see networking/dante.

Dante Domain Manager (DDM) is Audinate's licensed server application that extends the capabilities of a Dante network beyond the single-VLAN, single-subnet model that standard Dante Controller supports. In a basic Dante network, all devices must share the same Layer 2 VLAN because Dante relies on mDNS for device discovery — and mDNS does not cross IP subnet boundaries. DDM replaces mDNS-based discovery with a centralized registry, enabling Dante devices on separate VLANs, separate buildings, or even separate campuses to discover each other and exchange audio over routed IP networks.

Beyond multi-VLAN support, DDM adds enterprise-class management: named logical domains that partition a large system into manageable segments, user authentication with role-based access control, and an audit log of every routing change made on the network. For any Dante deployment spanning more than one VLAN or requiring change management accountability, DDM is not optional — it is the only supported path.

When DDM Is Required

DDM becomes necessary when a Dante deployment encounters any of the following conditions:

Multi-VLAN routing — The most common trigger. A conference center with a dedicated AV VLAN per floor (VLAN 100 on Floor 1, VLAN 110 on Floor 2) needs DDM to route audio from a shared DSP on Floor 1 to amplifiers on Floor 2. Without DDM, each VLAN is a completely isolated Dante island.

Multi-subnet campus — University, hospital, or corporate campus with AV infrastructure distributed across routed network segments. Standard Dante discovery fails at Layer 3 boundaries. DDM's unicast discovery model works over routed networks with proper firewall rules.

Domain separation within a single VLAN — A large venue (convention center, broadcast facility) may have 200+ Dante devices on one VLAN. DDM allows logically partitioning those devices into named domains (Ballroom A, Ballroom B, Production Gallery) so that operators only see the devices relevant to their space. Accidental cross-system routing is prevented.

Authentication and access control — Permanent installations where unauthorized routing changes would cause service disruptions require DDM's login-based access model. Without DDM, anyone with Dante Controller on the same VLAN can modify routing.

Audit requirements — Corporate and government AV installations with IT compliance requirements need DDM's audit log for change tracking.

Single-room or single-VLAN installations with trusted operators do not require DDM and should not add it unnecessarily — DDM introduces network infrastructure complexity and licensing cost.

DDM Architecture

Centralized Registry Model

DDM replaces Dante's mDNS peer-to-peer discovery with a client-server model:

1. DDM Server — Windows Server or Linux application that maintains the Dante device registry. All Dante devices running DDM-compatible firmware register with the server on boot. The server tracks device names, IP addresses, domain assignments, and routing state.

2. DDM-enrolled devices — Dante devices with DDM support (firmware 4.2+ on most hardware) connect to the DDM server via unicast TCP. Once enrolled, the device's routing state is managed by DDM rather than Dante Controller's direct device communication.

3. Dante Controller (DDM mode) — The standard Dante Controller application continues to be used for routing configuration, but when DDM is present, it connects through DDM rather than communicating directly with devices. The routing matrix in Dante Controller works identically from the user's perspective.

4. DDM Web UI — DDM includes a browser-based administration interface for domain management, user management, and audit log review. This is separate from Dante Controller's audio routing matrix.

Network Communication Ports

DDM requires specific firewall rules between the DDM server and all Dante devices:

Critical: Firewall rules between VLANs must allow ports 8700 and 8800 between the DDM server subnet and every VLAN carrying Dante devices. Port 4440–4455 (audio RTP) must also be permitted between VLANs for cross-VLAN audio flows. PTP (ports 319/320) must be permitted for clock synchronization — though cross-VLAN PTP presents its own challenges (see Common Pitfalls).

DDM Server Sizing and Deployment

DDM is available in two deployment models:

Software installation — DDM installs on a Windows Server (2016, 2019, 2022) or Ubuntu Linux host. Recommended for permanent installations where the server runs alongside other AV management software.

Audinate DDM Virtual Machine — Pre-configured VM image (VMware/Hyper-V) for integration into existing virtualization infrastructure. Reduces setup time; appropriate for IT-managed environments.

Hardware requirements (DDM v4.x):

• CPU: 4-core minimum (Intel Xeon or equivalent); 8+ cores for large deployments
• RAM: 8 GB minimum; 16 GB for 500+ device deployments
• Storage: 60 GB minimum for OS + DDM + 90-day audit log
• NIC: Single 1GbE sufficient; dual-NIC recommended for management separation
• Network: DDM server must be reachable from all Dante device VLANs via routed IP

Scaling tiers (approximate):

License tiers are sold by Audinate through distribution. License files are uploaded to the DDM Web UI.

Domains

A domain in DDM is a named logical grouping of Dante devices. Domains serve two purposes: access control (users can be granted access to specific domains) and scoping (Dante Controller only shows devices in the domains the logged-in user can access).

Domain Design Principles

One domain per acoustic system — Design domains around which devices need to route audio to each other. Devices in different domains cannot route audio between them without an explicit interdomain connection. A large conference center might have: Ballroom-A, Ballroom-B, Ballroom-Combined, Pre-Function-North, Production-Hub.

Avoid over-partitioning — Creating too many small domains fragments the system and makes commissioning more difficult. A single room with 10 Dante devices should almost always be one domain.

Reserved system domain — DDM creates a default _system domain for devices not yet assigned to a named domain. Devices in _system can only be reached by DDM administrators, not regular users.

Interdomain Connections

When two domains need to exchange audio (for example, routing from Production-Hub to Ballroom-A), DDM supports interdomain connections. An interdomain connection creates a controlled bridge between two domains, allowing specific device-to-device routing across the domain boundary. The connection must be explicitly created by an administrator — it does not happen automatically.

This mechanism supports the common large-venue scenario where a central DSP/mix engine domain feeds multiple room domains: the production hub domain connects to each room domain individually.

User Authentication and Role-Based Access

DDM requires all Dante Controller users to authenticate before making routing changes. Authentication eliminates the "anyone on the network can change routing" problem inherent in standard Dante deployments.

User Roles

Roles are assigned per domain. A user can be a Domain User in Ballroom-A and Read-Only in Ballroom-B.

Authentication Integration

DDM supports two authentication models:

Local accounts — User accounts created directly in DDM. Appropriate for smaller deployments or isolated AV networks not connected to corporate directory services.

Active Directory / LDAP integration — DDM can authenticate against a corporate AD domain or LDAP directory. Users log in with their corporate credentials; AD group membership can map to DDM roles. Preferred for enterprise IT environments where account lifecycle management is centrally managed.

Dante Controller Login Flow

When DDM is present on the network, Dante Controller detects it automatically on launch and presents a login dialog. After authentication, the routing matrix populates with only the devices in the domains the user is authorized to access. From the operator's perspective, the workflow is nearly identical to standard Dante Controller — login is the only added step.

Audit Logging

DDM records every routing change, device enrollment, user login, and configuration modification in an audit log. Log entries include:

• Timestamp (UTC)
• Username of the operator who made the change
• Action type (route created, route deleted, device enrolled, domain assigned, etc.)
• Source and destination device/channel names
• Before/after state

The audit log is accessible from the DDM Web UI and can be exported as CSV. Log retention is configurable; 90 days is the default. For compliance requirements, logs should be exported and archived to external storage on a scheduled basis.

The audit log is invaluable during troubleshooting: when a client reports that audio disappeared from a zone, the audit log shows whether a routing change was made, by whom, and when — often resolving what would otherwise be a multi-hour diagnostic session.

Multi-VLAN Audio Routing

The core technical value of DDM is enabling audio routing across routed network boundaries. Understanding how it works informs network design decisions.

How Cross-VLAN Audio Flows

In a multi-VLAN DDM deployment:

1. All Dante devices register with the DDM server via unicast TCP (port 8700), regardless of their VLAN
2. DDM maintains a global registry of all enrolled devices and their IP addresses
3. When an operator creates a route from Device A (VLAN 100) to Device B (VLAN 110), DDM communicates the route to both devices via unicast TCP
4. Device A begins sending RTP audio streams directly to Device B's IP address on VLAN 110
5. The inter-VLAN router or L3 switch forwards the RTP packets between VLANs
6. PTP clock synchronization must also cross the VLAN boundary for devices to stay in sync

Audio flows directly between devices — DDM does not proxy audio. DDM only handles the control plane (discovery, routing assignment, authentication). Once a route is established, audio flows natively between device IPs just as it would on a single VLAN.

PTP Across VLANs

Clock synchronization is the most technically complex aspect of multi-VLAN Dante. PTP requires all devices to share a common clock. In a single-VLAN system, PTP multicast propagates naturally and the BMCA elects one grandmaster. Across VLANs:

Option 1: PTP-aware L3 switch — Some enterprise switches (Cisco Catalyst 9xxx with IOS-XE, Aruba CX) support PTP boundary clock mode, which terminates the PTP domain at the switch and re-originates it on other VLANs. This is the cleanest solution but requires switch configuration and a compatible switch model.

Option 2: External PTP grandmaster — A dedicated hardware grandmaster clock (Meinberg, Sonifex, or similar) with a VLAN trunk port can serve as the clock reference for all VLANs simultaneously. The grandmaster is visible to all VLANs via inter-VLAN routing.

Option 3: Dante Clock Domain per VLAN — Each VLAN elects its own PTP grandmaster independently. Cross-VLAN routing still works, but devices on different VLANs are not sample-synchronized with each other. Acceptable for non-simultaneous distribution (different program audio to different rooms) but not for systems requiring phase-coherent multi-room output.

Most enterprise DDM deployments use Option 1 or Option 2. Option 3 is acceptable in convention center/hospitality applications where rooms are programmatically isolated.

Integration with Control Systems

Q-SYS and DDM

Q-SYS Cores include a full Dante implementation and support DDM enrollment. When a Q-SYS Core is enrolled in DDM:

• The Core's Dante I/O appears as a device in the DDM-managed domain
• Dante routing to/from the Core is managed through DDM, not directly via Dante Controller
• Q-SYS Designer still handles DSP processing, routing within the Core, and the control system logic
• The Dante channels in Q-SYS Designer's canvas represent the DDM-enrolled endpoints

In practice, Q-SYS + DDM systems require coordination between the DDM administrator (who manages Dante routing) and the Q-SYS programmer (who configures DSP signal flow). Both must understand which Dante channels are assigned to which Q-SYS components.

Crestron and DDM

Crestron DM NVX and Crestron DSP products that include Dante (via the Crestron DM-TX/RX-4K-DANTE or similar) also support DDM enrollment. Routing from NVX-embedded Dante audio to other Dante devices is managed through DDM when DDM is present.

Biamp Tesira and DDM

Biamp Tesira DSP servers support DDM enrollment. Tesira's Dante I/O appears as a DDM-managed device. Large enterprise audio deployments combining Tesira DSPs across multiple floors/VLANs commonly use DDM for cross-floor routing coordination.

Commissioning Workflow

A structured DDM commissioning process avoids the most common failures:

1. DDM server deployment (before device installation)

• Install and license DDM on a server with static IP reachable from all AV VLANs
• Configure inter-VLAN firewall rules for ports 8700, 8800, 4440-4455, 319, 320
• Create domain structure reflecting the venue's acoustic layout
• Create user accounts and assign domain roles

2. Network infrastructure verification

• Confirm IGMP snooping active on all Dante VLANs
• Confirm QoS DSCP EF → high priority on all relevant switch ports
• Confirm inter-VLAN routing is operational (ping from DDM server to device management IPs on all VLANs)
• Confirm PTP strategy — boundary clock, external grandmaster, or per-VLAN

3. Device enrollment

• Update all Dante device firmware to DDM-compatible version (4.2+)
• Configure each device's network settings (static IP recommended for DDM; avoids DHCP lease changes breaking DDM registration)
• Open Dante Controller on the same VLAN as each device; verify discovery before DDM enrollment
• In DDM Web UI, assign each device to its correct domain

4. Routing and verification

• Log in to Dante Controller with operator credentials; verify domain-scoped view
• Create routing assignments via the standard routing matrix
• Verify audio with metering in Dante Controller
• Confirm audit log entries appear for routing changes made during commissioning

5. Handoff documentation

• Export DDM configuration backup (Web UI → Settings → Backup)
• Document domain structure, user accounts (without passwords), and inter-VLAN firewall rules
• Include DDM server IP and Web UI URL in the project's as-built documentation

Common Pitfalls

• Static IP required but not configured. DDM registers devices by IP address. If a Dante device obtains a new IP address from DHCP after a lease renewal or switch change, DDM loses track of it and the device appears offline. Always assign static IPs (or DHCP reservations) to all Dante devices in DDM deployments. Document IP assignments in the project's as-built before handoff.

• Firewall blocking ports 8700/8800 between VLANs. The most common cause of devices failing to enroll across VLAN boundaries. Symptoms: devices visible via mDNS on their local VLAN but not appearing in DDM Web UI. Verify with a port scan or firewall log that TCP 8700 from device subnets reaches the DDM server. Even enterprise firewall rules with "AV traffic allowed" may omit these DDM-specific ports.

• Firmware incompatibility. DDM requires Dante firmware 4.2 or later on enrolled devices. Older hardware (particularly early AES67-only devices, some third-party OEM implementations) may not support DDM. Check Audinate's DDM compatibility list before specifying hardware for a DDM deployment. Upgrading device firmware after installation is possible but time-consuming on large systems.

• PTP grandmaster instability across VLANs. Without a PTP boundary clock or external grandmaster, each VLAN elects its own PTP master independently. When a cross-VLAN route is created, devices on different VLANs may have clock offsets large enough to cause audio artifacts. This manifests as clicks, pops, or intermittent dropouts only on cross-VLAN routes — which is confusing if the operator doesn't know about PTP. Resolve with a boundary clock configuration or dedicated PTP grandmaster before commissioning cross-VLAN routes.

• DDM server single point of failure. If the DDM server goes offline, enrolled devices retain their last known routing state and continue passing audio. However, no routing changes can be made, and any device that reboots while DDM is offline will come up in a degraded state (may lose routing). In permanent installations, run DDM on redundant server infrastructure (VM with HA) or document a manual recovery procedure. Test DDM server failure during commissioning — do not discover this behavior in front of a client.

• Over-partitioned domain design. Creating a separate DDM domain for every room in a 30-room building results in a management nightmare: 30 domains, 30 sets of interdomain connection rules, and operators who can't route audio during an event reconfiguration without administrator intervention. Design domains around acoustic systems that genuinely need to be isolated, not around room names. Ten rooms that regularly combine for events should be one domain or a small group with pre-defined interdomain connections.