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

Reply via email to