On Tue, 2012-05-29 at 17:16 +0200, Petr Spacek wrote: > Hello, > > for clarity: I'm not going to implement it (now). There are another features > on the table. > > I'm trying to find simplest solution/workaround, because several people asked > for this feature and I think it is quite important. (Besides load-balancing > purpose it can be handy for environments with NAT in place - as Amazon EC2.) > Discussion about major changes should be read as "design for far future". > > On 05/25/2012 04:10 PM, Simo Sorce wrote: > > On Thu, 2012-05-24 at 19:07 +0200, Petr Spacek wrote: > >> Hello, > >> > >> some time ago there was a request for DNS to support "routing requests to > >> local servers". Any opinions if/when do it and proposals how to do it are > >> more > >> than welcome. My best knowledge about this problem follows: > >> > >> > >> This request actually means "differentiate answer to DNS query on client's > >> IP > >> address basics". > >> Relevant thread on ipa-users-list: > >> https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html > >> > >> First question is: Do we want to implement it? > >> (IMHO it is very important for large-scale deployments.) > > > > I am not really sure I like it, as it makes things quite difficult to > > handle. > > > > Please think how we are going to operate if you ahve a view dfined and a > > client does a dyn DNS update. > Yes, it's a bit difficult. I propose this approach: > > - add new record -> add it to "base" (shared) part > - delete record -> delete "visible" record: i.e. delete override record if it > is present, delete "base" record otherwise.
not sure this is the right thing, when you delete you should probably delete all, or adding back will fail. > It allows clients to update own records as usual and changes will be visible > to the whole world. Which may not be the desired outcome actually :-/ > One potential problem are update scripts from monitoring systems. Monitoring > system can test availability of server and dynamically adjust DNS records, if > server status has changed. > I'm not sure if some monitoring systems supports this feature directly, I > always used my own scripts. These scripts have to be changed from > nsupdate/another tool to ldapmodify, but I think it is acceptable. Custom systems can adapt indeed. > ...snip ... > > >> Adam and I discussed possible approaches. We agreed on "stackable" > >> approach: > >> - Store whole original DNS tree in one subtree, let say "base". > >> - Create "override" subtrees for each "locality" = set of customized > >> records. > >> Shared records are only in "base". During DNS query processing "override" > >> subtree is searched first. If record does not exist in "override" subtree, > >> search will continue in "base" subtree. > > > > Yes, this is my first thought too. > > > >> Second question is how to realize these "overrides": > >> - Let Directory Server to do the work. If DS supports this, it is mostly > >> done. > > Why do you need dirsrv to do anything special ? > I can save bugs in the new code (and time) if dirsrv can do it. > > I played with 389 last days and unfortunately I can't find support for this > use case. (I'm pretty sure that OpenLDAP can support this scenario - that was > a reason why I started to examine this possibility in 389.) Not sure what you wanted to do, but I would avoid implementation specific stuff. Make some things simpler and other more complex. > > The simple way is to do subtree searches, if you get back more than one > > result for a specific name then you know you have views and proceed to > > filter out the one you want. The bonus here is that you can cache all > > replies if you keep different caches per view. > > > > The alternative is to add a 'viewname' or something in the filter, but > > then you need to do 2 searches and fallbacks. This sounds more > > expensive. > > > >> 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. > I probably missed something, I don't see the problem. One bind-dyndb-ldap > instance is run for each "view" separately. Each instance has own caches and > other data structures. They don't know about each other. This is a problem, 389DS uses a lot fo resources for persistent searches. It means if you have views we'd have to disable persistent searches or enable them only in some views. Why do you need to run multiple instances ? Do each of them have its own in memory cache ? How much memory are we going to sue with many views ? I think we really need to discuss also these architectural issues. > >> 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. > You are right, if we change the way how DNS data are stored in LDAP (a bit). > Mentioned idea was to create new subtree ("cn=dns-viewname") and re-use > existing driver and all tools for managing it with minimal changes. I see too many pitfalls, seem like not a good tradeoff in this case. > > 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. > > > > Simo. > > I'm not talking about new DS plugin, I wanted to use existing features. > > IMHO OpenLDAP with rewrite/remap and rwm overlays can do all the work for us. > Unfortunately 389 is poor in this case (or I can't find it in manual). Overlay == Plugin, it'a a custom feature specific of one implementation and not defined in a standard (afaik). > Merging with another thread: > > On 05/25/2012 09:20 PM, Simo Sorce wrote: > > On Fri, 2012-05-25 at 15:52 +0200, Petr Spacek wrote: > >> > On 05/24/2012 08:00 PM, Dmitri Pal wrote: > >>> > > On 05/24/2012 01:07 PM, Petr Spacek wrote: > >>> > > > >>> > > May be I am oversimplifying things but it seems that it would make > >>> > > sense > >>> > > to just have an extra multi-value attribute added to the DNS schema. > >>> > > This attribute would contain a value that would allow the entry to > >>> > be > >>> > > included into the view. This way the base is the same and what the > >>> > view > >>> > > exposes is just a filter. The default view would have a filter that > >>> > > matches all entries like now. > >>> > > > >>> > > > >>> > > I assume that DNS server makes it decision based on the IP so it > >>> > has a > >>> > > call to get a "view" data. The ldap driver can return a filter. The > >>> > DNS > >>> > > server them makes a call using this filter to get all the records > >>> > that > >>> > > apply. I know it is too ldap centric. There is some abstraction in > >>> > DNS > >>> > > server and we do not want to change it. But the point is there are > >>> > > probably two calls in the DNS server (have not actually confirmed): > >>> > > lookup data X by IP to understand what the view is. > >>> > > Pass data X to get the actual DNS entries. > >>> > > > >>> > > I am saying that X can be filter. > >>> > > > >>> > > Thoughts? > >> > > >> > Special attribute sounds like a good idea. It is not realizable > >> > directly, but > >> > I will explore variants with some "view" attribute. > >> > > >> > Current DNS "name" (name can potentially contain multiple records) > >> > structure > >> > is following: > >> > > >> > dn: idnsname=_kerberos._tcp,idnsname=e.localnet,cn=dns,dc=e,dc=org > >> > objectClass: idnsrecord > >> > objectClass: top > >> > idnsName: _kerberos._tcp > >> > sRVRecord: 0 100 88 unused-4-107 > >> > > >> > DNS name is part of DN. It is not possible to have more objects with > >> > same DNS > >> > name and different attributes. This problem lead me to "stackable" > >> > approach. > > Yes, and we can also use multiple attributes in the same tree, although > > for clarity I probably prefer the subtree approach. > > > > So a few options: > > > > 1. all in the same subtree: > > # Normal object > > dn: idnsname=bar,idnsname=foo.org,cn=dns,dc=foo,dc=org > > objectClass: idnsrecord > > objectClass: top > > idnsName: bar > > aRecord: 192.168.12.34 > > dNSTTL: 1200 > > > > # Object belongin to the 'DMZ' view > > dn:cn=DMZ-bar,idnsname=foo.org,cn=dns,dc=foo,dc=org > > objectClass: idnsrecord > > objectClass: top > > objectClass: nsContainer > > cn: DMZ-bar > > idnsName: bar > > aRecord: 5.6.7.8 > > dNSTTL: 3600 > > idnsView: DMZ > > > > > > NOTE: I had to add nsContainer here in order to give the object a way to > > have a unique name by using the CN attribute. I am not very fond of this > > arrangement though. It is also ugly to parse out using a LDAP browser. > > It make one thing simpler in that using multiple values for dnsView you > > can assign the same entry to multiple views. > > > > 2. using per view subtrees > Generally - I like this idea. > > > # Normal object > > dn: idnsname=bar,idnsname=foo.org,cn=dns,dc=foo,dc=org > > objectClass: idnsrecord > > objectClass: top > > idnsName: bar > > aRecord: 192.168.12.34 > > dNSTTL: 1200 > I prefer to create "_default" view for normal records (as BIND does). > e.g. dn: idnsname=bar,cn=_default,idnsname=foo.org,cn=dns,dc=foo,dc=org > > It allows to treat "normal" and override records in the same way. Also it > allows to optimize query with extensibleMatch filter. > E.g. plugin is configured to serve records for "view1": Filter can be > (|(cn:dn:=view1)(cn:dn:=_default)) so LDAP server will not return unnecessary > records for view2, view3, view4 ... I don;t think that filter is standard LDAP, I do not want to rely on something like that. It is preferrable to have a idnsView attribute in the entry, so you can use a normal filter and index on it. > Another problem to solve is how to modify SOA record/hide zone/add new zone > to > view. With this view-zone-dnssubtree ordering you cannot modify SOA record or > hide the zone from certain views. Please provide more info, it is not clear to me why you can't do it. > With ordering zone-view-dnssubtree situation is better. We still can run > subtree query in 'cn=dns' and as bonus it is possible to define zone only in > some views or create modified version of zone's SOA record in another views. > > Problem is how to *not* override zone SOA record. One (not very nice) > approach: > We can create extensibleObject and define container only with idnsName extensibleObject is not ok to use except for experimentation. > attribute (necessary for RDN construction). "Real" zones from "fake" ones can > be distinguished by objectClass. Records are leaves under this zone record as > usual. Create a idnsViewZone objectclass or something like that. > > # Object belongin to the 'DMZ' view > > dn:idnsname=bar,cn=DMZ,idnsname=foo.org,cn=dns,dc=foo,dc=org > > objectClass: idnsrecord > > objectClass: top > > idnsName: bar > > aRecord: 5.6.7.8 > > dNSTTL: 3600 > > > > > > NOTE: I prefer this method as it makes things a lot easier to manage and > > view through an LDAP broiwser, however it makes sharing entries between > > multiple views a bit awkward. > I like this idea. What about LDAP aliases? (I never used them, so I don't > know.) It is not very nice, but for limited amount of "override" records it > can be sufficient. Obviously this feature will be abused, so if you start with assuming "limited" you are already on the wrong path IMO :-) > > 3. using only one 'views' subtree pr zone and dnsView to discrimnate > > > > # Normal object > > dn: idnsname=bar,idnsname=foo.org,cn=dns,dc=foo,dc=org > > objectClass: idnsrecord > > objectClass: top > > idnsName: bar > > aRecord: 192.168.12.34 > > dNSTTL: 1200 > > > > # Object belongin to the 'DMZ' view > > dn:idnsUniqueID=F6A1245-bar,cn=views,idnsname=foo.org,cn=dns,dc=foo,dc=org > > objectClass: idnsrecord > > objectClass: top > > idnsUniqueID: F6A1245-bar > > idnsName: bar > > aRecord: 5.6.7.8 > > dNSTTL: 3600 > > idnsView: DMZ > > idnsView: VPN > > > > > > NOTE: here I added also a idnsUniqueID as a way to have unique names so > > we can have multiple entries for the same record. This is so that you > > can have 3 different entries for the same record belonging to 3 > > different views. The reason why I added the actual name after a random > > id is that this way it is simpler to recognize what it is when looking > > at an ldap browser w/o having to read the actual object attributes, it > > also make collisions a lot less likely and so it allows to keep the > > random part smaller (and thus more readable). > > Also note that I've put 2 values in idnsView, meaning that this record > > belongs to 2 separate views. This allows compact representation when > > multiple views want to redefine some records in the same way (an dothers > > in a different way, thus why 2 separate views)/ > I also prefer "way 2", as I said above. I actually prefer 3 :) Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
