The Samba AD DNS Back Ends: Difference between revisions

From SambaWiki
(→‎Configuration: Fix comment to match updated example.)
(→‎Configuration: It's "secure", "secure only" or "signed". Not "signed only".)
Line 24: Line 24:


# Don't allow any updates | allow unsigned updates | only allow signed updates
# Don't allow any updates | allow unsigned updates | only allow signed updates
allow dns updates = False | nonsecure | signed only
allow dns updates = False | nonsecure | signed
# If recursive queries = yes is set, the following is also needed
# If recursive queries = yes is set, the following is also needed

Revision as of 09:33, 1 June 2013

Which DNS backend should I choose?

The DNS backend should be choosen, on the requirements of your network or existing DNS installations.

The internal DNS is a new implementation, that allows to quick and easy setup of the DNS backend, that is required for every AD installation. No further work is required to set it up. Currently it covers the important and required parts for AD.

If you already having BIND running, plan complex DNS setups or you require special functions (zone transfers only from defined hosts, etc.), that are currently not supported by the internal DNS, BIND should be the preferred backend.

The choice for a DNS backend during provisioning/upgrading is not a one way street. If you find out, that your choice doesn't fit your requirements, you can flip over and change the DNS backend.



Internal DNS

The internal DNS server is built into Samba and uses AD as backend. Also it is the default DNS solution when you provisioning/upgrading an Samba AD controller.


Configuration

If you choosed the internal server as DNS backend for your environment, there are three options that can be added to your smb.conf to control the behavior of DNS at this point:

# Don't allow any updates | allow unsigned updates | only allow signed updates
allow dns updates = False | nonsecure | signed

# If recursive queries = yes is set, the following is also needed
dns forwarder = <ip addr of external dns server>

Limitations / Known issues

  • The internal server is not a caching resolver.
  • The samba_dnsupdate command produces warnings when used with signed updates. We're currenly investigating a fix for the warnings, but the updates actually succeed. Client systems like samba3 or Win7 work fine.


Tests

Run during make test

TDB_NO_FSYNC=1 make test TESTS=samba.tests.dns

Run against external servers (Windows or BIND)

SERVER_IP=<dns server ip> SERVER=<dns server name> REALM=<dns server domain name part> PYTHONPATH=`pwd`/bin/python ./source4/scripting/bin/subunitrun samba.tests.dns



BIND DLZ plug-in (for BIND 9.8 and 9.9)

BIND can be setup to provide DNS resolving for zones managed in AD. They are accessable from BIND through the DLZ (dynamically loadable zones) plug-in.


Installation / Setup

See the Bind as DNS backend HowTo for a detailed instruction.



Changing the DNS backend

Changing from Internal DNS to BIND

  • Shutdown Samba
  • Migrate the zonefiles to BIND9_DLZ:
...../sbin/samba_upgradedns --dns-backend=BIND9_DLZ
  • Remove the 'dns' option from the 'server services = ' parameter in your smb.conf, or change it to '-dns':
server services = ........ -dns
  • Start BIND and Samba


Changing from BIND to Internal DNS

  • Shutdown BIND and Samba
  • Migrate the zonefiles to internal DNS:
...../sbin/samba_upgradedns --dns-backend=SAMBA_INTERNAL
  • Add 'dns' option to the 'server services = ' parameter in your smb.conf:
server services = ........ dns
  • Start Samba