Difference between revisions of "BIND9 DLZ DNS Back End"

(Move DLZ examples to BIND documentation)
(suggest minimal-responses by default)
(33 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
= Introduction =
 
= Introduction =
  
This HowTo describes how to configure a BIND installation to be used as the Samba DC DNS backend. See [[Setup_a_basic_BIND_installation]] for the prerequisites.
+
Samba provides support for using the BIND DNS server as the DNS back end on a Samba Active Directory (AD) domain controller (DC). The <code>BIND9_DLZ</code> back end is recommended for complex DNS setups that the Samba internal DNS server does not support.
  
If you need a more complex DNS setup than is possible with the Samba 4 internal DNS, then using BIND as the DNS backend is recommended.
+
{{Imbox
 +
| type = note
 +
| text = This documentation only supports BIND versions that are actively maintained by ISC. For details about the ISC BIND life cycle, see https://www.isc.org/downloads/software-support-policy/
 +
}}
  
As this HowTo is based around a compiled install, the PATHs refer to '/usr/local/samba' as a base. If you are using packages from your OS or Sernet, this PATH will most likely not exist, you will need to find the relevant files on your system, try starting with '/var/lib/samba'.
+
The <code>BIND9_DLZ</code> module is a BIND9 plugin that accesses the Samba Active Directory (AD) database directly for registered zones. For this reason:
 +
* BIND must be installed on the same machine as the Samba AD domain controller (DC).
 +
* BIND must not run in a changed root environment.
 +
* zones are stored and replicated within the directory.
  
Notes:
+
= Software Architecture =
* Since the BIND DLZ module accesses the AD database directly, Bind9 '''must''' be run on the same machine as the Samba 4 AD DC.
 
* Because the BIND DLZ module uses the information already stored in AD, you do not need to create any extra databases.
 
  
 +
Bind9 operates a threading model with the 'worker threads' concept.  Each plugin has an associated mutex, so no two worker threads can call API functions provided by our plugin at once.  Database access by the plugin is guarded by a fcntl lock.
  
 +
= Recommended Architecture =
  
 +
For high traffic environments, it is not recommended to use BIND9_DLZ-backed samba as a primary DNS server.  Instead, use an external server that only forwards queries to BIND9_DLZ-backed samba DNS installations when the query is addressed to a zone managed by that node.
  
= BIND 9.8 / 9.9 =
+
= Setting up BIND =
  
During provisioning/upgrading, a file ('/usr/local/samba/private/named.conf') was created, this must be included in your BIND named.conf:
+
For details, see [[Setting_up_a_BIND_DNS_Server|Setting up a BIND DNS Server]].
  
include "/usr/local/samba/private/named.conf";
 
  
Depending on the BIND version you are running, you should edit '/usr/local/samba/private/named.conf' and enable the correct version of the DLZ module:
 
  
dlz "AD DNS Zone" {
 
    # For BIND 9.8.0
 
    database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so";
 
 
    # For BIND 9.9.0
 
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so";
 
 
    # For BIND 9.10.0
 
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so";
 
};
 
  
The example above enables the module for BIND 9.8.x (default).
 
  
Restart BIND so the included file will be used. Check the logfiles for errors and problems. If available, you can run <code>named-checkconf</code> to help you fix any problems with your BIND configuration.
+
= Configuring the BIND9_DLZ Module =
  
If you provisioned with the internal DNS, there are a few steps required to [[Changing_the_DNS_backend#Changing_from_Samba_Internal_DNS_to_BIND_DLZ|switch to BIND]].
+
During the domain provisioning, join, or classic upgrade, the <code>/usr/local/samba/bind-dns/named.conf</code> file has been created.
  
 +
{{Imbox
 +
| type = note
 +
| text = For Samba v4.7 and earlier, the <code>named.conf</code> filepath is slightly different: <code>/usr/local/samba/private/named.conf</code>. If you're using an older version of Samba, take care to use the correct filepath in the instructions that follow.
 +
}}
  
 +
To enable the <code>BIND9_DLZ</code> module for your BIND version:
  
 +
* Add the following <code>include</code> statement to your BIND <code>named.conf</code> file:
  
 +
include "/usr/local/samba/bind-dns/named.conf";
  
= BIND 9.7=
+
* Display the BIND version:
  
Users of bind 9.7 are strongly encouraged to upgrade! If this is not possible, refer to the section [[#BIND_9.7_2|DNS dynamic updates via Kerberos for BIND 9.7]] for instructions on configuring BIND 9.7.
+
# named -v
 +
BIND 9.9.4
  
 +
* Edit the <code>/usr/local/samba/bind-dns/named.conf</code> file and uncomment the module for your BIND version. For example:
  
 +
dlz "AD DNS Zone" {
 +
    # For BIND 9.8
 +
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so";
 +
 +
    # For BIND 9.9
 +
    database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so";
 +
 +
    # For BIND 9.10
 +
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so";
 +
   
 +
    # For BIND 9.11
 +
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_11.so";
 +
};
  
 +
:The following table shows the supported BIND versions and from which version of Samba the support started:
  
 +
:{| class="wikitable"
 +
!BIND Version
 +
!Supported in Samba Version
 +
|-
 +
|BIND 9.11
 +
|Samba 4.5.2 and later
 +
|-
 +
|BIND 9.10
 +
|Samba 4.2 and later
 +
|-
 +
|BIND 9.9
 +
|Samba 4.0 and later
 +
|-
 +
|BIND 9.8
 +
|Samba 4.0 and later
 +
|}
  
= DNS dynamic updates via Kerberos (optional, but recommended) =
+
= Setting up BIND9 options and keytab for Kerberos =
 
 
Samba has the capability to automatically update the BIND zone files via Kerberos.
 
 
 
To setup dynamic DNS updates you need to have a recent version of BIND installed. It is highly recommended that you run at least version 9.8.0, as that version includes a set of patches from the Samba Team to make dynamic DNS updates much more robust and easier to configure. Please use 9.8 or 9.9 if possible!
 
 
 
To find out what version of BIND you are running, use
 
 
 
# named -V
 
 
 
If your operating system does not have BIND 9.8 or 9.9, please consider getting it from a package provided by a 3rd party (for example, on Ubuntu there is a ppa available with the newer versions of bind) or [[#Installing_BIND|compile it by yourself]].
 
  
 +
Samba needs to have some options set to allow Kerberos clients to automatically update the Active Directory (AD) zone managed by the <code>BIND9_DLZ</code> back end and improve performance.
  
 +
{{Imbox
 +
| type = note
 +
| text = Dynamic DNS updates require minimum BIND version 9.8.
 +
}}
  
== BIND 9.8 / 9.9 ==
+
To enable dynamic DNS updates using Kerberos and avoid returning NS records in all responses:
  
A DNS keytab file was automatically created during provisioning/updating. Add the following' tkey-gssapi-keytab' option to the 'options' section of your named.conf:
+
* Add the following to the <code>options {}</code> section of your BIND <code>named.conf</code> file. For example:
  
 
  options {
 
  options {
 
       [...]
 
       [...]
 
       tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
 
       tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
       [...]
+
       minimal-responses yes;
 
  };
 
  };
  
 +
* If you provisioned or joined an AD forest or run the classic upgrade using a Samba version prior to 4.4.0, the BIND Kerberos key tab file was generated using wrong permissions. To fix, enable read access for the BIND user:
  
 +
# chmod 640 /usr/local/samba/private/dns.keytab
 +
# chown root:named /usr/local/samba/private/dns.keytab
  
== BIND 9.7 ==
+
:{{Imbox
 +
| type = note
 +
| text = If you are installing installing Samba using packages, validate that the BIND user is able to read the <code>dns.keytab</code> file. Some package installations set to restrictive permissions on higher folders.
 +
}}
  
If you have BIND 9.7.x (specifically 9.7.2 or later), then first determine if you can at all possibly run 9.8 or 9.9. You will have far fewer problems! Otherwise, follow these instructions:
+
* Verify that your <code>/etc/krb5.conf</code> Kerberos client configuration file is readable by your BIND user. For example:
  
The Samba provision will have created a custom '/usr/local/samba/private/named.conf.update' configuration file. You need to include this file in your 'named.conf' to allow Samba/Kerberos DNS updates to automatically take place.
+
# ls -l /etc/krb5.conf
 +
-rw-r--r--. 1 root named 99  2. Sep 2014  /etc/krb5.conf
  
include "/usr/local/samba/private/named.conf.update";
+
* Verify that the <code>nsupdate</code> utility exists on your domain controller (DC):
  
Be advised that if you include this file in BIND versions that don't support it, BIND will fail to start!
+
# which nsupdate
 +
/usr/bin/nsupdate
  
You additionally need to set two environment variables when using 9.7:
+
:The <code>nsupdate</code> command is used to update the DNS. If the utility is missing, see you distribution's documentation how to identify the package containing the command and how to install.
  
KEYTAB_FILE="/usr/local/samba/private/dns.keytab"
+
= AppArmor and SELinux Integration =
KRB5_KTNAME="/usr/local/samba/private/dns.keytab"
 
export KEYTAB_FILE
 
export KRB5_KTNAME
 
  
These should be put in your settings file for BIND. On Debian based systems (including Ubuntu) this is in '/etc/default/bind9'. On RedHat and SuSE derived systems it is in '/etc/sysconfig/named'. Please refer to your distribution documentation for the correct location to set these environment variables. Strictly speaking, you only either need KEYTAB_FILE or KRB5_KTNAME, but which you need depends on your distribution, so it's easier to just set both.
+
For details, see [[BIND9_DLZ_AppArmor_and_SELinux_Integration|BIND9_DLZ AppArmor and SELinux Integration]].
  
The 'dns.keytab' must be readable by the bind server process:
 
  
# chown named:named /usr/local/samba/private/dns.keytab
 
  
Normally, the provision/update should have setup these permissions for you automatically.
 
  
Finally, you need to add the following to the options section of your named.conf:
 
  
options {
+
= Starting the BIND Service =
      [...]
 
      tkey-gssapi-credential "DNS/server.samdom.example.com";
 
      tkey-domain "SAMDOM.EXAMPLE.COM";
 
      [...]
 
};
 
  
The last part of the credential in the first line must match the dns name of the server you have set up.
+
* Before you start the service, verify the BIND configuration:
  
 +
# named-checkconf
  
 +
: If no output is shown, the BIND configuration is valid.
  
== Testing/Debugging dynamic DNS updates ==
+
* Start the BIND service.
  
The way the automatic DNS update in Samba works, is that the provision will create a file '/usr/local/samba/private/dns_update_list', which contains a list of DNS entries that Samba will try to dynamically update at startup and every 10 minutes thereafter using the 'samba_dnsupdate' utility. Updates will only happen if the DNS entries do not already exist. Remember that you need the 'nsupdate' utility from BIND the distribution for all these to work.
 
  
If you want to test or debug this process, then please run as root:
 
  
# /usr/local/samba/sbin/samba_dnsupdate --verbose --all-names
 
  
The command line options specified will force an update of all records in the 'dns_update_list', as well as output detailed information on what is being done.
 
  
 +
= Testing Dynamic DNS Updates =
  
 +
For details, see [[Testing_Dynamic_DNS_Updates|Testing Dynamic DNS Updates]].
  
= Interaction with AppArmor or SELinux =
+
= The Lockup Problem =
  
If you are getting an error from samba_dnsupdate and nsupdate '''return dns_tkey_negotiategss: TKEY is unacceptable''' try the following:
+
When a BIND thread calls one of the BIND9_DLZ plugin API calls, execution can be blocked on database access calls if locks are out on the database at the time.  Unfortunately, during that time, BIND will not be able to serve any queries, even external (non-samba) queries.  Bind has a "-n" option that can increase the number of worker threads but testing has shown that increasing this number does not fix the problem, indicating that BIND's threading and queueing models are probably a bit broken.
 +
In small-scale environments this problem is unlikely to come up, but, in high-traffic environments, it may cause DNS outage.  The only solution right now is to use an external DNS server that only forwards queries to BIND9_DLZ-backed samba DNS installations when the query is addressed to a zone managed by that node.
  
If you are using AppArmor or SELinux, you have to ensure that the BIND process has read access to the following files:
 
* /usr/local/samba/private/dns.keytab
 
* /usr/local/samba/private/named.conf
 
as well read-write access to the
 
* /usr/local/samba/private/dns/
 
directory and it's own zone file(s).
 
  
The Samba provision tries to setup the permissions correctly for these files, but you may find you need to make changes in your AppArmor or SELinux configuration if you are running either of those. If you are using AppArmor, then the 'aa-logprof' command may help you add any missing permissions you need to add after you start Samba and BIND for the first time after configuring them.
 
  
Permissions, SELinux Labeling and Policy
+
= Troubleshooting =
  
These instructions are intended for RHEL6, but may serve as a guide for other distributions/versions.
+
== Reconfiguring the BIND9_DLZ Back End ==
  
There is still more work to be done in regards of creating a Samba 4 specific SELinux policy but for now you should be able to have everything working without disabling SELinux.
+
Running the <code>BIND9_DLZ</code> back end setup automatically fixes several problems, such as recreating the Active Directory (AD) BIND DNS account (<code>dns-*</code>) and BIND Kerberos keytab file problems.
  
For all the commands below, make sure you have set the following environment variable:
+
To fix the problem:
MYREALM="samdom.example.com"
 
  
Set Permissions (SELinux):
+
* Run the auto-reconfiguration:
  
  chown named:named /usr/local/samba/private/dns
+
  # samba_upgradedns --dns-backend=BIND9_DLZ
  chgrp named /usr/local/samba/private/dns.keytab
+
Reading domain information
  chmod g+r /usr/local/samba/private/dns.keytab
+
DNS accounts already exist
  chmod 775 /usr/local/samba/private/dns
+
  No zone file /usr/local/samba/private/dns/SAMDOM.EXAMPLE.COM.zone
 +
DNS records will be automatically created
 +
DNS partitions already exist
 +
dns-DC1 account already exists
 +
  See /usr/local/samba/private/named.conf for an example configuration include file for BIND
 +
  and /usr/local/samba/private/named.txt for further documentation required for secure DNS updates
 +
Finished upgrading DNS
  
Label files (SELinux):
+
* Restart the BIND service.
  
chcon -t named_conf_t /usr/local/samba/private/dns.keytab
 
chcon -t named_conf_t /usr/local/samba/private/named.conf.update
 
chcon -t named_var_run_t /usr/local/samba/private/dns
 
chcon -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone
 
  
Set Label Persistence (SELinux):
 
  
semanage fcontext -a -t named_conf_t /usr/local/samba/private/dns.keytab
+
== Debugging the BIND9_DLZ Module ==
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf
 
semanage fcontext -a -t named_conf_t /usr/local/samba/private/named.conf.update
 
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns
 
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone
 
semanage fcontext -a -t named_var_run_t /usr/local/samba/private/dns/${MYREALM}.zone.jnl
 
  
AppArmor Configuration :
+
To set a log level for the <code>BIND9_DLZ</code> module:
  
Add the following to the end of /etc/apparmor.d/local/usr.sbin.named (create it if it doesn't already exist).
+
* Append the <code>-d</code> parameter and log level to the module in the <code>/usr/local/samba/bind-dns/named.conf</code> file. For example:
  
  # Samba4 DLZ and Active Directory Zones (default source installation)
+
  database "dlopen .../bin/modules/bind9/dlz_bind9_9.so -d 3";
/usr/local/samba/lib/** rm,
 
/usr/local/samba/private/dns.keytab r,
 
/usr/local/samba/private/named.conf r,
 
/usr/local/samba/private/dns/** rwk,
 
  
Additionally, it was found that on some distributions, additional paths may be required; consult your AppArmor logs for more information.  
+
* Stop the BIND service.
  
Examples:
+
* Start BIND manually to display the debug out put and to capture the log output in the <code>/tmp/named.log</code> file:
  
It was found that on Ubuntu 14.04.1 LTS, BIND was trying to create files such as /var/tmp/DNS_110, and so a further entry was required:
+
  # named -u named -f -g 2>&1 | tee /tmp/named.log
  
/var/tmp/** rwmk,
+
: See the <code>named (8)</code> man page for details about the used parameters.
  
It has also been found on Ubuntu 14.04.3 LTS using Samba: Version 4.1.17 (built from source) and BIND 9.9.5-3ubuntu0.5-Ubuntu you need to add the line:
+
== New DNS Entries Are Not Resolvable ==
  
/usr/local/samba/etc/smb.conf r,
+
If you create new DNS records in the directory and are not able to resolve them using the <code>nslookup</code>, <code>host</code> or other DNS lookup tools, the database hard links can got lost. This happens, for example, if you move the databases across mount points.
  
 +
To verify that the domain and forest partition as well as the <code>metadata.tdb</code> database are hard linked in both directories, run
  
 +
# ls -lai /usr/local/samba/private/sam.ldb.d/
 +
17344368 -rw-rw---- 2 root named  4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
 +
17344370 -rw-rw---- 2 root named  4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
 +
17344372 -rw-rw---- 2 root named  421888 11. Nov 17:53 metadata.tdb
 +
 +
# ls -lai /usr/local/samba/private/dns/sam.ldb.d/
 +
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
 +
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
 +
17344372 -rw-rw---- 2 root named  421888 11. Nov 17:53 metadata.tdb
  
 +
The same files must have the same inode number in the first column of the output in the both directories. If they differ, the hard link got lost and Samba and BIND use separate database files and thus DNS updates in the directory are not resolveable through the BIND DNS server.
  
= Debugging BIND as Samba AD backend =
+
To auto-repair the hard linking, see [[#Reconfiguring_the_BIND9_DLZ_Back_End|Reconfiguring the BIND9_DLZ Back End]].
  
For enabling debugging on the BIND DLZ module, change the following line in '/usr/local/samba/private/named.conf' from
 
  
database "dlopen .../bin/modules/bind9/dlz_bind9.so";
+
== Updating the DNS Fails: NOTAUTH ==
 
 
to
 
 
 
database "dlopen .../bin/modules/bind9/dlz_bind9.so -d 3";
 
 
 
If you are running BIND 9.9, then add the '-d 3' to the corresponding line.
 
 
 
Stop BIND and run the service manually to capture logs:
 
 
 
  # /usr/sbin/named -u named -f -g 2>&1 | tee named.log
 
 
 
 
 
 
 
 
 
 
 
= Known issues and ways to fix/workaround =
 
 
 
== Chroot BIND ==
 
 
 
If you use BIND as Backend for your Samba AD, it must not run chroot, because it must be able to live access files and databases from your Samba installation.
 
 
 
To disable chroot for BIND, see the documentation for your distribution. In some, you can set
 
NAMED_RUN_CHROOTED="no"
 
in "/etc/sysconfig/named" and restart the service.
 
  
 +
If BIND uses incorrect Kerberos settings on the Samba Active Directory (AD) domain controller (DC), dynamic DNS updates fail. For example:
  
 +
# samba_dnsupdate --verbose
 +
...
 +
update(nsupdate): SRV _gc._tcp.Default-First-Site-Name._sites.samdom.example.com DC1.samdom.example.com 3268
 +
Calling nsupdate for SRV _gc._tcp.Default-First-Site-Name._sites.samdom.example.com DC1.samdom.example.com 3268 (add)
 +
Outgoing update query:
 +
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
 +
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
 +
;; UPDATE SECTION:
 +
_gc._tcp.Default-First-Site-Name._sites.samdom.example.com. 900 IN SRV 0 100 3268 DC1.samdom.example.com.
 +
 +
update failed: NOTAUTH
  
== Debian: BIND is listening on wrong IP address ==
+
To solve the problem:
  
On Debian systems, the AD zone auto-generation might detect and use '127.0.1.1' as the domain controller's IP address. This will cause problems when trying to connect to the server from client machines. To fix this, you will need to adjust '/usr/local/samba/private/named.conf' by changing '127.0.1.1' to reflect the actual IP address of the server you're setting up.
+
* Verify that BIND configuration is set up correctly. For further details, see [[#Setting_up_Dynamic_DNS_Updates_Using_Kerberos|Setting up Dynamic DNS Updates Using Kerberos]].
  
 +
* Recreate the BIND back end settings. For details, see [[#Reconfiguring_the_BIND9_DLZ_Back_End|Reconfiguring the BIND9_DLZ Back End]].
  
  
== Debian Sid: Named does not start ==
 
  
On Debian Sid (BIND 9 package), '/etc/bind/named.conf.options' is missing and this will cause the named daemon to fail to start. To fix this either create an empty file, or comment out corresponding line in '/etc/bind/named.conf'. See your syslog messages for more information.
+
== Updating the DNS Fails: dns_tkey_negotiategss: TKEY is unacceptable ==
  
 +
For details, see [[Dns_tkey_negotiategss:_TKEY_is_unacceptable|dns_tkey_negotiategss: TKEY is unacceptable]].
  
  
== New added DNS entries are not resolvable ==
 
  
If you have problems with resolving new added DNS entries using the BIND9 DLZ interface, you maybe want to check the following:
+
== Reloading the Bind9 DNS Server ==
  
The DNS zones and the metadata.ldb file in 'samba/private/dns/sam.ldb.d/' are hardlinks to 'samba/private/sam.ldb.d/'.
+
If you <code>reload</code> Bind9, you are likely to see lines similar to these in the logs:
Maybe you've copied/moved it across filesystems and the hardlinking got lost
+
named[29534]: samba_dlz: Ignoring duplicate zone
and you're now running with two different copies of the databases at the moment
 
(You can test this by adding a new DNS entry, e. g. by 'samba-tool'. If you can't
 
resolve it, check if the inodes differ).
 
  
If you 'ls -i' on the two folders, you should see, that the following files
+
You cannot <code>reload</code> Bind9 on a Samba AD DC, you must use <code>restart</code>.
have the same inodes (what indicates, that they are hard-linked):
+
You should check if logrotate is using <code>reload</code> and change it if it is>
  
# ls -lai .../samba/private/sam.ldb.d/
 
17344368 -rw-rw---- 2 root named  4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
 
17344370 -rw-rw---- 2 root named  4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
 
17344372 -rw-rw---- 2 root named  421888 11. Nov 17:53 metadata.tdb
 
 
# ls -lai .../samba/private/dns/sam.ldb.d/
 
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
 
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
 
17344372 -rw-rw---- 2 root named  421888 11. Nov 17:53 metadata.tdb
 
 
If the files in the two folders have different inode numbers, then they
 
aren't hard-links. To fix this, run
 
 
# samba_upgradedns --dns-backend=BIND9_DLZ
 
  
This will recreate the DNS files with correct hard links and permissions.
+
== Starting Bind9 DNS Server fails with "unhandled record type 65281" (Windows AD + Samba AD)==
  
Then restart BIND.
+
If when starting Bind9 DNS Server you see something like:
  
 +
samba_dlz: starting configure
 +
samba_dlz b9_format: unhandled record type 65281
 +
zone example.local/NONE: could not find NS and/or SOA records
 +
zone example.local/NONE: has 0 SOA records
 +
zone example.local/NONE: has no NS records
 +
samba_dlz: Failed to configure zone 'example.local'
  
  
== DDNS updates not working ==
+
This is likely caused because you have a Windows Server Active Directory that has WINS entries and you are joining it.
 +
To fix it, you have to disable WINS resolving in DNS of Windows Server DC direct search zones, restart Samba AD service, reload DNS config <code>samba_upgradedns --dns-backend=BIND9_DLZ</code>, and then, restart Bind9 service.
  
* Check that the file '/etc/krb5.conf' is readable by BIND.
 
  bind DLZ lookup for default_realm  , realm , domain_realm and appdefaults at /etc/krb5.conf
 
  
* Check that the configured samba4 dns.keytab  been accessible by BIND and samba4
+
----
* Check that deployed dns resolver been correctly set to samba4 AD server
+
[[Category:Active Directory]]
* Check at named.conf that the samba DLZ settings been correct at least for
+
[[Category:DNS]]
  tkey-gssapi-keytab
 
  tkey-domain
 
* Check common settings for samba4 smb.conf:
 
  kerberos method = system keytab
 
  client ldap sasl wrapping = sign
 
  allow dns updates = nonsecure and secure
 
  nsupdate command =  /usr/bin/nsupdate -g
 
* Check out if SPNEGO been not disabled while use samba4.1 and up the deployed ISC BIND package (see [[DNS#using_ISC_BIND_backend_with_secured_.2F_signed_dns_updates]])
 
* Check that TLS/SSL  are correctly deployed
 
* Check that filesystems support acl
 

Revision as of 17:08, 19 June 2019

Introduction

Samba provides support for using the BIND DNS server as the DNS back end on a Samba Active Directory (AD) domain controller (DC). The BIND9_DLZ back end is recommended for complex DNS setups that the Samba internal DNS server does not support.

The BIND9_DLZ module is a BIND9 plugin that accesses the Samba Active Directory (AD) database directly for registered zones. For this reason:

  • BIND must be installed on the same machine as the Samba AD domain controller (DC).
  • BIND must not run in a changed root environment.
  • zones are stored and replicated within the directory.

Software Architecture

Bind9 operates a threading model with the 'worker threads' concept. Each plugin has an associated mutex, so no two worker threads can call API functions provided by our plugin at once. Database access by the plugin is guarded by a fcntl lock.

Recommended Architecture

For high traffic environments, it is not recommended to use BIND9_DLZ-backed samba as a primary DNS server. Instead, use an external server that only forwards queries to BIND9_DLZ-backed samba DNS installations when the query is addressed to a zone managed by that node.

Setting up BIND

For details, see Setting up a BIND DNS Server.



Configuring the BIND9_DLZ Module

During the domain provisioning, join, or classic upgrade, the /usr/local/samba/bind-dns/named.conf file has been created.

To enable the BIND9_DLZ module for your BIND version:

  • Add the following include statement to your BIND named.conf file:
include "/usr/local/samba/bind-dns/named.conf";
  • Display the BIND version:
# named -v
BIND 9.9.4
  • Edit the /usr/local/samba/bind-dns/named.conf file and uncomment the module for your BIND version. For example:
dlz "AD DNS Zone" {
    # For BIND 9.8
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9.so";

    # For BIND 9.9
    database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_9.so";

    # For BIND 9.10
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_10.so";
    
    # For BIND 9.11
    # database "dlopen /usr/local/samba/lib/bind9/dlz_bind9_11.so";
};
The following table shows the supported BIND versions and from which version of Samba the support started:
BIND Version Supported in Samba Version
BIND 9.11 Samba 4.5.2 and later
BIND 9.10 Samba 4.2 and later
BIND 9.9 Samba 4.0 and later
BIND 9.8 Samba 4.0 and later

Setting up BIND9 options and keytab for Kerberos

Samba needs to have some options set to allow Kerberos clients to automatically update the Active Directory (AD) zone managed by the BIND9_DLZ back end and improve performance.

To enable dynamic DNS updates using Kerberos and avoid returning NS records in all responses:

  • Add the following to the options {} section of your BIND named.conf file. For example:
options {
     [...]
     tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
     minimal-responses yes;
};
  • If you provisioned or joined an AD forest or run the classic upgrade using a Samba version prior to 4.4.0, the BIND Kerberos key tab file was generated using wrong permissions. To fix, enable read access for the BIND user:
# chmod 640 /usr/local/samba/private/dns.keytab
# chown root:named /usr/local/samba/private/dns.keytab
  • Verify that your /etc/krb5.conf Kerberos client configuration file is readable by your BIND user. For example:
# ls -l /etc/krb5.conf
-rw-r--r--. 1 root named 99  2. Sep 2014  /etc/krb5.conf
  • Verify that the nsupdate utility exists on your domain controller (DC):
# which nsupdate
/usr/bin/nsupdate
The nsupdate command is used to update the DNS. If the utility is missing, see you distribution's documentation how to identify the package containing the command and how to install.

AppArmor and SELinux Integration

For details, see BIND9_DLZ AppArmor and SELinux Integration.



Starting the BIND Service

  • Before you start the service, verify the BIND configuration:
# named-checkconf
If no output is shown, the BIND configuration is valid.
  • Start the BIND service.



Testing Dynamic DNS Updates

For details, see Testing Dynamic DNS Updates.

The Lockup Problem

When a BIND thread calls one of the BIND9_DLZ plugin API calls, execution can be blocked on database access calls if locks are out on the database at the time. Unfortunately, during that time, BIND will not be able to serve any queries, even external (non-samba) queries. Bind has a "-n" option that can increase the number of worker threads but testing has shown that increasing this number does not fix the problem, indicating that BIND's threading and queueing models are probably a bit broken. In small-scale environments this problem is unlikely to come up, but, in high-traffic environments, it may cause DNS outage. The only solution right now is to use an external DNS server that only forwards queries to BIND9_DLZ-backed samba DNS installations when the query is addressed to a zone managed by that node.


Troubleshooting

Reconfiguring the BIND9_DLZ Back End

Running the BIND9_DLZ back end setup automatically fixes several problems, such as recreating the Active Directory (AD) BIND DNS account (dns-*) and BIND Kerberos keytab file problems.

To fix the problem:

  • Run the auto-reconfiguration:
# samba_upgradedns --dns-backend=BIND9_DLZ
Reading domain information
DNS accounts already exist
No zone file /usr/local/samba/private/dns/SAMDOM.EXAMPLE.COM.zone
DNS records will be automatically created
DNS partitions already exist
dns-DC1 account already exists
See /usr/local/samba/private/named.conf for an example configuration include file for BIND
and /usr/local/samba/private/named.txt for further documentation required for secure DNS updates
Finished upgrading DNS
  • Restart the BIND service.


Debugging the BIND9_DLZ Module

To set a log level for the BIND9_DLZ module:

  • Append the -d parameter and log level to the module in the /usr/local/samba/bind-dns/named.conf file. For example:
database "dlopen .../bin/modules/bind9/dlz_bind9_9.so -d 3";
  • Stop the BIND service.
  • Start BIND manually to display the debug out put and to capture the log output in the /tmp/named.log file:
 # named -u named -f -g 2>&1 | tee /tmp/named.log
See the named (8) man page for details about the used parameters.

New DNS Entries Are Not Resolvable

If you create new DNS records in the directory and are not able to resolve them using the nslookup, host or other DNS lookup tools, the database hard links can got lost. This happens, for example, if you move the databases across mount points.

To verify that the domain and forest partition as well as the metadata.tdb database are hard linked in both directories, run

# ls -lai /usr/local/samba/private/sam.ldb.d/
17344368 -rw-rw---- 2 root named  4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344370 -rw-rw---- 2 root named  4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344372 -rw-rw---- 2 root named   421888 11. Nov 17:53 metadata.tdb

# ls -lai /usr/local/samba/private/dns/sam.ldb.d/
17344368 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DDOMAINDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344370 -rw-rw---- 2 root named 4251648 11. Nov 18:27 DC%3DFORESTDNSZONES,DC%3DSAMBA,DC%3DEXAMPLE,DC%3DCOM.ldb
17344372 -rw-rw---- 2 root named  421888 11. Nov 17:53 metadata.tdb

The same files must have the same inode number in the first column of the output in the both directories. If they differ, the hard link got lost and Samba and BIND use separate database files and thus DNS updates in the directory are not resolveable through the BIND DNS server.

To auto-repair the hard linking, see Reconfiguring the BIND9_DLZ Back End.


Updating the DNS Fails: NOTAUTH

If BIND uses incorrect Kerberos settings on the Samba Active Directory (AD) domain controller (DC), dynamic DNS updates fail. For example:

# samba_dnsupdate --verbose
...
update(nsupdate): SRV _gc._tcp.Default-First-Site-Name._sites.samdom.example.com DC1.samdom.example.com 3268
Calling nsupdate for SRV _gc._tcp.Default-First-Site-Name._sites.samdom.example.com DC1.samdom.example.com 3268 (add)
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
_gc._tcp.Default-First-Site-Name._sites.samdom.example.com. 900	IN SRV 0 100 3268 DC1.samdom.example.com.

update failed: NOTAUTH

To solve the problem:


Updating the DNS Fails: dns_tkey_negotiategss: TKEY is unacceptable

For details, see dns_tkey_negotiategss: TKEY is unacceptable.


Reloading the Bind9 DNS Server

If you reload Bind9, you are likely to see lines similar to these in the logs:

named[29534]: samba_dlz: Ignoring duplicate zone

You cannot reload Bind9 on a Samba AD DC, you must use restart. You should check if logrotate is using reload and change it if it is>


Starting Bind9 DNS Server fails with "unhandled record type 65281" (Windows AD + Samba AD)

If when starting Bind9 DNS Server you see something like:

samba_dlz: starting configure
samba_dlz b9_format: unhandled record type 65281
zone example.local/NONE: could not find NS and/or SOA records
zone example.local/NONE: has 0 SOA records
zone example.local/NONE: has no NS records
samba_dlz: Failed to configure zone 'example.local'


This is likely caused because you have a Windows Server Active Directory that has WINS entries and you are joining it. To fix it, you have to disable WINS resolving in DNS of Windows Server DC direct search zones, restart Samba AD service, reload DNS config samba_upgradedns --dns-backend=BIND9_DLZ, and then, restart Bind9 service.