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

[Petr Spacek]

On 22.1.2013 16:01, Simo Sorce wrote:

Replying to myself for the beginning:

 > On Tue, 2013-01-22 at 15:23 +0100, Petr Spacek wrote:
 >>> Server Implementation
 >>> TODO: interaction with DNSSEC
 >> That it *very* important part. I have fear from so many dynamic things inside.
There is less dynamic things than I thought :-) The only dynamic thing is 
_location.client.domain DNAME record. Proposal of "filters" was omitted in 
this version.

My biggest concern is related to dynamical parts, I like the idea itself.

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

>> 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
Sure, admin will never touch lines above. All data *are* directly in LDAP, so 
any tool can read & change _locations configuration on the fly.

>> 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.
I agree. This is a problem. It would require a tool to handle all location 
stuff. It definitely needs some clever way for management.

> 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.
I agree, it could be seen as a problem. With LDAP referrals and right tool it 
could be reasonable.

> Also your methods puts location information out of the actual DNS, so
> you can't lookup location data via DNS except for the 'default'.
That is not correct. Any client could ask any server for 
something._locations.domain and the reply will contain server's mapping for 
particular location.

> 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.
Sure, that doesn't change.

>> 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.
DNAME record stored in the database is only "preferred" location, it could be 
overridden on server side (by different content of _locations.domain sub-tree).

>> 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 ?
It was mentioned below - 'ipa host-add' + fall-back to 'domain' 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.
Each client machine has record like "_location DNAME eng._locations.domain.".

>> 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.
I'm not sure if I understood what "hop" mean. In reality all the CNAME/DNAME 
alias de-referencing is done in single shot if all data are available locally 
(which is our case).

>> 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.
IMHO allowing only defined locations (i.e. checking object existence) should 
be fairly simple.

>>> 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.
This problem is closely related to record generation. We need to know at which 
point record has to be generated etc. What we do when somebody asks for:
_location._location._location...
_location.blah._location.blah._location...
_location._ntp._udp.example.com.
_location._ntp._udp._location._ntp._udp.example.com.
and other variants.

How it will play with wildcards?
E.g. what we do when somebody asked for _location.client.sub.example.com. but 
wildcard *.client.sub.example.com. exists? What about wildcard 
*.sub.example.com.? Etc.

What if labels *preceding* '_location' do not exist? I.e. somebody asked for 
_location.nonexistent-blah.existing-domain.
(Note: Zone can legally contain names like 'blah.blah' without 'blah' alone.)


How would it be possible to direct legacy clients (looking for SRV records 
directly in 'domain') to local/optimized location?

Trivial solution came over my mind:
_ntp._udp.domain. CNAME _ntp._udp._location.dummy_client.domain.
... but it results in internal reference to generated record ... that is 
scary! (Note: CNAME/DNAMEs within zone are resolved internally in name server, 
there is no request-response ping-pong between client and server.)

Again, I like the idea itself, but I see a lot of problems. (Still not digging 
into DNSSEC.)

-- 
Petr^2 Spacek