[Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]

[William Brown]

On 25/05/12 11:40 PM, Simo Sorce wrote:
>> It do not require any change in bind-dyndb-ldap code. All merges/overrides 
>> > will be done on Directory server.
> Given we do persistent searches and we also do some caching in
> bind-dyndb-ldap we almost certainly do not want to 'fool' it by
> returning different values from DS w/o bind-dyndb-ldap knowledge.
> 
>> >  Only /etc/named.conf has to be adjusted with 
>> > right search base and "view" clause.
>> > 
>> > I asked on 389 mailing list and I'm waiting for reply:
>> > http://lists.fedoraproject.org/pipermail/389-users/2012-May/014653.html
>> > 
>> > 
>> > - Another approach is to add support directly to bind-dyndb-ldap, but it is 
>> > not so nice solution.
> Why ?
> 
>> >  In that case both LDAP search bases have to be defined 
>> > in /etc/named.conf. For each DNS query is necessary to search "override" base 
>> > first. If required record is not present then is necessary to search through 
>> > "base" subtree.
> No, you do not need to do multiple searches, you just need to filter the
> results by view.
> 
> It would make it very easy to manage if we added a 'dnsView' attribute
> to overriding entries in the subtree. This would allow us to define a
> new overriding entry and even assign it to multiple views if the
> 'dnsView' attribute is multivalued.
> 
>> > With persistent search it should be better, because all records are in memory, 
>> > but basic principle remains same.
> psearch is one of the reasons we might want a dnsView attribute base
> approach instead of playing games with DS.
> I would also prefer to avoid adding more code to DS where the bind
> plugin can easily handle this data itself. Another reason is that I
> really want this plugin code to be generic and usable with other LDAP
> servers and not be tied so strictly to 389ds.

I think Simo is on the money here. Adding this to bind-dyndb-ldap makes
the most sense. Views become a multivalued attribute, and configurable
via an idnsView object of some kind (It may even be some kind of "group"
membership even?). This would only need to be in the idnsZone
information - All records in a zone are bounded by the policies of that
zone. There is no concept of a per-record view. It would also means that
records can be correctly updated for DynDNS updates correctly.

If memory serves correctly, Named impelements views in such a way that
you update the record of the view you are updating with dyndns. So, lets
say you have a view public and private. Lets also say you were sharing a
zone between these azone.example (You were using the view to apply
attributes like recursive query permissions). When the DynDNS update
comes in, from a host matched in the "private" view, the code will go to
update the zone that the the private view references. In this case, the
update would be referenceable by both views.

In the case where you have azone.example in public and private, but each
has their own unique zone file, the dyndns update would only update the
zone that the private zone has access to - The public view is still
referencing the other data.

This functionality could easily be achieved by the plugin. When the Dns
update comes in, and that data is referenced by 2 views you have to
choose - Do you duplicate the record, with each record now representing
the data in each view, or do you update the record that is accesible by
both views? From the FreeIPA standpoint of consistency and simplicity, I
think that updating the record, provided the update comes from a view
that is able to make updates, would be a sensible solution. Spliting the
record is much hassle for no real benefit. This keeps the DNS data
intact, and consistent across all views. Views would really only affect
access policies to zones, recursive responders etc.

The best benefit of this, would be that policies of "views" could be
edited with the CLI tool or the web interface, rather than having to
edit the named.conf file. This would again simplify administration of
DNS services.


-- 
Sincerely,

William Brown

Research & Teaching, Technology Services
The University of Adelaide, AUSTRALIA 5005

CRICOS Provider Number 00123M
-----------------------------------------------------------------------------
IMPORTANT: This message may contain confidential or legally privileged
information. If you think it was sent to you by mistake, please delete all
copies and advise the sender. For the purposes of the SPAM Act 2003, this
email is authorised by The University of Adelaide.

pgp.mit.edu
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 945 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120530/b10391d1/attachment.sig>