bind 9.11.3 BIND9_FLATFILE update-policy

[Sergey Urushkin]

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 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).
So why removing? After modifying dns_update.c code, this option will 
require minimal support, 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.

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

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