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

[Petr Spacek]

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