> Nobody has looked into it yet. Likely just an extra build rule > required, I would need to see the 9.11 and 9.12 DLZ header files to > check. > > Aaron Haslett (CC'ed) may be able to help once he fights past the other > BIND9 issues he is looking at. > > Andrew BartlettThanks for response. I actually looked it myself. Since there is no DLZ ABI changes since 9.11, I reckon as it would be easy as making "python/samba/provision/sambadns.py" aware of Bind 9.12 will do the job without any hassle. Any extra build routine for 9.12 will do things complicated without a sensible reason. I prepared a patch and tested it locally. It seems it just works fine during provision and as a dns backend. Patch attached. Regards. -- Taner Tas <taner76 at gmail.com>
On Thu, 2018-08-02 at 22:37 +0300, Taner Tas wrote:> > Nobody has looked into it yet. Likely just an extra build rule > > required, I would need to see the 9.11 and 9.12 DLZ header files to > > check. > > > > Aaron Haslett (CC'ed) may be able to help once he fights past the other > > BIND9 issues he is looking at. > > > > Andrew Bartlett > > Thanks for response. I actually looked it myself. Since there is no > DLZ ABI changes since 9.11, I reckon as it would be easy as making > "python/samba/provision/sambadns.py" aware of Bind 9.12 will do the > job without any hassle. > > Any extra build routine for 9.12 will do things complicated > without a sensible reason. I prepared a patch and tested it locally. > It seems it just works fine during provision and as a dns backend. > > Patch attached.Thanks for comfirming that. That said, I would prefer the extra 9.12 (identical) .so from the build system just because otherwise I'll spend my days telling folks it will work when they ask why it loads 9.11 into 9.12. Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Development and Support, Catalyst IT https://catalyst.net.nz/services/samba
On Fri, 03 Aug 2018 12:28:38 +1200 Andrew Bartlett <abartlet at samba.org> wrote:> On Thu, 2018-08-02 at 22:37 +0300, Taner Tas wrote: > > > Nobody has looked into it yet. Likely just an extra build rule > > > required, I would need to see the 9.11 and 9.12 DLZ header files to > > > check. > > > > > > Aaron Haslett (CC'ed) may be able to help once he fights past the other > > > BIND9 issues he is looking at. > > > > > > Andrew Bartlett > > > > Thanks for response. I actually looked it myself. Since there is no > > DLZ ABI changes since 9.11, I reckon as it would be easy as making > > "python/samba/provision/sambadns.py" aware of Bind 9.12 will do the > > job without any hassle. > > > > Any extra build routine for 9.12 will do things complicated > > without a sensible reason. I prepared a patch and tested it locally. > > It seems it just works fine during provision and as a dns backend. > > > > Patch attached. > > Thanks for comfirming that. That said, I would prefer the extra 9.12 > (identical) .so from the build system just because otherwise I'll spend > my days telling folks it will work when they ask why it loads 9.11 into > 9.12. > > Andrew BartlettThanks. I want to notice that, you'll follow the same routine for 9.13 that seems ABI remains same, and maybe for other next releases. So, this is right time for decide which strategy you will follow. As myself, I opt for simplicity, extra build routine may added only when really needed. By this way, we are able to follow ABI changes with each separate "dlopen" line in named.conf.dlz. This is just my thought as an user. As developers, you are the ones who's going to deal with all odds afterwards. I can send a patch for build extra dlz module for 9.12. I can send it if you interested. Regards. -- Taner Tas <taner76 at gmail.com>
Hi, I recently noticed that when doing "samba_dns --all-names --verbose" against Bind-9.12, I can't update dns records. I'm getting these error messages for each record to update: . . . update failed: REFUSED Failed nsupdate: 2 update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.samdom.com alpine.samdom.com 389 Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.samdom.com alpine.samdom.com 389 (add) Successfully obtained Kerberos ticket to DNS/alpine.samdom.com as ALPINE$ Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; UPDATE SECTION: _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.samdom.com. 900 IN SRV 0 100 389 alpine.samdom.com. update failed: REFUSED Failed nsupdate: 2 Failed update of 34 entrier ----- This is Bind-9.12 log during operation: daemon.err [6942]: samba_dlz: spnego update failed daemon.info [6942]: client @0x562790c4cc40 127.0.0.1#53705/key ALPINE\$\@samdom.com: updating zone 'samdom.com/NONE': update failed: rejected by secure update (REFUSED) daemon.info [6942]: samba_dlz: cancelling transaction on zone samdom.com daemon.info [6942]: samba_dlz: starting transaction on zone samdom.com daemon.err [6942]: samba_dlz: spnego update failed daemon.info [6942]: client @0x562790c45d20 127.0.0.1#43211/key ALPINE\$\@samdom.com: updating zone 'samdom.com/NONE': update failed: rejected by secure update (REFUSED) daemon.info [6942]: samba_dlz: cancelling transaction on zone samdom.com ----- Same setup works on Bind-9.11. I didn't encounter this problem earlier because "samba_dnsupdate" runs fine but since it doesn't force an update, its behaviour has misled me. When bind service first launch, dlz module is loading fine: daemon.info named[7317]: Loading 'AD DNS Zone' using driver dlopen daemon.info [7317]: samba_dlz: started for DN DC=samdom,DC=som daemon.info [7317]: samba_dlz: starting configure daemon.info [7317]: samba_dlz: configured writeable zone 'samdom.com' daemon.info [7317]: samba_dlz: configured writeable zone'_msdcs.samdom.com' daemon.info [7317]: none:103: 'max-cache-size 90%' - setting to 7185MB (out of 7984MB) alpine daemon.info [7317]: set up managed keys zone for view _default, file 'managed-keys.bind' ----- I'm trying to find the cause of the problem. Maybe related to this: "Previously, update-policy local; accepted updates from any source so long as they were signed by the locally-generated session key. This has been further restricted; updates are now only accepted from locally configured addresses. [RT #45492]" https://kb.isc.org/article/AA-01554/0/BIND-9.12.0-Release-Notes.html --- Taner Tas