bind 9.11.3 BIND9_FLATFILE update-policy

[Sergey Urushkin]

Rowland Penny писал 2018-10-11 12:38:
> 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.

This is just the simplest way. Actually I could use another server which 
will be getting info from the AD via LDAP (I know it's crazy but this 
will work).

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

I know, I was the one who published such dhcp script in the forefront  
:)

> 
>> So why removing?
> 
> Because it doesn't work as BIND9_DLZ does and how AD expects.

As I know, AD (samba) just needs dns, it doesn't use ldap dns-records 
directly (except for replication and administration purposes 
(samba-tool)).

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

We are removing config generation, not an ability to use side dns 
server.
Until we stop using nsupdate for records update, we may use another 
server with tkey-gss support (or even without it).

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

I really don't understand what "AD requires" means, except ACLs. 
Incorrect ACLs in the update-policy could lead to security holes 
("administrator" is not dns/domain admin in LDAP) - and that is the 
reason to not support PLAIN in the base installation (among other 
reasons you mentioned). But even MS AD could be run with dns security 
updates disabled (you may see that the first try of updating dns-record 
from windows machine goes without auth).

I will not be surprised if one of my installations is the only one with 
the flat files :) So, if you think this should be removed, I don't mind. 
But we might mention this possibility in docs (shortly, even without 
examples):
"Samba AD could potentially be used with any dns-server that supports 
tkey-gss updates (and even without such support), but samba team doesn't 
recommend this and doesn't provide support. This may bring security 
risks."
This schema is working, until we remove nsupdate support (actually even 
after it - static records). And by this text, we will shield users from 
wrong decisions, which they could make even without our support in the 
provision script.

Just MHO, thanks.

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