[Freeipa-users] DNS views: request for comments

[Simo Sorce]

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.

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