[Samba] [SOLVED] samba_dlz Failed to configure reverse zone

[Lars Hanke]

Last month I struggled with a severe DLZ issue and today I could solve 
it. Credits for the important idea go to Peter Serbe, thanks!

I checked the DNS contents using RSAT. There was nothing wrong with SOA 
nor NS entries, but the reverse zones were actually forward zones with 
proper names in the in-addr.arpa. domain. I built proper reverse zones 
and deleted the forward-reverse zones and Bind DLZ did not complain 
anymore and can resolve all hosts on all directions.

The remaining questions is: Since I never created any reverse zones 
manually, how have these zones been created?

Thanks,
  - lars.

Am 29.12.2014 um 21:33 schrieb 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.
>