[Samba] samba_dlz Failed to configure reverse zone

[Lars Hanke]

Just to clarify some things ...

the Bind9 and Samba4 are both current Debian Jessie on amd64. So the 
applicable changelog would be 
http://metadata.ftp-master.debian.org/changelogs//main/b/bind9/testing_changelog

Using 1:9.9.5.dfsg-6 the system worked nicely. Fixing a CVE pertaining 
to recursion does not easily link to DLZ issues.

The system definitely has DLZ included. Otherwise it could not produce 
DLZ related errors and change behaviour, if sam.ldb is changes.

Using some hints from bind-users I found

ldbsearch -H /var/lib/samba/private/sam.ldb -b 
"DC=DomainDnsZones,DC=ad,DC=microsult,DC=de" "(objectClass=dnsZone)" dn

a useful command. It showed me that I added the wrong zones and that the 
zones claimed to have missing SOA and NS are actually there. To cite the 
most important parts of the logs:

Dec 29 20:24:26 verdandi named[3695]: samba_dlz: starting configure
Dec 29 20:24:26 verdandi named[3695]: zone 10.16.172.in-addr.arpa/NONE: 
has 0 SOA records
Dec 29 20:24:26 verdandi named[3695]: zone 10.16.172.in-addr.arpa/NONE: 
has no NS records
Dec 29 20:24:26 verdandi named[3695]: samba_dlz: Failed to configure 
zone '10.16.172.in-addr.arpa.'

Mind the final dot in the zone name! It's clear, but for some reason I 
forgot it over and over in the past. So listing the correct reverse zone:

root at verdandi:~# samba-tool dns query localhost 10.16.172.in-addr.arpa. 
@ ALL -U Administrator
Password for [AD\Administrator]:
   Name=, Records=2, Children=0
     SOA: serial=1, refresh=900, retry=600, expire=86400, minttl=3600, 
ns=samba.ad.microsult.de., email=hostmaster.ad.microsult.de. 
(flags=600000f0, serial=1, ttl=3600)
     NS: samba.ad.microsult.de. (flags=600000f0, serial=1, ttl=3600)

Shows that the are SOA and NS entries, i.e. it's all there is in the 
zone and in all other reverse zones as well.

The library is part of the Samba package and has not changed. So either 
Bind9 now has a bug and interfaces incorrectly with DLZ, or the DLZ 
library presents the data incorrectly and the CVE fix now denies it, or 
the library does not match Bind9 anymore.

I ran a strace, but it does not give too much information. Yes, sam.ldb 
and sam.ldb.d are accessed, so the DLZ basics should be straight, which 
somewhat rules out the last option. In between "samba_dlz: starting 
configure" and "zone ... has 0 SOA records" I only see a lot of read 
lock and unlock operations on 3 different fd, relating to files in 
sam.ldb.d: "AD DN.ldb", "DC=DOMAINDNSZONES,AD DN.ldb", 
"DC=FORESTDNSZONES,AD DN.ldb" (AD DN is the DN of the AD).

In summary: I now understand, why Bind9 would load reverse zones (they 
actually exist). I don't understand why samba-tool reports SOA and NS, 
while Bind9 claims both absent. And I'm unsure why 
10.16.172.in-addr.arpa seems to collide with 10.16.172.in-addr.arpa. 
(mind the dot). This at least smells like different parts of the code 
follow a different functional specification. But this is a side note and 
in no way important for the problem of getting Bind9 running again.

I still don't know whether I can configure it away, or should file a bug 
and to whom: Bind9 or Samba4.

Regards,
  - lars.