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

[Simo Sorce]

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.

Simo.

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