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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
