[Freeipa-devel] A new proopsal for Location Based Discovery

[Petr Spacek]

On 22.1.2013 01:59, Simo Sorce wrote:
> Hello FreeIPA developers and other followers,

> Roaming/Remote clients
> Roaming clients or Remote clients have one big problem, although they
> may have a default preferred location they move across networks and the
> definition of 'location' and 'closest' server changes as they move. Yet
> their name is still fixed. With a classic Bind setup this problem can
> somewhat be handled by using views and changing the DNAME returned or
> directly the SRV records depending on the client IP address. However
> using source IP address is not always a good indicator. Clients may be
> behind a NAT or maybe IP addressing is shared between multiple logical
> locations within a physical network. or the client may be getting the IP
> address over a VPN tunnel and so on. In general relying on IP address
> information may or may not work. (There is also the minor issue that we
> do not yet support views in the bind-dyndb-ldap plugin.)
>
>
> Addressing the multiple locations problem
> The reason to define multiple locations is that we want to redirect
> clients to different servers depending on the location they belong to.
> This only really makes sense if each location has its own (set of)
> FreeIPA server(s).
>
> Also usually a location corresponds to a different network so it can be
> assumed the if at least one of the FreeIPA servers in each location is a
> DNS enabled server and the local network configuration (DHCP) server
> serves this DNS server as the primary server for the client then we can
> make the reasonable assumption that a client in a specific location will
> generally query a FreeIPA server in that same location for
> location-specific information.
>
> If this holds true then changing the 'default' location base on the
> server's own location would effectively make clients stick to the local
> servers (Assuming the location's SRV records are properly configured to
> contain only local server, which we can insure through appropriate
> checks in the framework)
>
> This is another simple optimization and works for a lot of cases but not
> necessarily all. However this optimization leads to another problem.
> What if the client needs to belong to a specific location indipendetly
> from what server they ask to, or what if we really only have a few
> FreeIPA DNS servers but want to use more locations ?
>
> One way of course is to create a fixed DNAME record for these clients,
> so the defaults do not kick in. However this is rather final. Maybe the
> clients needs a preference but that preference can be overridden in some
> circumstances.
>
>
> Choosing the right location
> So the right location for a client may be a combination of a preference
> and a set of requirements. One example of a requirement that can trump
> any preference is a bandwidth constrained location.
>
> Assume we have a client that normally resides in a large location. This
> location has been segmented in small sublocations to better distribute
> load so it has a preferred location. If we use a fixed DNAME to
> represent this preference when this client roams to a bandwidth
> constrained network it will try to use the slow link to call 'home' to
> his usual location. This may be a serious problem.
>
> However if we generate the default location dynamically we can easily
> have rules on the bandwidth constrained location DNS servers that no
> matter what is the preference any client asking for location based SRV
> records will always be redirected to the local location which includes
> only local servers in their SRV records.
>
> This is quite powerful and would neatly solve many issues connected with
> roaming clients.

I see two ways how to achieve server controlled "location override" as 
described above.

First way is about dynamically changing the _location.client DNAME record, as 
Simo proposed above.

Second way is about making DNS sub-tree "_locations.domain" per-server 
specific. In that case, client's _location DNAME record points to same 
("preferred") location all the time, but real records under 
"preferred._locations.domain" can point to local or remote servers, it depends 
on configuration.

Creating per-server _locations sub-tree is very easy with current code: Simply 
copy&paste new bind-dyndb-ldap section to /etc/named.conf and point base DN to 
some server-specific part of LDAP tree:

dynamic-db "ipa-local" {
/<snip>/
         arg "base cn=srv2.example.com, cn=dns-local, dc=example,dc=com";
}

Server specific _locations records live in this sub-tree and each server has 
have own view of _locations, i.e. each server could specify mapping between 
locations in own way. DNS clients will see merged DNS tree, no change on 
client side is required.

E.g. client has preferred location "brno" but the client is connected to 
network in "nyc", i.e. DNS queries are sent to servers in NYC. NYC server has 
own "_locations" sub-tree with trivial mapping "brno DNAME nyc".

How to read the result: Location "Brno" is too far from "NYC", use "NYC" 
anyway! Also, "default" location could prefer local server over remote ones, 
i.e. local clients without any configuration will prefer local servers.

There is another nice feature: "old" _ntp._udp.domain SRV records could 
contain aliases pointing to SRV records in some location, e.g. "default". In 
that case also old clients will prefer local servers over remote ones - almost 
with no price and with no client reconfiguration.

No new concepts, no new code :-)

There is still _location DNAME record under client's name, that stay 
unchanged. Personally, I don't like any on-the-fly record generation. Is it 
really necessary?
In case described above I don't think so. Roaming between locations don't 
require changing any record, so configuration is static.

Old clients would see "default" location and _location record for new clients 
could be created during ipa host-add or something similar.

IMHO client fall-back "try own hostname and then try configured domain if own 
hostname doesn't contain _location" is reasonable and doesn't enforce new 
records at all. Admin always could create _location records if he has legacy 
system and default configuration doesn't fit him.


> DNS Slave server problem
Without dynamic record generation it would be possible to do zone transfers 
without any change to current code. Only one new zone (i.e. _locations part of 
DNS sub-tree) has to be set on each slaves and we are done.


> Server Implementation
> TODO: interaction with DNSSEC
That it *very* important part. I have fear from so many dynamic things inside.

-- 
Petr^2 Spacek