Re: [Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
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. It allows clients to update own records as usual and changes will be visible to the whole world. 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. ...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.) 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. 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. 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
Re: [Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
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
Re: [Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
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=vindexsearch=0x3C0AC6DAB2F928A2 signature.asc Description: OpenPGP digital signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
On Wed, 2012-05-30 at 01:28 +0930, William Brown wrote: 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. Well said, I think this is one of the other key reasons to avoid multiple plugins, and handle everything from one. Otherwise we go back to having issues with updating these configurations dynamically via LDAP (always think replication). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
On 05/24/2012 08:00 PM, Dmitri Pal wrote: On 05/24/2012 01:07 PM, 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.) It is related to IPA ticket #122 at architecture level: IPA DNS integration should support GeoIP https://fedorahosted.org/freeipa/ticket/122 IMHO it is better to support generic locations defined by user than real Geo-IP: - at least private IP addresses will be problematic - real Geo-IP database is huge and can slow all things down Bind-dyndb-ldap plugin supports BIND views already. It should be possible to define multiple plugin instances with different ldap search base and let it to serve records. The main problem problem is managing DNS subtree in LDAP. With current implementation you have to copy whole subtree to another place and then change necessary records. Problem is with maintaining base (non-overridden) records - you have to do same change n-times. 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. Second question is how to realize these overrides: - Let Directory Server to do the work. If DS supports this, it is mostly done. It do not require any change in bind-dyndb-ldap code. All merges/overrides will be done on Directory server. 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. 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. With persistent search it should be better, because all records are in memory, but basic principle remains same. Thanks for all opinions. Petr^2 Spacek 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. I'm looking into Views in DS now. Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
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. It is related to IPA ticket #122 at architecture level: IPA DNS integration should support GeoIP https://fedorahosted.org/freeipa/ticket/122 IMHO it is better to support generic locations defined by user than real Geo-IP: - at least private IP addresses will be problematic - real Geo-IP database is huge and can slow all things down Geo-IP is good for some services, mostly internet facing high availability stuff. For internal networks we should just use the location code, as Geo-IP tagging makes no sense for private networks. I say we should defer any work on Geo-IP tagging as we do not target public facing high avilability IP serving with our DNS at the moemnt (Ie I expect those people will delegate a zone to a dedicated set of DNS servers instead). Ah incidentally this means we need to start supporting zone delegation from the management UI if we do not already support that. Bind-dyndb-ldap plugin supports BIND views already. It should be possible to define multiple plugin instances with different ldap search base and let it to serve records. The main problem problem is managing DNS subtree in LDAP. With current implementation you have to copy whole subtree to another place and then change necessary records. Problem is with maintaining base (non-overridden) records - you have to do same change n-times. Using different bases would require replicating the whole database indeed with common entries you do not change per view. That's a lot of effort, and very easy to screw up. I think we really do not want to take this approach. 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 ? 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. 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
Re: [Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
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: 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.) It is related to IPA ticket #122 at architecture level: IPA DNS integration should support GeoIP https://fedorahosted.org/freeipa/ticket/122 IMHO it is better to support generic locations defined by user than real Geo-IP: - at least private IP addresses will be problematic - real Geo-IP database is huge and can slow all things down Bind-dyndb-ldap plugin supports BIND views already. It should be possible to define multiple plugin instances with different ldap search base and let it to serve records. The main problem problem is managing DNS subtree in LDAP. With current implementation you have to copy whole subtree to another place and then change necessary records. Problem is with maintaining base (non-overridden) records - you have to do same change n-times. 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. Second question is how to realize these overrides: - Let Directory Server to do the work. If DS supports this, it is mostly done. It do not require any change in bind-dyndb-ldap code. All merges/overrides will be done on Directory server. 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. 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. With persistent search it should be better, because all records are in memory, but basic principle remains same. Thanks for all opinions. Petr^2 Spacek 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
[Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
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.) It is related to IPA ticket #122 at architecture level: IPA DNS integration should support GeoIP https://fedorahosted.org/freeipa/ticket/122 IMHO it is better to support generic locations defined by user than real Geo-IP: - at least private IP addresses will be problematic - real Geo-IP database is huge and can slow all things down Bind-dyndb-ldap plugin supports BIND views already. It should be possible to define multiple plugin instances with different ldap search base and let it to serve records. The main problem problem is managing DNS subtree in LDAP. With current implementation you have to copy whole subtree to another place and then change necessary records. Problem is with maintaining base (non-overridden) records - you have to do same change n-times. 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. Second question is how to realize these overrides: - Let Directory Server to do the work. If DS supports this, it is mostly done. It do not require any change in bind-dyndb-ldap code. All merges/overrides will be done on Directory server. 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. 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. With persistent search it should be better, because all records are in memory, but basic principle remains same. Thanks for all opinions. Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] routing requests to local servers - DNS SRV [discussion needed]
On 05/24/2012 01:07 PM, 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.) It is related to IPA ticket #122 at architecture level: IPA DNS integration should support GeoIP https://fedorahosted.org/freeipa/ticket/122 IMHO it is better to support generic locations defined by user than real Geo-IP: - at least private IP addresses will be problematic - real Geo-IP database is huge and can slow all things down Bind-dyndb-ldap plugin supports BIND views already. It should be possible to define multiple plugin instances with different ldap search base and let it to serve records. The main problem problem is managing DNS subtree in LDAP. With current implementation you have to copy whole subtree to another place and then change necessary records. Problem is with maintaining base (non-overridden) records - you have to do same change n-times. 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. Second question is how to realize these overrides: - Let Directory Server to do the work. If DS supports this, it is mostly done. It do not require any change in bind-dyndb-ldap code. All merges/overrides will be done on Directory server. 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. 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. With persistent search it should be better, because all records are in memory, but basic principle remains same. Thanks for all opinions. 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? Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
