bind 9.11.3 BIND9_FLATFILE update-policy

Rowland Penny rpenny at samba.org
Thu Oct 11 09:38:44 UTC 2018


On Thu, 11 Oct 2018 12:01:22 +0300
Sergey Urushkin <urushkin at telros.ru> wrote:

> Rowland Penny писал 2018-10-10 21:40:
> > On Thu, 11 Oct 2018 07:23:37 +1300
> > Andrew Bartlett <abartlet at samba.org> wrote:
> > 
> >> On Wed, 2018-10-10 at 14:38 +0300, Sergey Urushkin wrote:
> >> > ---
> >> > Best regards,
> >> > Sergey Urushkin
> >> >
> >> >
> >> > Andrew Bartlett писал 2018-10-10 13:04:
> >> > >
> >> > > Sergey,
> >> > >
> >> > > Can you fill us in on your use case here?
> >> >
> >> > Actually, this is just history. When we were migrating from
> >> > samba3 NT domain (that was 4.0 alfa-beta times) DLZ backend was
> >> > buggy, didn't work with bind views, didn't support zone types
> >> > mixing (plain+dlz), dhcp-dns updates (that's what left in my
> >> > memory, I could be wrong). Every of these problems could be
> >> > solved in some way, but this required additional configuring,
> >> > migration and risks, so we decided to do this later. Now all
> >> > that problems seems to be solved and dlz is really stable, so I
> >> > don't see any reason for not using DLZ/INTERNAL for new
> >> > installations. But since we still don't need features of DLZ, we
> >> > are still PLAIN, that's why I'm voting for supporting this
> >> > feature :).
> >> 
> >> The only part of this that can't be supported is views, but that
> >> could be done on another server (with a zone type of forward
> >> pointing at Samba) and leave the Samba server with a simple
> >> configuration.
> 
> By view support I meant put dlz inside view (e.g. one view with dlz,
> one without; or dlz in both but with different other zones), what is 
> possible now and, as I remember, was not possible in the early
> versions, but I could be wrong.
> 
> >> 
> >> > May be someone has a configured/patched bind version, so that dlz
> >> > breaks it, but I haven't met such. If someone has plain backend
> >> > he knows what he is doing (and can fix config files), so all we
> >> > need to support this backend without auto-breaking it in the
> >> > future - is removing dns_update.c code. And for new
> >> > installations we could describe this backend as DEPRECATED in
> >> > docs/tools.
> >> >
> >> > Fixed patch attached.
> >> 
> >> OK, how about this for a plan:
> >> 
> >> * This patch for master, then backported to 4.9 (also removing the
> >> dns_update.c code).
> >> 
> >> The rationale is also that we think that kicking bind with a rndc
> >> reload can crash bind (sadly we can't reliably reproduce), we
> >> can't do
> > 
> > If you run 'bind9 reload' you get this:
> > 
> > Oct 10 19:28:12 dc3 named[5261]: Loading 'AD DNS Zone' using driver 
> > dlopen
> > Oct 10 19:28:12 dc3 named[5261]: samba_dlz: starting configure
> > Oct 10 19:28:12 dc3 named[5261]: samba_dlz: Ignoring duplicate zone
> > '0.168.192.in-addr.arpa' from
> > 'DC=@,DC=0.168.192.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com'
> > Oct 10 19:28:12 dc3 named[5261]: samba_dlz: Ignoring duplicate zone
> > 'samdom.example.com' from
> > 'DC=@,DC=samdom.example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=samdom,DC=example,DC=com'
> > Oct 10 19:28:12 dc3 named[5261]: samba_dlz: Ignoring duplicate zone
> > '_msdcs.samdom.example.com' from
> > 'DC=@,DC=_msdcs.samdom.example.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=samdom,DC=example,DC=com'
> > Oct 10 19:28:12 dc3 named[5261]: samba_dlz: shutting down
> > 
> >> the version detection at runtime, can't tell if we are in
> >> BIND9_FLATFILE and shouldn't be doing that on a timer tick for 99%
> >> of installs.
> 
> Agreed.
> 
> >> 
> >> * Then mark as DEPRECATED and remove BIND9_FLATFILE from provision
> >> in master for 4.10.
> >> 
> > 
> > Good idea.
> 
> BIND9_FLATFILE is the only method to use dns server on another
> physical server 

Yes, but you shouldn't be running the dns server on another server, the
dns info is stored in AD.

> and/or mix usual bind update keys (e.g.isc-dhcp) with
> gssapi update keys for one zone. While I can not tell why someone
> would need this with current ready-to-use solutions, this is possible
> and fully working configuration (for clients it is absolutely the
> same; admins could write it's own update rules, and use nsupdate
> instead of samba-tool - I can confirm).

And I can confirm that you can use nsupdate with the dns info stored in
AD, even with an isc-dhcp-server

> So why removing?

Because it doesn't work as BIND9_DLZ does and how AD expects.

> After modifying dns_update.c code, this option will 
> require minimal support,

It will require even less support if it is removed, it was only used
because some distro's didn't have a version of bind9 that supported
dlz, these distro's are now EOL.


> it will not break running installations, I
> can imagine minimal config template modification if BIND developers
> change something again (will it ever happen?).
> I'm talking about DEPRECATED -> NOT RECOMMENDED and describing this
> in the docs.
> 
> Or if you really-really want to remove this, we could at least write 
> some info about possibility of using bind9 with the flat files in the 
> docs/mans/wiki.
>

Why would we want to tell people about using something that has been
removed ? 

> Also, I have tested the patch before sending - it works for me.

Yes, it may work in the way you perceive to be correct, but it isn't a
supported way and probably isn't working as AD requires.

Rowland

> 
> > 
> >> We can do this on a more accelerated schedule than normal because
> >> existing installations, unchanged, won't notice anything.
> >> 
> >> What do you think?  Alternately it might be simpler to just:
> >> 
> >> * Remove the provision and dns_update.c code from master for 4.10,
> >> leave 4.9 alone.  Bypass our normal feature deprecation rules
> >> because existing installs will continue to just work, add a note
> >> to WHATSNEW.
> >> 
> > 
> > No, I think we should stick to the deprecate, then remove method,
> > just do it faster this time.
> > 
> > Rowland
> 
> 
> ---
> Best regards,
> Sergey Urushkin




More information about the samba-technical mailing list