bind 9.11.3 BIND9_FLATFILE update-policy

Sergey Urushkin urushkin at telros.ru
Thu Oct 11 13:10:25 UTC 2018


Rowland Penny писал 2018-10-11 15:57:
> On Thu, 11 Oct 2018 15:40:25 +0300
> Sergey Urushkin <urushkin at telros.ru> wrote:
> 
>> 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).
> 
> No the simplest (and the best) is to run Bind9 on the Samba AD DC.

Agreed, I mean exactly this, wrote wrong, sorry for my English.

>> 
>> >
>> >> 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 :)
> 
> No you were not, it was started by Michael Kuron, you just updated his
> script, just as I did.

I did not say I was the first.

> 
>> 
>> >
>> >> 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)).
>> 
> 
> It needs dns and it creates the records in AD, so the easiest way is to
> use those records.

The easiest, not the only. It creates dns-records, not ldap (in common 
case), that's what I'm talking about.

> 
>> >
>> >> 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
> 
> Have you ever heard of the term 'Flogging a dead horse' ???

Yes. And that's why I do not insist on saving this feature. But someone 
may flog - and this suggested text in the documentation for him.

> 
> Rowland



More information about the samba-technical mailing list