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

[Simo Sorce]

On Tue, 2013-01-22 at 15:23 +0100, Petr Spacek wrote:

> 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";
> }

Unless you have a way to mange it via LDAP this is unworkable. Locations
should be managed via the Web UI. So you need to be able to create new
locations on the fly and change server's locations dynamically, possibly
w/o requiring a server restart, but certainly w/o requiring the DNS
admin to have direct SSH access to all boxes to go and manually change
named.conf

> 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.

But this would require to manually change multiple records for multiple
servers in the same location, which could go wrong quite easily.

Each location configuration should be in a single place so that it is
consistent for all servers of that location and not a burden for
administration.

Also your methods puts location information out of the actual DNS, so
you can't lookup location data via DNS except for the 'default'.
But that would not be correct, we want to allow a client to lookup
location data for a non-default location, because an IPA DNS server may
very well be serving multiple locations.

> 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.

I am not sure how this is different from my proposal, the problem I see
is that you loose the ability to force a configuration for select client
by actually creating real DNAME records.

> 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 :-)

We can do that with a DNAME in theory, but I would rather keep current
domain records as is for now.

> 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?

Who creates this record for new clients ?
How to you handle 3 locations on a single DNS server ?

Say I have a headquarters DNS setup where I want to send clients to the
engineering, sales or accounting locations depending on the client but I
have a shared local network configuration so all clients use the same
DNS server.

> In case described above I don't think so. Roaming between locations don't 
> require changing any record, so configuration is static.

Yep 'static' is the issue here, we want it more dynamic, the point of
generating is that we can change the way we manage locations in future
w/o having to jump through more hops.

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

We can't give out the privilege to create arbitrary DNAME records to
lower level admins, so we would have to add special code.

> > 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.

This is true, and we can opt for this fallback initially, but I do not
want to restrict manageability just to make the job easier for one of
the cases.

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

Yes this is indeed going to add complexity. No doubt.

Simo.

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