[Freeipa-users] Realm distrubuted across data centers

[Simo Sorce]

On Wed, 2013-03-13 at 21:10 -0430, Loris Santamaria wrote:
> El mié, 13-03-2013 a las 15:57 -0400, Simo Sorce escribió:
> > On Wed, 2013-03-13 at 14:36 -0430, Loris Santamaria wrote:
> > > El mié, 13-03-2013 a las 14:44 +0100, Petr Spacek escribió:
> > > > On 13.3.2013 14:28, Rob Crittenden wrote:
> > > > > Michael ORourke wrote:
> > > > >> I think SRV records are only part of the problem.  We are using
> > > > >> integrated BIND/DNS with our IPA servers and I'm not sure it supports
> > > > >> views.  But thanks for the suggestion.
> > > > >> I guess we could create custom krb5.conf files in each DC and mange them
> > > > >> with Puppet, but there are other config files (e.g. resolv.conf and
> > > > >> ldap.conf) that would need to be managed too.  Maybe there are some
> > > > >> other IPA client config files that setup static mappings during the join
> > > > >> process.  Anyone know which ones to look at?
> > > > >
> > > > > No, we don't support views yet.
> > > > Views are not supported in IPA admin tools, but generally views can be 
> > > > configured with some hacking around. The price for that is losing IPA admin 
> > > > tools for DNS and generally, it is ugly and hard to maintain. I wouldn't 
> > > > recommend that.
> > > > 
> > > > Our latest & greatest proposal for location auto-discovery in summarized at 
> > > > http://www.freeipa.org/page/V3/DNS_Location_Mechanism . Any comments are welcome!
> > > 
> > > Hi!
> > > 
> > > The proposal seems to me too complicated, I really liked the old
> > > proposal where you could query the DNS which was the most appropriate
> > > "site" for your IP address. Choosing the right site by IP address is not
> > > perfect, there will be always some corner cases, but it is good enough
> > > and way better than what we have now.
> > 
> > Can you explain what is complicated about the current proposal ?
> > 
> > The reason I thought hard about this one is that the previous proposal
> > would require * a lot* of work on both client and server and was, as you
> > note, not great.
> > 
> > The current proposal is a lot easier to implement both on the server and
> > the client and reduces considerably the amount of code for both,
> > especially for the client, where in many case no changes are required at
> > all, just a client reconfiguration.
> 
> Maybe I don't get the proposal completely but these dynamically
> generated DNAME record which won't work when you need them the most
> (when you are a roaming user querying a non-ipa DNS server...) don't
> seem very helpful.

DNAME is a standard DNS feature, you can set it up with a standard DNS
server as well. It will simply not be dynamically generated, but static
is fine too.

>  The "complicated" part seems to me all the magic (or
> rather, policy) that would go into bind-dyndb-ldap, which can not be
> easily modified by the admin, and as you note in the proposal DNSSEC
> interaction is problematic.
> 
> In general DNSSEC doesn't play well with views and with dynamically
> generated records.

Yeah taht will be a problem no matter what the method used IMO.

> What if the company doesn't want to manage their DNS with IPA? What if
> the user is outside the company's network? What if the user is
> connecting to the company's network via vpn but is using the DNS servers
> of his ISP?

Then you can use standard SRV records. We are not taking anything out of
the table, just changed the old proposal to the new one. But the new, as
the old is an optional optimization from my POV.

> Your first proposal, even if it required the admin to add some info in
> the server (site list, servers per site, ip networks per site) would
> work even outside the company's firewall, could be managed with any dns
> server and would play well with DNSSEC.

I think the current proposal still have the same properties, the admin
just have to manually set DNAMEs.

Simo.

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