[Freeipa-users] DNS views: request for comments

[Martin Kosek]

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]
> 
>> Proposal - variant A ("classical" views)
>> ====================
>> - keep it simple :-)
>> - single level inheritance, all views inherit from 'base' (Base is our current 
>> cn=dns subtree, so old and new plugins can co-exist. The base can be empty.)
>> - 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 the 'base' can be overriden (deleted/replaced) in any 
>> view
>> - changes done to the base are propagated to all views
>>
>> LDAP schema
>> -----------
>> My goal is to maintain 1:1 mapping between "name+view" pair and LDAP DN. This 
>> is crucial for DNS updates. The other option is to maintain some 'record->LDAP 
>> DN database' or do a LDAP search before each DNS update - I would like to 
>> avoid that.
>>
>> Each view is stored as separate object under cn=dns.
>> DN: idnsView=view1, cn=dns
>> - this object stores settings specific to particular view (allowed clients, 
>> recursion ...)
>>
>> Zone in particular view is stored inside view container:
>> DN: idnsName=zone1, idnsView=view1, dn=dns
>> - this object can be empty container
>> - attributes without explicit configuration are inherited from the base
>> - a zone doesn't appear in the DNS view if the container is not present (i.e. 
>> it is possible to hide the zone from particular view)
>> 'Override' records for particular name in zone and view are stored as:
>> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns
> 
> 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).
> 
>> - 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 ?
> Is this the actual desired outcome maybe ?
> 
> Should we allow Dynamic Updates in Views at all ?
> 
>> - 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 :)
> 
> 
> 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 ?
> 
> 
>> LDAP schema
>> -----------
>> Group of shared records - container:
>> DN: idnsRecordGroup=group1, cn=dns
>>
>> One shared name:
>> DN: idnsName=record1, idnsRecordGroup=group1, cn=dns
>> - contains DNS records for that name as usual
>>
>> Each view is stored as separate object under cn=dns.
>> DN: idnsView=view1, cn=dns
>>
>> Zone in particular view is stored inside view container:
>> DN: idnsName=zone1, idnsView=view1, dn=dns
>> - zone has a attribute with DNs of inherited record groups
>>
>> 'Override' records for particular name in zone and view are stored as:
>> DN: idnsName=name1, idnsName=zone1, idnsView=view1, cn=dns
>>
>>
>> After each change to any data we have to compute new resulting value. It means 
>> to combine the data for particular name from all record groups and then apply 
>> overrides for particular instance.
>>
>> It means a lot of bookkeeping after each change ...
>>
>>
>> Proposal - variant 0
>> ====================
>> Do not implement it in bind-dyndb-ldap and wait if Martin Basti succeeds with 
>> his thesis. He is trying to design and implement some generic/pluggable 
>> LDAP<->DNS synchronization mechanism.
>>
>> Personally, I think that variant "0" is the best one! :-D One of side effects 
>> is that our depedency on BIND 9 will be lowered and most of the work will be 
>> deferred to the real DNS server.
> 
> 
> Synchronization is always very, very hard, especially when you throw in
> the word 'generic'. Especially problematic are races. I would proceed
> with A unless there is solid evidence this can work with all corner
> cases and in a short period of time.
> 
> Simo.


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,
especially when speaking about synchronization corner cases. Martin's thesis
may prove me wrong, we will see.

Martin