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

[support at remsnet.de]

Hello Lars 

> Betreff: Re: [Samba] [SOLVED] samba_dlz Failed to configure reverse zone
>
> 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?

you need to create them on the respective reverse dns zone master .
if your samba is the master - then use samba-tool 
see ar https://wiki.samba.org/index.php/DNS_Administration#Creating_a_new_zone_2

The reverse dns samba-dlz will fail untill zones exist and propper 
update key´s & acl´s been configured.

If reverse dns are not on the same bind9 as the samba4 server , 
then use bind9 ´s  FWD zone featger with propper keys and acls.

> 
> 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.
> >

blame samba4 ´s samba-tool, why ?

in-addr.arpa are an "internet" wide  special domain  and needs carefully handling / checks.

you´ll see the difference  while using the same bind9 with flat files :
for bind9 flat files  in-addr.arpa. and in-addr.arpa are the _same_ . 

Bugs had been filled a awhile ago without fix it - yet.


Bind9 with the DLZ Plugin provides only what the samba4 service & manage : from the LDB files.


There are some more "special" domains for ie ipv6, multicast , 


> > Regards,
> >   - lars.
> >

regards

Horst