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

[Petr Spacek]

On 23.1.2013 02:13, Simo Sorce wrote:
> On Tue, 2013-01-22 at 18:30 +0100, Petr Spacek wrote:
>> 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.
>
> Ok I can see that now.
>
>>>> 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.
>
> Yes we are shifting complexity from one place to another.
>
>>> 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.
>
> I am not sure I like the idea of using LDAP referrals for this, I need
> to think ab out that, I can see how it can be used to reduce some
> duplication.
>
>>> 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.
>
> See this is the problem. Because your DNAME is fixed, in order to do
> overrides, you have to have a 'server's view of a location.
> Ie instead of directing the client to the right place, you 'fake'
> information about the place the client thinks it is fetching info for.
>
> This maintains still a great deal of 'duplication' except the data is
> not identical, each server have different data labeled with a name
> recurring on other servers in order to cheat clients. This can easily
> get out of control.
>
> Even if the data is not 'duplicated' in the db and it is just all smoke
> and mirrors and internal redirects it still a complex maze of redirects
> you have to store. It also prevents to have final absolute rules for
> some clients.
>
>>> 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.
>
> Ah but it does, in order to force clients to stick to a location in some
> case you are faking data for all location so all locations point to the
> same data.
>
> In my model _location.client.domain returns you arbitrary (dynamic) data
> but foo._location.domain is always consistent across all servers.
>
> In your model _location.client.domain returns 'stable' data but
> foo._location.domain may instead return fake data.
>
> For some reason I prefer the former rather than the latter, although I
> recognize it may just be a matter of taste, but is sounds right to me
> that the _locations.domain tree is the stable one rather than the
> _location.client.domain one.
>
>
>>>> 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).
>
> Yeah but see above about that.
>
>>>> 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.
>
> This means it doesn't work for clients that join now. They use DNS
> update to create records and have no rights to create DNAME. So admins
> regularly need to go and add DNAME records or we need to add some code
> in DS to automatically create them. So again we've just move around
> where the complexity is. It is untrue that we have no new code, the new
> code is just elsewhere.
>
>>> 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.".
>
> Ok another point here.
> If I need to rename a location in my model I just do it.
> If I rename NYC to newyork, all I need to do is change
> NYC._locations.domain to newyork._locations.domain and in IPA I just
> change the name of the group or association or whatever object we use to
> group clients (Cos Attribute for example propagates automatically).
>
> In your scheme we would have to also change all the records for each
> client in that location, making a rename quite burdensome.
>
>>>> 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).
>
> I was just saying that if data is staic you need to change actual data
> if you want to change behavior, if it is synthetic you just need to
> change the code that synthesize it. Changing actual stored data is
> costly because involves generating replication traffic.
>
>>>> 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.
>
> you are assuming that allowing someone to create redirects to arbitrary
> locations is harmless. But is it ?
>
> What if a junior admin, maliciously or not uses this privilege to
> redirect clients trafic to a location it shouldn't go to by DNS updating
> the DNAME to point to the wrong location ?
> I am not comfortable with that and my solution does not suffer from this
> problem.
> In order to use stored DNAMEs we would need code on the server to
> automatically create them and store them in LDAP,a nd do that according
> to the location defined for the client. Or in other world the same
> logical process you would need to know how to synthesize the record,
> only in a different part of the code. (this is just the logic, of
> course, a phantom record involves more than that, so not saying it is
> the same)
>
>>>>> 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...
>
> ignore
>
>> _location.blah._location.blah._location...
>
> ignore
>
>> _location._ntp._udp.example.com.
>
> ignore
>
>> _location._ntp._udp._location._ntp._udp.example.com.
>
> ignore
>
>> and other variants.
>
> Only 1 _location is acceptable, and only 'on top' of an existing A
> record, and only if an actual record with the same name doesn't actually
> exist.
>
>> 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.
>
> I think I would create the _location record. We just need to decide what
> is the most appropriate behavior for this case though.
>
> What happen if you have a record foo.example.com and also
> *.example.com ?
>
>> 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.)
>
> We return an error.
> As said above the 'base' must be an A (or AAAA) record.
>
>> How would it be possible to direct legacy clients (looking for SRV records
>> directly in 'domain') to local/optimized location?
>
> Not sure what is the problem here.
>
>> 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.)
>
> I wasn't going to change the legacy SRV records, but it might be an idea
> as well to redirect them to the 'local' default. I am not sure it is a
> good idea. However you wouldn't redirect to the client own location I
> don't think.
> I think you would redirect to the server default location at most.
> And the locations are actual existing records.
>
>> Again, I like the idea itself, but I see a lot of problems. (Still not digging
>> into DNSSEC.)
>
> Another compromise option I was thinking is to keep the complexity in
> LDAP by making up fake DNAME records in LDAP, like we do with the compat
> plugin, but then I think we would break persistent searches, so I do not
> like that one too much.

Pavel Brezina discovered that the design doesn't specify how client should 
behave if expected _location.client.example.com. record doesn't exist.

I propose to let this aspect on implementer's discretion (or configurable).

Personally, I would fall back to another pre-configured name, e.g. in case of 
SSSD to configured 'IPA domain' ...

-- 
Petr Spacek