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

[Dmitri Pal]

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 at 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/