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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
