bind 9.11.3 BIND9_FLATFILE update-policy

Thu Oct 11 09:49:11 UTC 2018

On Thu, 2018-10-11 at 12:01 +0300, Sergey Urushkin 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.

Correct, you need to stop doing fancy DNS things on your DC, that is
what other hosts are for. 

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

Correct, but can you explain a little more why you need this? 
(Compared with a zone type of 'forward' pointing at your DC).

>  and/or mix usual bind update keys (e.g.isc-dhcp) with gssapi 
> update keys for one zone. 

While ugly, there are scripts for this, using gss-tkey.  It may also be
possible to patch our internal DNS server, and even perhaps bind, to
accept those static keys, if anybody really wants that. 

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

Samba has traditionally been a 'do whatever you want, here are the
parts' kind of place, and we have seen some incredible things built
with Samba that way.

The AD DC part has mostly been the opposite:  Here is one working
pattern (mostly).  

In the past little guidance and much flexibility was given to
administrators on how to construct their Samba classic/NT4-like
domains, and so it was uniformly hard to configure, hard to debug and
hard to develop (because who knows who is using it strangely). 

On the flip side, by being strict, making there be 'only one way' and
producing a product, not a kit of parts the AD DC has actually gained a
level of polish and our installations a level of consistency that has
made Samba quite successful as an AD DC. 

Finding the right middle ground is hard, but this is why we push back
at 'creative solutions' so much.

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

My main fear is that this is something that 'seems to work' but really
doesn't and we just mislead folks into thinking this is a viable
option.

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

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba