[Freeipa-devel] FreeIPA integration with external DNS services

[Simo Sorce]

On Tue, 11 Nov 2014 16:29:51 +0100
Petr Spacek <pspacek at redhat.com> wrote:

> Hello,
> 
> this thread is about RFE
> "IPA servers when installed should register themselves in the
> external DNS" https://fedorahosted.org/freeipa/ticket/4424
> 
> It is not a complete design, just a raw idea.
> 
> 
> Use case
> ========
> FreeIPA installation to a network with existing DNS infrastructure +
> network administrator who is not willing to add/maintain new DNS
> servers "just for FreeIPA".
> 
> 
> High-level idea
> ===============
> - Transform dns* commands from FreeIPA framework to equivalent
> "nsupdate" commands and send DNS updates to existing DNS servers.
> - Provide necessary encryption/signing keys to nsupdate.
> 
> 
> 1) Integration to FreeIPA framework
> ===================================
> First of all, we need to decide if "external DNS integration" can be
> used at the same time with FreeIPA-integrated DNS or not.
> Side-question is what to do if a first server is installed with
> external-DNS but another replica is being installed with
> integrated-DNS and so on.

I think being able to integrate with an external DNS is important, and
not just at the server level, being able to distribute TSIG keys to
client would be nice too, though a lot less important, than getting
server integration..

> In other words, the question is if current "dns.py" plugin shipped
> with FreeIPA framework should be:
> 
> a) Extended dns.py with dnsexternal-* commands
> ----------------------------------------------
> Disadvantages:
> - It complicate FreeIPA DNS interface which is a complex beast even
> now.
> - We would have add condition to every DNS API call in installers
> which would increase horribleness of the installer code even more (or
> add another layer of abstraction...).

I agree having a special command is undesirable.

> - I don't see a point in using integrated-DNS with external-DNS at
> the same time. To use integrated-DNS you have to get a proper DNS
> delegation from parent domain - and if you can get the delegation
> then there is no point in using external DNS ...

I disagree on this point, it makes a lot of sense to have some zones
maintained by IPA and ... some not.

> Advantages:
> - You can use external & integrated DNS at the same time.

We can achieve the same w/o a new ipa level command.

> b) Replace dns.py with another implementation of current dnszone-* &
> dnsrecord-* API.
> ---------------------------------------------------------------------
> This seems like a cleaner approach to me. It could be shipped as
> ipa-server-dns-external package (opposed to "standard" ipa-server-dns
> package).
> 
> Advantages:
> - It could seamlessly work with FreeIPA client installer because the
> dns*->nsupdate command transformation would be done on FreeIPA server
> and client doesn't need to know about it.
> - Does not require re-training/not much new documentation because
> commands are the same.
> 
> Disadvantages:
> - You can't use integrated & external DNS at the same time (but I
> don't think it justifies the added complexity).

I disagree.

One of the reason to use a mix is to allow smooth migrations where
zones are moved into (or out of) IPA one by one.

> Petr^3 or anyone else, what do you propose?

I think what I'd like to see is to be able to configure a DNS zone in
LDAP and mark it external.
The zone would held the TSIG keys necessary to perform DNS updates.

When the regular ipa dnsrecord-add etc... commands are called, the
framework detects that the zone is "external", fewttches the TSIG key
(if the user has access to it) and spawn an nsupdate command that will
perform the update against whatever DNS server is authoritative for the
zone.

Some commands may be disabled if the zone is external and appropriate
errors would be returned.


> 2) Authentication to external DNS server/keys
> =============================================
> This is separate problem from FreeIPA framework integration.
> We will have to somehow store raw symmetric keys (for DNS TSIG) or
> keytabs (for DNS GSS-TSIG) and distribute them somehow to replicas so
> every replica can update DNS records as necessary.

For TSIG keys I think we should just store them in a LDAP record, see
above.
For keytabs we can simply store them just like any  other kerberos key
if we really need it (in a trust case for example, we may not need a
new keytab, we may be allowed to use our own credentials through the
trust. So we'll need to explore a bit how to properly express that in
configuration. REtrieval ok keytabs is then just a matter of running
ipa-getkeytab -r on the replica that needs it.

> This will be the funny part because in case of AD trusts we have
> chicken-egg problem. You need to establish trust to get ticket for
> DNS/dc1.ad.example at AD principal but you can't (I guess) establish
> trust until proper DNS records are in place ...

No, in this case we should create the records at trust establishment
time using the admin credentials we have been provided. NO chicken-egg
issue.

> For 'experimental' phase I would go with pre-populated CCcache, i.e.
> admin will manually do kinit Administrator at AD and then run FreeIPA
> installer.

We already to this, so there is no need to invent anything here IMO.

> Maybe we can re-use trust secret somehow? I don't know, I will reach
> out to AD experts with questions.
> 
> This area needs more research but for now it seems feasible to re-use
> DNSSEC key distribution system for TSIG keys and keytabs so "only"
> the chicken-egg problem is left.
> 
> This will need new LDAP schema but I will propose something when I'm
> done with investigation.

Please let me know if you agree with a new zone type as a way to
"forward" updates.

Simo.

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