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

[Simo Sorce]

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 generic and usable with other LDAP
servers and not be tied so strictly to 389ds.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York