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 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 # 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: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. 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'm looking into "Views" in DS now. We do not want to make this code 389DS specific, anyways, so I think we should not go there. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel