similar to: DNS not exactly fixed

On 29/12/14 09:40, Lars Hanke wrote: > And some more information about this strange effect apparently no-one > has seen before. > > I now added the missing zone: > > samba-tool dns zonecreate verdandi 10.16.172.in-addr.arpa -U > Administrator > > and it claims that the zone is okay, but the next one is missing: > > Dec 29 10:31:12 verdandi named[2601]: Loading

And some more information about this strange effect apparently no-one has seen before. I now added the missing zone: samba-tool dns zonecreate verdandi 10.16.172.in-addr.arpa -U Administrator and it claims that the zone is okay, but the next one is missing: Dec 29 10:31:12 verdandi named[2601]: Loading 'ad.microsult.de' using driver dlopen Dec 29 10:31:12 verdandi named[2601]:

I just upgraded bind9 on my backup DC to 9.9.5-7-Debian and restarting the service failed: Dec 22 12:25:55 verdandi named[18534]: starting BIND 9.9.5-7-Debian -u bind -4 Dec 22 12:25:55 verdandi named[18534]: built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var'

I dug somewhat deeper into what is going on below and it seems even stranger. The reverse zone without SOA or NS does not even exist: root at verdandi:~# samba-tool dns query localhost 10.16.172.in-addr.arpa @ ALL -U Administrator Password for [AD\Administrator]: ERROR(runtime): uncaught exception - (9714, 'WERR_DNS_ERROR_NAME_DOES_NOT_EXIST') File

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

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

Dear Roland, and here we have one reasons / prove regarding Debian and current Samba BIND DLZ issues : http://metadata.ftp-master.debian.org/changelogs//main/b/bind9/bind9_9.8.4.dfsg.P1-6+nmu2+deb7u3_changelog MSG >> " * disable dlz until we get a patch to make it build again" Well Debian Maintainers seems seeking missing the dlz patches that RHEL & SLES maintainers created

It did happen again and this time I was a little less panicked and took some time to figure out what happened. On my primary DC (SAMBA) I did not notice anything extraordinary. However, my secondary (VERDANDI) reported issues: root at verdandi:~# samba-tool drs showrepl Default-First-Site-Name\VERDANDI DSA Options: 0x00000001 DSA object GUID: a03bbb51-1dca-44ae-a4d9-7aa8cb4a1ace DSA

-------- Original-Nachricht -------- > Datum: Fri, 23 Nov 2012 14:32:31 -0800 > Von: Matthieu Patou <mat at samba.org> > An: samba at lists.samba.org > Betreff: Re: [Samba] samba4 binddlz performance > On 11/19/2012 07:11 AM, Thomas Manninger wrote: > > Hello, > > > > i am using samba4rc2. > > > > I have problems with the bind9 dlz module, i get

I have 2 AD DC and apparently there is something wrong with the replication. samba-tool drs showrepl returns kinda different information for the two: ---8<----------- First DC: Default-First-Site-Name\SAMBA DSA Options: 0x00000001 DSA object GUID: b19509be-c3ee-4a58-9fc9-afd61759a23f DSA invocationId: 4f30d79d-2e9c-4235-88a1-c258b8622d23 ==== INBOUND NEIGHBORS ====

Today I had another automatic restart of my secondary DC because samba-tool drs showrepl showed errors. The restart was completed at 12:35. This is what I found in log.samba at log level 3: [2016/01/04 12:33:47.201892, 3] ../source4/rpc_server/drsuapi/getncchanges.c:2007(dcesrv_drsuapi_DsGetNCChanges) UpdateRefs on getncchanges for b19509be-c3ee-4a58-9fc9-afd61759a23f [2016/01/04

Hai Baptiste, You missed my first message but here it is again. . systemctl cat bind9 # /lib/systemd/system/bind9.service [Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target Wants=nss-lookup.target Before=nss-lookup.target [Service] EnvironmentFile=/etc/default/bind9 ExecStart=/usr/sbin/named -f $OPTIONS ExecReload=/usr/sbin/rndc reload

Hello. To follow-up this issue, since the upgrade, when i do a named reload it crash, look like there's duplicated zones. Here's the log when i trigger a reload nov 05 03:09:02 data.contoso.com named[2807]: received control channel command 'reload' nov 05 03:09:02 data.contoso.com named[2807]: loading configuration from '/etc/named.conf' nov 05 03:09:02 data.contoso.com

options { listen-on port 53 { 127.0.0.1; 172.17.2.187; }; //listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; allow-query { localhost; 172.17.0.0/16; }; allow-transfer { localhost;

On Wed, 31 Oct 2018 14:52:28 +0100 L.P.H. van Belle <belle at bazuin.nl> wrote: > Hai, >   > I've checked out the log you send and i re-read the complete thread. >   > Based on thats done and what i did see in you logs now, looks like a > * (wildcard)  entry is giving the problem. But i am not sure of that, > the wildcard bugs should be fixed, when i look in

On Mon, 6 Nov 2017 11:39:50 +0100 (CET) Maxence SARTIAUX via samba <samba at lists.samba.org> wrote: > Hello. > > To follow-up this issue, since the upgrade, when i do a named reload > it crash, look like there's duplicated zones. > > Here's the log when i trigger a reload > > > nov 05 03:09:02 data.contoso.com named[2807]: received control >

Hi Roger, I'm using Samba as AD DC in version 4.5.0 on Centos 7 with Bind9_DLZ DNS backend, Bind is 9.9.4 and I don't have that issue. I tried reload my bind using systemctl at first and no issue, then I tried "rdnc reload" to be sure rndc was used, still no issue. By no issue I don't mean log are clean, I mean the DNS service is working well (tested using dig commands).

Hum... what are these logs related to GeoIP? Perhaps this answer will be a bit rough... anyway: MS AD is complex. Samba team did a great job to reproduce its behaviour but MS product are not reputed to be too stable, so a work-in-progress reproduction of such tool has few chances to be too stable. DNS is complex by itself, especially when using Bind as backend: Bind can do lot of things related

Hello! After updating (only one dc) for samba 4.5.3 is occurring duplicate zone errors, when I run rndc reload Samba_dlz: Ignoring duplicate zone This replied to all my dcs ... When I run: Samba_dnsupdate --verbose --all-names I get the error Update failed: NOTAUTH .... .... Update failed: NOTAUTH Failed nsupdate: 2 Failed update of 21 entries Like this topic to have reference to this,

Hello Rowland, I have already checked and the DN's are in AD, see attached. SOA: <domain>.corp. 3600 IN SOA psad102zadprh.<domain>.corp. . 9766 3600 600 86400 3600 See below NS, but the 1st NS (zatprdc001) doesn't exsit, and I cannot find it anywhere. NS: <domain>.corp. 3600 IN NS zatprdc001.<domain>.corp. <domain>.corp. 3600