bind 9.11.3 BIND9_FLATFILE update-policy

Rowland Penny rpenny at samba.org
Thu Oct 11 13:21:25 UTC 2018


On Thu, 11 Oct 2018 16:10:25 +0300
Sergey Urushkin <urushkin at telros.ru> wrote:

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

Okay, I have added a warning using your text to the wikipage here:
https://wiki.samba.org/index.php/Setting_up_a_BIND_DNS_Server

Rowland





More information about the samba-technical mailing list