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

[Pavel Březina]

On 04/05/2013 02:22 PM, Petr Spacek wrote:
> 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' ...

Before I seen the design page, I wanted to implement it in SSSD this way:

If '_location.host.domain' gives any result than take it as primary 
servers and SRV from 'domain' as backup servers. Otherwise use 'domain' 
result as primary servers.

But I'm not so sure now.