[Freeipa-users] DNS views: request for comments

[Simo Sorce]

On Tue, 2013-10-22 at 18:14 +0200, Petr Spacek wrote:
> On 22.10.2013 16:44, Martin Kosek wrote:
> > On 10/21/2013 10:57 PM, Simo Sorce wrote:
> >> Comments inline.
> >>
> >> On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote:
> >>> On 1.10.2013 17:11, Petr Spacek wrote:
> >>
> >> [trim]
> 
> I should make one thing clear:
> We already do two-way synchronization between LDAP and DNS server (run-time).
> 
> Persistent search (and now syncrepl) dumps content of LDAP database to a 
> internal database in DNS server and the bind-dyndb-ldap plugin operates on 
> this internal database. I.e. changes done in LDAP are asynchronously applied 
> to internal database and vice versa, changes done via DNS protocol are written 
> back to LDAP.
> 
> This is why we are able to apply any change in LDAP almost immediatelly to DNS 
> data. It is true that there are nasty corner cases, but up to now we didn't 
> receive many complains about data inconsistency. (This will change after the 
> major refactoring in bind-dyndb-ldap 4.0 :-))

Yes but this synchronization is tightly coupled and controlled and only
the LDAP data is considered authoritative.

It's quite different from using things like zone transfers to perform
some sort of 'generic' synchronization.

[..]

> >> Doesn't this scheme means you always have to do 2 searches ? One to find
> >> if the object is in the view and one to the base ?
> >>
> >> We could use multivalued RDNs to achieve something similar but that will
> >> require you only one search (assuming it matters).
> 
> Reading = 0 searches :-D Psearch/SyncRepl delivers the data from LDAP 
> asynchronously to the plugin, almost immediatelly after each change in LDAP.

This is true only with the current specific implementation, I think we
want to create a schema that can be used with an alternative
implementation w/o forcing the use of syncrepl/psearch and
synchronization.

> >>> - values added on top of inherited set are represented as normal DNS
> >>> attributes: e.g. aRecord: 192.0.2.1
> >>> - values deleted from inherited set - *are open question*: It would be great
> >>> if we could store it under the same object as additions, it would make
> >>> implementation a bit simpler.
> >>> - Would it be acceptable to store override 'delete TXT record "hello"' as
> >>> attribute 'tXTRecord;x-deleted: test'?
> >>
> >> I think this would be acceptable, however what happens if then someone
> >> deletes the base object and later on again recreates it ?
> >>
> >> Will the view still 'mask' it ?
> My original idea was: "Yes, it will." The main reason is that user can have 
> some tools which do LDAP delete/add instead of replace/modify, so some data 
> from the base could be accidentally exposed if we delete 'override' 
> automatically with base object.

Ok.

> >> Is this the actual desired outcome maybe ?
> This is a good question :-) This is most generic/powerful mechanism but it 
> could create some nasty surprises. One drawback is that you have to go and add 
> 'mask'/'delete' record to affected views (if necessary) when you add a record 
> to the base.

As long as it is possible it is not surprising, I would expect that when
using inheritance.

> Another variants:
> aa) Do overrides on name-level instead of record level. I.e. records for 
> particular name will not be inherited if the override is present.
> 
> Example:
> Base definition:
> - gateway.example.com. A   203.0.113.66
> - gateway.example.com. TXT "this record came from base"
> - example.com          MX  10 gateway.example.com.
> 
> View definition:
> - gateway.example.com. A 10.1.1.1
> 
> Result - view:
> - gateway.example.com. A  10.1.1.1
> - example.com          MX 10 gateway.example.com.

I think this is preferable indeed.

> => A and TXT records from base were not inherited because override for the 
> name 'gateway' was present in the view.
> => MX record for name 'example.com' was inherited because there is no override 
> with this name in the view.
> => Modification done in 'base' will not affect view in any way if the override 
> is present, so there can't be information leak.
> => This approach doesn't require ;x-deleted or cn=deleted trick.

It till requires an empty object to mask though, but that is fine I
think, I like this better.

> ab) No inheritance at all.
> This is what BIND9 does if dynamic updates are enabled. After first update the 
> inheritance relationship is broken and views operate independently.

I am not sure what this means exactly, our server uses Dynamic Updates
by default, so I am not sure that 'breaking inheritance' on dynamic
updates makes much sense, we'd have no inheritance at all.

> Obviously, this is simplest and clearest solution. Maybe that it is enough for 
> most users, look at the support in open source software ...
> 
> Maybe that some UI support for copying from one view to the other would be enough?

It is certainly a first implementation option.
Start w/o inheritance but do not preclude the option of adding it later.

> >> Should we allow Dynamic Updates in Views at all ?
> It would be too simple without dynamic updates :-)
> 
> I think that we should allow updates, otherwise we can drop all the code for 
> DNS updates from SSSD, ipa-client-install etc.
> 
> Of course, we can implement first version without support for updates and add 
> it later, if there is a demand. We just need to keep it in mind during design.

The problem with updates in views is that generally views are returned
based on the origin of the client.

now if you have laptops and you get the laptop outside of the company
then it could try to issue DNS updates, but given it is "outside" it
would be associated to the "external" view ?

I do not think you'd want to allow a laptop to update the external view
in that case.

Granted a company like that should probably have an internal zone for
laptops that is not exposed at all ... but there will certainly be
cases, esp in small setups.

Perhaps it should be somehow optional.

> >>> - The other option is to store deleted attributes in separate object:
> >>> DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns
> >>
> >> This sound cumbersome and require a 3rd search for every query, nack :)
> Again, 0 searches because of syncrepl :-)

Shouldn't depend on syncrepl for the general schema design imo, unless
there is a very strong degradation of performance trying not to.

> >> I like variant A, I think it is the most sensible and the only one
> >> really needed. People have an internal view and want to 'filter' it some
> >> for the external world or similar.
> >>
> >>
> >>> Proposal - variant B (shared record groups)
> >>> ====================
> >>> - not so simple to implement, especially update-performance could be an issue
> >>> - multiple zones can share the same record group
> >>> - each view can contain arbitrary zones anf those zones can inherit arbitrary
> >>> record groups - inheritance is fully configurable
> >>> - the data in views can be modified via DNS updates, a change done to
> >>> inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is
> >>> shared between View1 and View2. Value change in View1 doesn't affect View2.
> >>> - particular record from any shared record group can be overriden
> >>> (deleted/replaced) in any zone in any view
> >>> - changes done to the shared record group are propagated to all views (this is
> >>> the hard part!)
> >>
> >> Sound very complex not only to build, but to explain to admins as well,
> >> is anyone actually going to need this level of complexity, what scenario
> >> would really benefit from this that can't be done with A ?
> I can see one use case:
> 
> Domains 'flower-eshop.com' and 'parfums-eshop.com' are hosted in 'data centre 
> 1', while domains 'car-eshop.com' and 'software-eshop.com' are hosted in 'data 
> centre 2'.
> 
> Typically it means that sites in one DC/group share the same set of NS 
> records, MX records etc.
> 
> So the admin will define record group "DC1":
> NS ns1.dc1.examplewebhoster.com.
> NS ns2.backup.examplewebhoster.com.
> MX 10 mx1.dc1.examplewebhoster.com.
> MX 20 mx1.dc2.examplewebhoster.com.
> 
> Record group "DC2":
> NS ns1.dc2.examplewebhoster.com.
> NS ns1.backup.examplewebhoster.com.
> MX 20 mx1.dc1.examplewebhoster.com.
> MX 10 mx1.dc2.examplewebhoster.com.
> 
> Now record group DC1 is assigned to servers hosted at DC1 and so on.
> Result = new mail server for DC1 has to be added to single place (the record 
> group DC1) and all domains hosted at DC1 will automagically pick up the new 
> server.
> 
> So you don't need to construct cycles over all servers in DC1, modify each 
> record by hand etc.
> 
> This sounds nice 'on the paper', but I don't know how big the real demand is ...

I do not see this as being very interesting in a FreeIPA scenario, but
I'd like to hear from actual users here.

[..]

> > I read all the proposals, I would personally stick with variant A as this is
> > something that is doable in near future. Variant 0 seems a bit utopic to me,
> One year, may be. Views are pretty complex thing - don't forget to integration 
> with DNSSEC ...
> 
> > especially when speaking about synchronization corner cases. Martin's thesis
> 
> Please see the note at the beginning of my e-mail. We already do two-way 
> synchronization in bind-dyndb-ldap.

As said, generic synchronization (especially 2 way) is quite different
from tightly coupled sync, especially when you define a clear
authoritative copy you can always revert to.

> > may prove me wrong, we will see.
> 
> Sure. Stand-alone daemon usually has some specific problems which are not so 
> problematic for plug-ins, we will see.

Indeed, will see.
Thanks for the work done so far, good thinking as usual.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York