Which Samba DNS backend fits your domain controllers
If you are deploying or moving a Samba AD domain, the practical choice for each domain controller is between the two supported DNS backends: SAMBA_INTERNAL and BIND9_DLZ. The Samba wiki warns against the NONE backend, and BIND9_FLATFILE is not supported, so neither belongs on the shortlist. Pick the backend once per DC, and keep every DC on the same choice so that zone data and replication behave predictably. Choose SAMBA_INTERNAL when you want DNS served by Samba itself, with fewer moving parts and no separate BIND service to patch, configure and monitor. Your team administers DNS through the same samba-tool workflow it uses for the directory, which suits a small or mid-sized estate without an existing DNS engineering function. The trade-off is that you depend on the features Samba's internal server provides, so confirm that it covers the record types, forwarding behavior and zone management your applications need before you commit.
Choose BIND9_DLZ when your organization already runs BIND and has the operational practice, monitoring and change process around it, or when you need DNS features that your team already depends on in BIND. The DLZ module lets BIND read directory-backed zone data from Samba, so existing BIND expertise carries over, but you now own two components whose versions, configuration and security updates must stay aligned. Before you decide, check the current Samba AD DC setup guidance and confirm the BIND version and DLZ module build your distribution ships, using the Samba AD DC setup guide as the reference for supported configuration.
Samba internal DNS and BIND9_DLZ side by side
This table compares the two supported Samba AD DC DNS backends on where data lives, who maintains it, forwarding, skills and upgrades. Read it as a checklist of what your team will operate on each DC, and confirm the items marked for verification against the Samba documentation and the BIND version you plan to run.
| Factor | SAMBA_INTERNAL | BIND9_DLZ |
|---|---|---|
| Where DNS data lives | Zone data is held in the Samba AD database and served by Samba's built-in DNS server. | Zone data is held in the Samba AD database and served by BIND through the DLZ module. |
| Who maintains zone configuration | Zones are managed through Samba's own tooling on each DC, with no separate DNS daemon configuration. | Zones are managed in Samba, but each DC also keeps a BIND named configuration that must match. |
| Forwarding setup | Forwarders are set in the Samba configuration. Confirm the exact option name for your version. | Forwarders are set in BIND's options block. Confirm how this interacts with Samba's own resolver settings. |
| Skills needed | Samba administration skills cover DNS operation. | Samba administration plus BIND configuration, DLZ build and named troubleshooting skills. |
| Software dependency | DNS ships inside Samba, so there is one package set to install and patch. | Requires a BIND build with DLZ support. Confirm package availability in your distribution. |
| Behavior during upgrades | Samba and DNS move together in one upgrade. Plan against the Samba release series windows. | Samba and BIND upgrades are tracked separately. Confirm the BIND version against the Samba wiki before upgrading. |
| Day-two checks | Check DNS health through Samba logs and tools already used for the DC. | Check named logs and Samba logs together. Confirm the logging setup for each DC. |
| Ruled-out options | Not applicable. NONE is warned against and BIND9_FLATFILE is not supported for either backend. | Not applicable. NONE is warned against and BIND9_FLATFILE is not supported for either backend. |
How each backend is built into the domain controller
Both DNS options run inside the same Samba AD DC and depend on the same Kerberos and AD DS foundations, so the choice changes which DNS process answers queries rather than how the domain itself works. The cards below separate the parts that stay constant from the parts that change, and name what to check on a DC that has to run on its own.
SAMBA_INTERNAL server inside the DC
With SAMBA_INTERNAL, the DNS server is part of the samba process itself, so there is no separate DNS daemon to install, configure or patch. Zones for the AD domain are served from the directory data the DC already holds. For a single DC or a small set of DCs, this keeps the number of moving parts low. Check that your Samba release series and its security support window cover the DNS features your environment needs before you commit.
BIND with the DLZ module
With BIND9_DLZ, a separate BIND process loads the Samba dynamically loadable zone module, which reads AD-backed DNS data and answers queries. BIND is then a second product with its own configuration files, its own packages and its own upgrade cycle, all of which must match the Samba version. Ask your team whether they already operate BIND well, because that skill is what this option asks you to bring.
samba-tool administration path
Zones, DNS records and domain settings on a Samba AD DC are managed with the samba-tool command, which is the same tool used for other domain administration. Whichever backend you pick, most routine DNS record changes go through this path rather than through BIND configuration files. Confirm that your change process, automation and audit logging can capture samba-tool actions, since these are the changes an auditor will ask about.
Kerberos and AD DS dependencies
Both backends sit on top of the same domain services: the Heimdal Kerberos key distribution center that Samba uses by default, and the directory data that holds users, computers and DNS objects. DNS answers are only useful to clients if Kerberos and the directory are healthy, so a DNS fault and an authentication fault often show up together. Test a failed DC for both symptoms rather than assuming the DNS backend is the cause.
Forwarder configuration
Queries for names outside the AD domain are passed to upstream resolvers through forwarder settings, and the DC's own resolver list must point to a working path to those servers. A DC that cannot reach its forwarders will still resolve its own zone but fail for internet and partner names, which clients often report as general connectivity problems. Document the forwarders for each DC, and confirm how the chosen backend handles them in your environment before go-live.
Unsupported options to rule out
The NONE backend is warned against in Samba's guidance, and BIND9_FLATFILE is not a supported option for an AD DC. Either choice would leave a domain without the DNS behavior that AD clients expect, so these should be removed from any design before the comparison begins. If an existing build uses either one, plan the move to a supported backend as a separate change with its own testing.
Why NONE and BIND9_FLATFILE are ruled out
The Samba wiki warns against the NONE DNS backend and states that BIND9_FLATFILE is not supported for an Active Directory domain controller, so neither should be chosen for a new Samba AD DC. The supported choices are SAMBA_INTERNAL and BIND9_DLZ. The reason is that an AD DC depends on DNS for more than name lookups: clients locate the domain, its Kerberos KDC and its global catalog through SRV records, and the domain's zones must be maintained through the directory itself. A backend that does not hold those records dynamically, or that is not in the supported list, leaves the domain partly working in ways that surface later as failed logons, missing service locations or replication errors that are hard to trace back to DNS.
If an existing build uses NONE, treat it as a configuration to correct before any other change. Check which backend the server was provisioned with, for example by reviewing the dns backend value in smb.conf and the output of samba-tool dns commands against the AD zones. Confirm the current guidance on the Samba wiki page for setting up Samba as an AD DC and the matching procedure for your Samba release before you move zones, because changing a DNS backend on a live domain controller is not a simple setting flip. If a BIND9_FLATFILE setup is in place, plan a migration to SAMBA_INTERNAL or BIND9_DLZ instead of extending it, and confirm the steps, the required packages and the rollback path in a lab copy first.
Ask the team that runs the domain to confirm three things in writing: the backend in use on every DC, whether SRV records resolve correctly from a representative Windows and Linux client, and whether the Samba release in use still receives the fixes the team needs. Sites that cannot confirm these should treat the DNS design as an open item in the implementation scope, not as something to assume is already correct.
Choosing the backend by estate type
A new Samba domain with one site and no existing BIND estate is the simplest case for SAMBA_INTERNAL. The DNS server is built into the domain controller, so the zones, dynamic updates and Kerberos-related records stay managed through the same tooling as the rest of the directory. The trade-off is that you accept the built-in server's feature set and the operating model Samba defines for it, rather than a general-purpose DNS platform your other teams already know. Choosing BIND9_DLZ adds a separate BIND package to patch, configure and monitor, which only pays off if you need BIND features elsewhere.
- Fewer moving parts: one service to install, back up and troubleshoot during initial build.
- Tooling fit: zone and record administration uses
samba-toolas the documented path for the domain. - Forwarding: confirm which upstream resolvers the built-in server forwards to and how they are reached from the domain controller.
- Future flexibility: ask whether you expect to add sites or hand DNS to another team within your planning horizon.
Before choosing, build a lab domain with each backend, create a test zone, run a forwarding query and confirm that a client joins and resolves service records correctly.
A domain spread across sites raises the stakes for DNS. Every domain controller needs correct service locator records for its site, and the DNS design must hold up when a site link fails. The Samba wiki warns against the NONE backend and states that BIND9_FLATFILE is not supported, so the real comparison is between the built-in server and BIND9_DLZ. Ask who will check replication health and DNS consistency across all controllers, because a backend that is easy to build can still be hard to verify across several sites.
- Site resilience: test client behavior when a site or its link is unavailable, not only when all controllers are healthy.
- Forwarder layout: decide which resolvers each site uses and document the path for external names.
- Operations count: BIND9_DLZ adds a second DNS stack to keep in step on every controller.
- Change control: agree how zone changes are reviewed and rolled out across the controllers.
- Multi-DC file serving: the Samba wiki advises against using an AD DC as a file server when multiple DCs exist, so keep that role separate.
In the lab, simulate a site outage and a controller rebuild, and confirm that DNS recovers without manual record repair.
Some organizations already run BIND as their enterprise DNS and have tested processes, monitoring and staff skills around it. In this case BIND9_DLZ lets the Samba domain controller hold directory-integrated data while your existing BIND operating model stays in place. The trade-off is that the integration is more involved than the built-in backend, and you must keep the DLZ module, BIND version and Samba release aligned. The wiki's support statements also mean you should not treat any BIND configuration as a supported starting point without checking the current Samba documentation for your release.
- Existing skills: your team already knows the BIND configuration and logging, which reduces new operational learning.
- Version alignment: confirm which BIND version your Samba release supports with the DLZ module before upgrading either.
- Audit and change records: map how zone changes are logged and approved in the BIND workflow today.
- Ownership of records: decide whether directory-generated records are edited only through Samba or also through BIND.
- Rollback plan: confirm how you would return to a known-good DNS configuration after a failed change.
In the lab, load a copy of your production zone configuration, run a Samba upgrade in the test domain and verify that both dynamic updates and forwarding still behave as expected.
When a separate network or DNS team owns name resolution, the backend choice becomes an ownership question. That team may require particular change tooling, monitoring and access controls, and the directory team may need to avoid editing records that DNS staff manage elsewhere. BIND9_DLZ can fit where the DNS team already governs BIND, while SAMBA_INTERNAL keeps DNS administration closer to the directory team. Agree the boundary in writing before the build, including who can create, change and delete directory-related records.
- Responsibility split: name who patches the DNS service, who approves zone changes and who responds to resolution incidents.
- Access model: confirm which accounts can alter zones and whether those changes can be audited centrally.
- Monitoring handoff: agree which metrics and logs each team watches and where alerts are routed.
- Escalation path: document how a Kerberos or logon failure caused by DNS is triaged between teams.
- Documentation: keep the boundary, runbooks and forwarder list in a shared location both teams can read.
In the lab, run a tabletop handoff: have each team perform one change and one incident response using only the documented boundary, and note every point where they need to ask the other team.
Upgrades, backups, monitoring and skills for each backend
This table compares what each DNS backend asks of the operations team after go-live: upgrades, backups, monitoring, troubleshooting and staffing. Read each row against your own release cadence and existing DNS skills, because the Samba release window sets when DNS changes must be tested. The main takeaway is that SAMBA_INTERNAL keeps DNS on the Samba upgrade path, while BIND9_DLZ adds a second software lifecycle to manage.
| Operational area | SAMBA_INTERNAL | BIND9_DLZ |
|---|---|---|
| Upgrade coupling | DNS changes with the Samba release line, so every Samba upgrade is also a DNS upgrade | BIND and the Samba DLZ module are upgraded separately, so the BIND version and Samba version must be tested together |
| Release window to plan around | Samba series get six months of full support, six months of maintenance and six months of security fixes only, so plan moves before a series drops to security-only | Same Samba window applies, plus BIND's own support schedule, which you must confirm with your BIND packager |
| Backup scope | The AD database holds DNS records, so backups of the domain controller cover DNS data; confirm the restore procedure in your environment | Zone data sits in the Samba database and the BIND configuration and named files are separate, so backups must cover both; confirm this for your build |
| Restore testing | Test a full DC restore in a lab, including DNS records, before relying on it | Test restores of the BIND configuration and the Samba-backed zone data together, since a partial restore can desynchronize them |
| Monitoring and logs | DNS problems appear in Samba logs and samba-tool output, so monitoring focuses on the Samba service and replication health | Monitor the named process and its logs as well as Samba and replication, which adds a second log stream to correlate |
| Troubleshooting path | Fewer moving parts: one service and one configuration tree to inspect when resolution fails | More components to check, including BIND configuration, the DLZ module and Samba's view of the zone |
| Skills the team needs | Samba administration with samba-tool and AD DNS concepts | Samba administration plus BIND named configuration, zone files and DLZ integration |
| Who to confirm with | Confirm DNS upgrade and rollback steps with your Samba build or packager for each release line | Confirm supported BIND and DLZ pairings with your distribution or packager before any change |
How forwarding and zone management change day-two work
The DNS backend decision follows you into every routine change. With SAMBA_INTERNAL, the domain controller answers for its own zones and forwards everything else, and the upstream resolvers are set through the dns forwarder key in smb.conf on each DC, so a forwarder change is a configuration edit repeated across controllers. Adding or removing a zone is handled through the samba-tool DNS subcommands, which keeps the work inside one toolset. With BIND9_DLZ, BIND serves the zones, so forwarding and zone definitions also sit in BIND's own configuration alongside the directory. Before you write a runbook, decide which place is the source of truth for each zone and forwarder, and record that decision.
Dynamic updates are where day-to-day work diverges most in practice. Domain members and DCs register their service and host records through dynamic update, and you should confirm on your release that those registrations land in the expected zone under each backend before you depend on them. For inspection, samba-tool dns query reads records from a named zone on a given server, and samba-tool dns serverinfo reports the state of that server, which gives you a quick check after an upgrade or a zone change. Run the same queries against every DC, because a record that resolves on one controller but not another is the failure your help desk will report first.
Domain-level administration, including raising functional levels, runs through the same samba-tool command, so DNS changes and functional level changes often share one maintenance window. Raising a functional level is a domain-wide step with its own prerequisites, so plan it separately from any forwarding or zone edit and check the level against the Windows Server releases your Samba version supports. Forwarding and zone behavior can change between Samba release series, so rehearse every step in a test domain built on the exact release you plan to deploy. The Samba wiki page on raising functional levels is the authority for those steps, and it should override anything summarized here.
Steps to change the DNS backend after go-live
This sequence moves a live Samba AD domain from one DNS backend to another without losing name resolution for domain members, and it leaves a tested way back if the change fails.
Inventory DNS zones, records and forwarders
The domain administrator exports every AD-integrated zone, the forwarder configuration on each domain controller, and the DNS records that clients and services depend on, including SRV records for Kerberos and LDAP. Record the current backend on every DC so no server is assumed to match the others. The step is done when the team holds a written inventory that another engineer can use to check the result without asking the author any questions.
Build a lab from the same Samba release
The platform engineer provisions a lab domain with the same Samba release that runs in production, using a copy of the inventory and the target backend. Testing against a different release can hide behaviour that appears only in production, so confirm the version with the Samba release notes before you start. The step is done when the lab domain resolves every production zone under the target backend and the test results are recorded against the production version number.
Test forwarding, dynamic updates and replication
In the lab, the engineer checks that forwarders answer external names, that dynamic updates from Windows and Samba members succeed, and that changes replicate between DCs. Use samba-tool and standard DNS query tools for these checks, and capture the output as evidence. The step is done when the lab shows no failed updates, no stale records after a test change, and no forwarder timeouts under normal query load.
Confirm client resolution from representative hosts
The team selects a set of member servers, workstations and service accounts that cover each client type in the estate, then resolves domain names, Kerberos service records and external names from each one. The network team confirms that DHCP-supplied DNS servers and any firewall rules still reach the DCs. The step is done when every representative host returns the expected answers, and the results are filed with the change record.
Roll out one domain controller at a time
The engineer changes the backend on a single production DC during an agreed change window, then waits for replication to complete and repeats the resolution checks from the previous step. Only after that DC passes does the team move to the next one. The step is done when each DC has been changed, validated and signed off in order, and no DC is changed while another is still failing its checks.
Keep and rehearse the rollback path
Before the first DC changes, the team takes a backup of each DC and writes down the exact steps to restore the previous backend, with a named owner for each step. The rollback is rehearsed in the lab so the team knows it works with the same Samba release and data. The step is done when the restore procedure has been run successfully in the lab and the production backups have been verified as readable.
Validate the domain and close the change
After all DCs are changed, the team repeats the full resolution, replication and client checks, reviews logs for DNS errors, and compares the results with the inventory. Any differences are either corrected or documented as accepted. The change record is closed only when the post-change results match the pre-change baseline or each exception has been approved by the domain owner.
Questions buyers ask about Samba DNS backends
Should I choose SAMBA_INTERNAL or BIND9_DLZ for a new Samba AD domain?
For a small, single-site domain with no existing BIND estate, most teams start with SAMBA_INTERNAL because it is built into the Samba AD DC and has fewer moving parts to patch and monitor. Choose BIND9_DLZ when your organization already runs BIND with staff who know it, when you need BIND-specific features such as views, RPZ or existing forwarding policy, or when DNS must be managed by a team that already owns BIND tooling. The Samba wiki documents both backends as supported, so the decision is operational rather than a support question. Confirm the exact behavior of your chosen backend against the Samba AD DC setup guide and test it in a lab before you commit.
Can I switch a Samba domain from one DNS backend to the other later?
Switching is possible in principle, but it is a change to a running directory service and should be planned as a project, not a setting. The DNS zones, dynamic updates from domain members and DCs, and forwarder configuration all have to be verified after the move, and you need a rollback plan and a tested backup of the directory before you start. Confirm the supported procedure for your Samba version with the wiki and your own test domain, because the steps differ between backends. Ask any implementation partner to show the change plan, validation checks and rollback steps in the written scope.
What skills does the internal team need to run Samba DNS?
The team needs working knowledge of Active Directory concepts, including SRV records, dynamic DNS registration and how domain members locate DCs, plus enough Samba administration to use samba-tool for day-to-day tasks. With BIND9_DLZ, add BIND configuration, zone file handling and DLZ module troubleshooting. Staff who already run Windows domains can usually learn the Samba tooling quickly, but they still need to test failure scenarios such as a DC going offline. The Samba wiki describes samba-tool as the administration command for AD domains, so plan training and runbooks around it.
Can my team deploy Samba DNS without outside help?
Yes, if the team has the Active Directory and Linux skills described above and time to build and test a lab domain first. Teams without that experience usually bring in outside help for the initial design, forwarding and zone layout, and the first upgrade. DeployOpen plans, implements, documents and supports self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Whether you do it yourself or buy help, ask for a written runbook covering both backends' failure modes.
What drives the cost and effort of a Samba DNS decision?
The main cost drivers are the number of domain controllers, the number of sites and zones, how much forwarding and conditional forwarding you need, the amount of testing you can run before production, and whether you already have BIND skills. Costs split into one-time work (design, build, migration testing, documentation and training) and recurring work (patching, monitoring, Samba upgrades and DNS changes). Samba is GPL-3.0 and free to download, so the spend is staff time and any external services. Samba 4.25.0 is the current stable release, and Samba 4.24.8 is also available, according to the Samba website. Each release series receives six months of full support, six months of maintenance and six months of security fixes only, with Samba 4.25 starting in September 2026, according to the Samba release planning page. Plan upgrades around those windows.
How does upgrade cadence change the DNS backend choice?
Your upgrade cadence matters more than the backend itself. Samba release series move through full support, maintenance and security-only phases, so a domain that lags several series will eventually run unsupported code. With BIND9_DLZ, you also track the BIND package version and the DLZ module compatibility, which adds a second upgrade stream to test. SAMBA_INTERNAL reduces that to one stream but ties DNS behavior to Samba releases. Ask for a written upgrade plan that names the Samba series in use, the test domain used before each change and who approves the window.
What should I request in a written scope for Samba DNS?
Ask for a scope that names the chosen backend, the DC count and sites, the zones and forwarders, the Samba version and its support window, the test environment and acceptance checks, and the backup and rollback procedure. Also request a list of deliverables, such as configuration documentation, runbooks for DC failure and zone recovery, and training for your staff. Because DeployOpen does not publish a price list, the written scope is what produces a quote. Confirm which items are one-time and which recurring support or upgrade work sits in a retainer.
How DeployOpen scopes and supports Samba DNS work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the DNS backend decision for a Samba AD domain controller. Engagements start from a written scope that covers the DNS backend, forwarding, zones and day-two operations before any change is made.
How we scope
- Written scope fixes which DNS backend, SAMBA_INTERNAL or BIND9_DLZ, applies to each domain controller
- Scope lists forwarders, AD-integrated zones, reverse zones and the Kerberos and DNS records clients depend on
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Build covers the domain controller DNS configuration and the forwarding path to your upstream resolvers
- Testing checks name resolution from Windows and Linux clients against each domain controller in the domain
- Lab validation runs before any change touches production zones or the domain controllers that serve them
How we hand over
- Handover documents the chosen backend, zone layout, forwarder settings and the reasons behind the decision
- Runbooks cover adding or removing zones, changing forwarders and checking DNS health after a domain controller change
- Operators receive a list of configuration items to confirm with the Samba and BIND9 release notes for your version
How we support
- Ongoing support, upgrades and continuous testing are available as retainers that follow the written scope
- Upgrade work tests DNS behavior against the Samba release in use before a domain controller is moved to it
- Support requests are handled against the agreed scope, with changes to the DNS backend recorded in writing
