Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Fri, 12 Dec 2014 10:20:28 +0100 Jan Cholasta wrote: > Hi, > > Dne 1.12.2014 v 17:12 Simo Sorce napsal(a): > > On Mon, 01 Dec 2014 16:17:54 +0100 > > Petr Spacek wrote: > > > >> On 14.11.2014 17:31, Petr Spacek wrote: > >>> On 14.11.2014 02:22, Simo Sorce wrote: > 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. > > >> Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy > >> instead of nsupdate command (to hide TSIG key behind FreeIPA)? > > > I do not like the XML-RPC->DNS approach as it requires a special > > client, leaving out the majority of clients. > > I'm confused. Above you have suggested hiding the nsupdate machinery > behind the framework and now you are saying that you do not like the > XML-RPC->DNS approach. But the framework talks XML-RPC (and JSON-RPC) > and using *anything else* would require a special client. Or did you > mean some other XML-RPC->DNS? I do not like XML-RPC -> DNS for when clients need to update the DNS. For the FreeIPA server itself or the manager working through the framework it is just fine of course, but then it is an internal detail. > > Also, I am thinking that we only _need_ to set infrastructure > > relevant names (like IPA servers SRV records), but if someone > > decides not to use IPA for the DNS we may decide that it is not our > > responsibility to provide a full end-to-end client dns update > > solution. > > > > So I would concentrate on making it possible for IPA *Servers* to > > use a private TSIG key to update infrastructure relevant names, and > > possibly defer the clients side of the problem. > > > > We could use an internal bus on the server to allow the ipa > > framework to use nsupdate w/o gaining direct access to the TSIG > > key, this way admins can use ipa dnsrecod-add and friends w/o > > exposing the key. > > +1, we had a short discussion about external DNS with Petr yesterday > and reached the same conclusion. Nice :) Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
Hi, Dne 1.12.2014 v 17:12 Simo Sorce napsal(a): On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek wrote: On 14.11.2014 17:31, Petr Spacek wrote: On 14.11.2014 02:22, Simo Sorce wrote: 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. Would it be feasible to use FreeIPA server as XML-RPC->DNS proxy instead of nsupdate command (to hide TSIG key behind FreeIPA)? I do not like the XML-RPC->DNS approach as it requires a special client, leaving out the majority of clients. I'm confused. Above you have suggested hiding the nsupdate machinery behind the framework and now you are saying that you do not like the XML-RPC->DNS approach. But the framework talks XML-RPC (and JSON-RPC) and using *anything else* would require a special client. Or did you mean some other XML-RPC->DNS? Also, I am thinking that we only _need_ to set infrastructure relevant names (like IPA servers SRV records), but if someone decides not to use IPA for the DNS we may decide that it is not our responsibility to provide a full end-to-end client dns update solution. So I would concentrate on making it possible for IPA *Servers* to use a private TSIG key to update infrastructure relevant names, and possibly defer the clients side of the problem. We could use an internal bus on the server to allow the ipa framework to use nsupdate w/o gaining direct access to the TSIG key, this way admins can use ipa dnsrecod-add and friends w/o exposing the key. +1, we had a short discussion about external DNS with Petr yesterday and reached the same conclusion. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 12/11/2014 03:05 PM, Simo Sorce wrote: > On Thu, 11 Dec 2014 10:43:02 +0100 > Petr Spacek wrote: > >> On 10.12.2014 18:50, Simo Sorce wrote: >>> On Wed, 10 Dec 2014 15:13:30 +0100 >>> Petr Spacek wrote: >>> I think that external DNS could depend on Vault (assuming that external DNS support will be purely optional). >>> >>> TBH, I do not think this is a sensible option, the Vault will drag >>> huge dependencies for now, and I would like to avoid that if all we >>> need is to add a couple of A/SRV records to an external DNS. >>> >>> If we can't come up with a service, I think I am ok telling admins >>> they need to manually copy the TKEY (or use puppet or other similar >>> configuration manager to push the key file around) on each replica, >>> and we defer automatic distribution of TKEYs. >>> >>> We will have a service that can give out keys, it is identified as >>> necessary in the replica promotion proposal, so we'll eventually get >>> there. >> >> Thank you for discussion. Now I would like to know in which direction >> are we heading with external DNS support :-) >> >> I have to admit that I don't understand why we are spending time on >> Vault and at the same time we refuse to use it ... >> >> Anyway, someone competent has to decide if we want to implement >> external DNS support and: >> - defer key distribution for now > > I vote for deferring for now. > > Simo. +1, we can defer until we have the Simo's KISS service from replica promotion work: http://www.freeipa.org/page/V4/Replica_Promotion#Key_Interchange_Security_Service_.28KISS.29 Same as Simo, I would also rather avoid the dependency on PKI&Vault for this base infrastructure feature orthogonal to FreeIPA PKI. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Thu, 11 Dec 2014 10:43:02 +0100 Petr Spacek wrote: > On 10.12.2014 18:50, Simo Sorce wrote: > > On Wed, 10 Dec 2014 15:13:30 +0100 > > Petr Spacek wrote: > > > >> I think that external DNS could depend on Vault (assuming that > >> external DNS support will be purely optional). > > > > TBH, I do not think this is a sensible option, the Vault will drag > > huge dependencies for now, and I would like to avoid that if all we > > need is to add a couple of A/SRV records to an external DNS. > > > > If we can't come up with a service, I think I am ok telling admins > > they need to manually copy the TKEY (or use puppet or other similar > > configuration manager to push the key file around) on each replica, > > and we defer automatic distribution of TKEYs. > > > > We will have a service that can give out keys, it is identified as > > necessary in the replica promotion proposal, so we'll eventually get > > there. > > Thank you for discussion. Now I would like to know in which direction > are we heading with external DNS support :-) > > I have to admit that I don't understand why we are spending time on > Vault and at the same time we refuse to use it ... > > Anyway, someone competent has to decide if we want to implement > external DNS support and: > - defer key distribution for now I vote for deferring for now. Simo. > - use Vault > - re-invent Vault and use that new cool thing > -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 10.12.2014 18:50, Simo Sorce wrote: > On Wed, 10 Dec 2014 15:13:30 +0100 > Petr Spacek wrote: > >> I think that external DNS could depend on Vault (assuming that >> external DNS support will be purely optional). > > TBH, I do not think this is a sensible option, the Vault will drag huge > dependencies for now, and I would like to avoid that if all we need is > to add a couple of A/SRV records to an external DNS. > > If we can't come up with a service, I think I am ok telling admins they > need to manually copy the TKEY (or use puppet or other similar > configuration manager to push the key file around) on each replica, and > we defer automatic distribution of TKEYs. > > We will have a service that can give out keys, it is identified as > necessary in the replica promotion proposal, so we'll eventually get > there. Thank you for discussion. Now I would like to know in which direction are we heading with external DNS support :-) I have to admit that I don't understand why we are spending time on Vault and at the same time we refuse to use it ... Anyway, someone competent has to decide if we want to implement external DNS support and: - defer key distribution for now - use Vault - re-invent Vault and use that new cool thing -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 12/10/2014 9:59 PM, Petr Spacek wrote: Alternatively we can use Vault for TSIG key storage and use Vault's capability to share keys among many users. In that case we don't have problem with key distribution nor authorization. I am not convinced we should grow Vault dependency for this functionality, it requires the whole PKI machinery to be available. Many deployments do not use it though. Another possibility is to say that replica-deletion can be done only by root user or that updates to external DNS are supported only when running ipa-replica-manage as root. Why does root help? So that TSIG keys will be available on all IPA servers, regardless whether they have DNS service running or not? The point is that we need to store TSIG keys "somewhere" to make them available to ipa* scripts on all replica but at the same not to human-users. BTW there don't need to be any 'DNS service' if only external DNS integration is in use. It would be better to have the TSIG keys available using standard FreeIPA RBAC roles, i.e. DS ACIs so that privileged users can also use the TSIG. Or am I missing anything? Ideologically - no, it sounds fine. Technically - the problem is in implementation. We need a mechanism for secure key distribution *among users*, i.e. Vault-like functionality. I would rather not re-implement Vault just for external DNS. I think that external DNS could depend on Vault (assuming that external DNS support will be purely optional). DNSSEC key distribution is very different because it distributes keys to *servers* and there is no ACI mechanism on top of that - all DNS servers need to know all the keys anyway. So IIUC, the goal would be to put TSIG keys in the Vault and then make them available for all IPA servers? I am now not sure if the Vault as proposed can easily select a group of principals to allow reading the Vault or if it is only confined for the owner/user principal. We would need to ask Endi (CCed). I assumed that very first sentence of http://www.freeipa.org/page/V4/Password_Vault_Implementation#Vault "Vault is a secure place to store data or a collection of secrets. A vault may be privately owned by a user, or shared among users, groups, or services." is correct :-) Endi, we would like to have one secret which is shared among services & users at the same time. Is it possible to do that with Vault? Yes, the access to a particular vault is limited to the vault members & owners which can be a set of users, groups, and/or services. See http://www.freeipa.org/page/V4/Password_Vault_Implementation#Access_Control A vault member can list, archive, and retrieve the secrets in a standard vault. With symmetric vault the member will need a vault password in order to archive and retrieve secrets. With asymmetric vault the member can only archive the secrets but not retrieve them since it only has the public key and not the private key. A vault owner can list, archive, and retrieve the secrets like vault members, but it has the private key so it can retrieve secrets from asymmetric vault. The owner can also manage the list of members and owners of the vault, and change the vault password/keys. There are commands to manage the members/owners. See http://www.freeipa.org/page/V4/Password_Vault_Implementation#Adding_vault_member $ ipa vault-add-member MyVault --groups group1,group2 $ ipa vault-add-owner MyVault --users user1,user2 (we may need a separate option for services) Below are the vault LDAP ACIs. See http://www.freeipa.org/page/V4/Password_Vault_Implementation#Access_Control_Attributes aci: (targetfilter="(objectClass=ipaVault)") (targetattr="*") (version 3.0; acl "Vault members can access the vault"; allow(read, search, compare) userattr="member#USERDN";) aci: (targetfilter="(objectClass=ipaVault)") (targetattr="*") (version 3.0; acl "Indirect vault members can access the vault"; allow(read, search, compare) userattr="member#GROUPDN";) aci: (targetfilter="(objectClass=ipaVault)") (targetattr="*") (version 3.0; acl "Vault owners can modify the vault"; allow(read, search, compare, write) userattr="owner#USERDN";) aci: (targetfilter="(objectClass=ipaVault)") (targetattr="*") (version 3.0; acl "Indirect vault owners can modify the vault"; allow(read, search, compare, write) userattr="owner#GROUPDN";) Note that the secrets are stored separately in KRA, not in the IPA LDAP tree, so they are not directly controlled by the above ACIs. The vault service will first verify that you have access to the vault based on the above ACIs then it will let you archive/retrieve secrets in KRA. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Wed, 10 Dec 2014 15:13:30 +0100 Petr Spacek wrote: > I think that external DNS could depend on Vault (assuming that > external DNS support will be purely optional). TBH, I do not think this is a sensible option, the Vault will drag huge dependencies for now, and I would like to avoid that if all we need is to add a couple of A/SRV records to an external DNS. If we can't come up with a service, I think I am ok telling admins they need to manually copy the TKEY (or use puppet or other similar configuration manager to push the key file around) on each replica, and we defer automatic distribution of TKEYs. We will have a service that can give out keys, it is identified as necessary in the replica promotion proposal, so we'll eventually get there. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 10.12.2014 15:50, Martin Kosek wrote: > On 12/10/2014 03:13 PM, Petr Spacek wrote: >> On 9.12.2014 13:40, Martin Kosek wrote: >>> On 12/03/2014 05:04 PM, Petr Spacek wrote: On 2.12.2014 17:21, Simo Sorce wrote: > On Tue, 02 Dec 2014 15:56:28 +0100 > Petr Spacek wrote: > >> On 1.12.2014 17:12, Simo Sorce wrote: >>> On Mon, 01 Dec 2014 16:17:54 +0100 >>> Petr Spacek wrote: >>> On 14.11.2014 17:31, Petr Spacek wrote: > On 14.11.2014 02:22, Simo Sorce wrote: >> On Tue, 11 Nov 2014 16:29:51 +0100 >> Petr Spacek 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.. > > Using TSIG on many clients is very problematic. Keep in mind that > TSIG is basically HMAC computed using symmetric key so: > a) Every client would have to use the same key - this is a > security nightmare. b) We would have to distribute and maintain > many keys for many^2 clients, which is an administrative > nightmare. > > For *clients* I would rather stay with GSS-TSIG which is much more > manageable because we can use Kerberos trust and Keytab > distribution is already solved by ipa-client-install. > > Alternative for clients would be to use FreeIPA server as proxy > which encapsulates TSIG keys and issues update requests on behalf > of clients. This would be FreeIPA-specific but any > TSIG-distribution mechanism will be FreeIPA-specific anyway. > > TSIG standard explicitly says that there is no standardized > distribution mechanism. > >>> 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. > > This needs to be decided by FreeIPA framework experts ... > > Petr^3 came up with clever 'proxy' idea for IPA-commands. This > proxy would provide all ipa dns* commands and dispatch user-issued > commands to appropriate FreeIPA-plugin (internal-dns or > external-dns). This decision could depend on some values in LDAP. > >>> b) Replace dns.py with another implementation of current >>> dnszone-* & dnsrecord-* AP
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 12/10/2014 03:13 PM, Petr Spacek wrote: > On 9.12.2014 13:40, Martin Kosek wrote: >> On 12/03/2014 05:04 PM, Petr Spacek wrote: >>> On 2.12.2014 17:21, Simo Sorce wrote: On Tue, 02 Dec 2014 15:56:28 +0100 Petr Spacek wrote: > On 1.12.2014 17:12, Simo Sorce wrote: >> On Mon, 01 Dec 2014 16:17:54 +0100 >> Petr Spacek wrote: >> >>> On 14.11.2014 17:31, Petr Spacek wrote: On 14.11.2014 02:22, Simo Sorce wrote: > On Tue, 11 Nov 2014 16:29:51 +0100 > Petr Spacek 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.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. >> 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. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. >> b) Replace dns.py with another implementation of current >> dnszone-* & dnsrecord-* API. >> - >> This seems like a cleaner approach to me. It could be s
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 9.12.2014 13:40, Martin Kosek wrote: > On 12/03/2014 05:04 PM, Petr Spacek wrote: >> On 2.12.2014 17:21, Simo Sorce wrote: >>> On Tue, 02 Dec 2014 15:56:28 +0100 >>> Petr Spacek wrote: >>> On 1.12.2014 17:12, Simo Sorce wrote: > On Mon, 01 Dec 2014 16:17:54 +0100 > Petr Spacek wrote: > >> On 14.11.2014 17:31, Petr Spacek wrote: >>> On 14.11.2014 02:22, Simo Sorce wrote: On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek 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.. >>> >>> Using TSIG on many clients is very problematic. Keep in mind that >>> TSIG is basically HMAC computed using symmetric key so: >>> a) Every client would have to use the same key - this is a >>> security nightmare. b) We would have to distribute and maintain >>> many keys for many^2 clients, which is an administrative >>> nightmare. >>> >>> For *clients* I would rather stay with GSS-TSIG which is much more >>> manageable because we can use Kerberos trust and Keytab >>> distribution is already solved by ipa-client-install. >>> >>> Alternative for clients would be to use FreeIPA server as proxy >>> which encapsulates TSIG keys and issues update requests on behalf >>> of clients. This would be FreeIPA-specific but any >>> TSIG-distribution mechanism will be FreeIPA-specific anyway. >>> >>> TSIG standard explicitly says that there is no standardized >>> distribution mechanism. >>> > 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. >>> >>> This needs to be decided by FreeIPA framework experts ... >>> >>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This >>> proxy would provide all ipa dns* commands and dispatch user-issued >>> commands to appropriate FreeIPA-plugin (internal-dns or >>> external-dns). This decision could depend on some values in LDAP. >>> > 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: > -
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 12/03/2014 05:04 PM, Petr Spacek wrote: > On 2.12.2014 17:21, Simo Sorce wrote: >> On Tue, 02 Dec 2014 15:56:28 +0100 >> Petr Spacek wrote: >> >>> On 1.12.2014 17:12, Simo Sorce wrote: On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek wrote: > On 14.11.2014 17:31, Petr Spacek wrote: >> On 14.11.2014 02:22, Simo Sorce wrote: >>> On Tue, 11 Nov 2014 16:29:51 +0100 >>> Petr Spacek 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.. >> >> Using TSIG on many clients is very problematic. Keep in mind that >> TSIG is basically HMAC computed using symmetric key so: >> a) Every client would have to use the same key - this is a >> security nightmare. b) We would have to distribute and maintain >> many keys for many^2 clients, which is an administrative >> nightmare. >> >> For *clients* I would rather stay with GSS-TSIG which is much more >> manageable because we can use Kerberos trust and Keytab >> distribution is already solved by ipa-client-install. >> >> Alternative for clients would be to use FreeIPA server as proxy >> which encapsulates TSIG keys and issues update requests on behalf >> of clients. This would be FreeIPA-specific but any >> TSIG-distribution mechanism will be FreeIPA-specific anyway. >> >> TSIG standard explicitly says that there is no standardized >> distribution mechanism. >> 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. >> >> This needs to be decided by FreeIPA framework experts ... >> >> Petr^3 came up with clever 'proxy' idea for IPA-commands. This >> proxy would provide all ipa dns* commands and dispatch user-issued >> commands to appropriate FreeIPA-plugin (internal-dns or >> external-dns). This decision could depend on some values in LDAP. >> 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 serve
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 2.12.2014 17:21, Simo Sorce wrote: > On Tue, 02 Dec 2014 15:56:28 +0100 > Petr Spacek wrote: > >> On 1.12.2014 17:12, Simo Sorce wrote: >>> On Mon, 01 Dec 2014 16:17:54 +0100 >>> Petr Spacek wrote: >>> On 14.11.2014 17:31, Petr Spacek wrote: > On 14.11.2014 02:22, Simo Sorce wrote: >> On Tue, 11 Nov 2014 16:29:51 +0100 >> Petr Spacek 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.. > > Using TSIG on many clients is very problematic. Keep in mind that > TSIG is basically HMAC computed using symmetric key so: > a) Every client would have to use the same key - this is a > security nightmare. b) We would have to distribute and maintain > many keys for many^2 clients, which is an administrative > nightmare. > > For *clients* I would rather stay with GSS-TSIG which is much more > manageable because we can use Kerberos trust and Keytab > distribution is already solved by ipa-client-install. > > Alternative for clients would be to use FreeIPA server as proxy > which encapsulates TSIG keys and issues update requests on behalf > of clients. This would be FreeIPA-specific but any > TSIG-distribution mechanism will be FreeIPA-specific anyway. > > TSIG standard explicitly says that there is no standardized > distribution mechanism. > >>> 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. > > This needs to be decided by FreeIPA framework experts ... > > Petr^3 came up with clever 'proxy' idea for IPA-commands. This > proxy would provide all ipa dns* commands and dispatch user-issued > commands to appropriate FreeIPA-plugin (internal-dns or > external-dns). This decision could depend on some values in LDAP. > >>> 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. >>>
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Tue, 02 Dec 2014 15:56:28 +0100 Petr Spacek wrote: > On 1.12.2014 17:12, Simo Sorce wrote: > > On Mon, 01 Dec 2014 16:17:54 +0100 > > Petr Spacek wrote: > > > >> On 14.11.2014 17:31, Petr Spacek wrote: > >>> On 14.11.2014 02:22, Simo Sorce wrote: > On Tue, 11 Nov 2014 16:29:51 +0100 > Petr Spacek 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.. > >>> > >>> Using TSIG on many clients is very problematic. Keep in mind that > >>> TSIG is basically HMAC computed using symmetric key so: > >>> a) Every client would have to use the same key - this is a > >>> security nightmare. b) We would have to distribute and maintain > >>> many keys for many^2 clients, which is an administrative > >>> nightmare. > >>> > >>> For *clients* I would rather stay with GSS-TSIG which is much more > >>> manageable because we can use Kerberos trust and Keytab > >>> distribution is already solved by ipa-client-install. > >>> > >>> Alternative for clients would be to use FreeIPA server as proxy > >>> which encapsulates TSIG keys and issues update requests on behalf > >>> of clients. This would be FreeIPA-specific but any > >>> TSIG-distribution mechanism will be FreeIPA-specific anyway. > >>> > >>> TSIG standard explicitly says that there is no standardized > >>> distribution mechanism. > >>> > > 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. > >>> > >>> This needs to be decided by FreeIPA framework experts ... > >>> > >>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This > >>> proxy would provide all ipa dns* commands and dispatch user-issued > >>> commands to appropriate FreeIPA-plugin (internal-dns or > >>> external-dns). This decision could depend on some values in LDAP. > >>> > > 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 u
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 1.12.2014 17:12, Simo Sorce wrote: > On Mon, 01 Dec 2014 16:17:54 +0100 > Petr Spacek wrote: > >> On 14.11.2014 17:31, Petr Spacek wrote: >>> On 14.11.2014 02:22, Simo Sorce wrote: On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek 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.. >>> >>> Using TSIG on many clients is very problematic. Keep in mind that >>> TSIG is basically HMAC computed using symmetric key so: >>> a) Every client would have to use the same key - this is a security >>> nightmare. b) We would have to distribute and maintain many keys >>> for many^2 clients, which is an administrative nightmare. >>> >>> For *clients* I would rather stay with GSS-TSIG which is much more >>> manageable because we can use Kerberos trust and Keytab >>> distribution is already solved by ipa-client-install. >>> >>> Alternative for clients would be to use FreeIPA server as proxy >>> which encapsulates TSIG keys and issues update requests on behalf >>> of clients. This would be FreeIPA-specific but any >>> TSIG-distribution mechanism will be FreeIPA-specific anyway. >>> >>> TSIG standard explicitly says that there is no standardized >>> distribution mechanism. >>> > 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. >>> >>> This needs to be decided by FreeIPA framework experts ... >>> >>> Petr^3 came up with clever 'proxy' idea for IPA-commands. This >>> proxy would provide all ipa dns* commands and dispatch user-issued >>> commands to appropriate FreeIPA-plugin (internal-dns or >>> external-dns). This decision could depend on some values in LDAP. >>> > 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. >>> >>> Good point, I agree. I will
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Mon, 01 Dec 2014, Simo Sorce wrote: On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek wrote: On 14.11.2014 17:31, Petr Spacek wrote: > On 14.11.2014 02:22, Simo Sorce wrote: >> On Tue, 11 Nov 2014 16:29:51 +0100 >> Petr Spacek 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.. > > Using TSIG on many clients is very problematic. Keep in mind that > TSIG is basically HMAC computed using symmetric key so: > a) Every client would have to use the same key - this is a security > nightmare. b) We would have to distribute and maintain many keys > for many^2 clients, which is an administrative nightmare. > > For *clients* I would rather stay with GSS-TSIG which is much more > manageable because we can use Kerberos trust and Keytab > distribution is already solved by ipa-client-install. > > Alternative for clients would be to use FreeIPA server as proxy > which encapsulates TSIG keys and issues update requests on behalf > of clients. This would be FreeIPA-specific but any > TSIG-distribution mechanism will be FreeIPA-specific anyway. > > TSIG standard explicitly says that there is no standardized > distribution mechanism. > >>> 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. > > This needs to be decided by FreeIPA framework experts ... > > Petr^3 came up with clever 'proxy' idea for IPA-commands. This > proxy would provide all ipa dns* commands and dispatch user-issued > commands to appropriate FreeIPA-plugin (internal-dns or > external-dns). This decision could depend on some values in LDAP. > >>> 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. > > Good point, I agree. I will focus on supporting both (internal and > external) DNS at the same time. > >>> 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 z
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Mon, 01 Dec 2014 16:17:54 +0100 Petr Spacek wrote: > On 14.11.2014 17:31, Petr Spacek wrote: > > On 14.11.2014 02:22, Simo Sorce wrote: > >> On Tue, 11 Nov 2014 16:29:51 +0100 > >> Petr Spacek 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.. > > > > Using TSIG on many clients is very problematic. Keep in mind that > > TSIG is basically HMAC computed using symmetric key so: > > a) Every client would have to use the same key - this is a security > > nightmare. b) We would have to distribute and maintain many keys > > for many^2 clients, which is an administrative nightmare. > > > > For *clients* I would rather stay with GSS-TSIG which is much more > > manageable because we can use Kerberos trust and Keytab > > distribution is already solved by ipa-client-install. > > > > Alternative for clients would be to use FreeIPA server as proxy > > which encapsulates TSIG keys and issues update requests on behalf > > of clients. This would be FreeIPA-specific but any > > TSIG-distribution mechanism will be FreeIPA-specific anyway. > > > > TSIG standard explicitly says that there is no standardized > > distribution mechanism. > > > >>> 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. > > > > This needs to be decided by FreeIPA framework experts ... > > > > Petr^3 came up with clever 'proxy' idea for IPA-commands. This > > proxy would provide all ipa dns* commands and dispatch user-issued > > commands to appropriate FreeIPA-plugin (internal-dns or > > external-dns). This decision could depend on some values in LDAP. > > > >>> 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. > > > > Good point, I agree. I will focus on supporting both (internal a
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 14.11.2014 17:31, Petr Spacek wrote: > On 14.11.2014 02:22, Simo Sorce wrote: >> On Tue, 11 Nov 2014 16:29:51 +0100 >> Petr Spacek 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.. > > Using TSIG on many clients is very problematic. Keep in mind that TSIG is > basically HMAC computed using symmetric key so: > a) Every client would have to use the same key - this is a security nightmare. > b) We would have to distribute and maintain many keys for many^2 clients, > which is an administrative nightmare. > > For *clients* I would rather stay with GSS-TSIG which is much more manageable > because we can use Kerberos trust and Keytab distribution is already solved > by ipa-client-install. > > Alternative for clients would be to use FreeIPA server as proxy which > encapsulates TSIG keys and issues update requests on behalf of clients. This > would be FreeIPA-specific but any TSIG-distribution mechanism will be > FreeIPA-specific anyway. > > TSIG standard explicitly says that there is no standardized distribution > mechanism. > >>> 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. > > This needs to be decided by FreeIPA framework experts ... > > Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would > provide all ipa dns* commands and dispatch user-issued commands to appropriate > FreeIPA-plugin (internal-dns or external-dns). This decision could depend on > some values in LDAP. > >>> 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. > > Good point, I agree. I will focus on supporting both (internal and external) > DNS at the same time. > >>> 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 ip
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On 14.11.2014 02:22, Simo Sorce wrote: > On Tue, 11 Nov 2014 16:29:51 +0100 > Petr Spacek 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.. Using TSIG on many clients is very problematic. Keep in mind that TSIG is basically HMAC computed using symmetric key so: a) Every client would have to use the same key - this is a security nightmare. b) We would have to distribute and maintain many keys for many^2 clients, which is an administrative nightmare. For *clients* I would rather stay with GSS-TSIG which is much more manageable because we can use Kerberos trust and Keytab distribution is already solved by ipa-client-install. Alternative for clients would be to use FreeIPA server as proxy which encapsulates TSIG keys and issues update requests on behalf of clients. This would be FreeIPA-specific but any TSIG-distribution mechanism will be FreeIPA-specific anyway. TSIG standard explicitly says that there is no standardized distribution mechanism. >> 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. This needs to be decided by FreeIPA framework experts ... Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would provide all ipa dns* commands and dispatch user-issued commands to appropriate FreeIPA-plugin (internal-dns or external-dns). This decision could depend on some values in LDAP. >> 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. Good point, I agree. I will focus on supporting both (internal and external) DNS at the same time. >> 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 tha
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek 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@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 provi
[Freeipa-devel] FreeIPA integration with external DNS services
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. 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 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 ... Advantages: - You can use external & integrated DNS at the same time. 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). Petr^3 or anyone else, what do you propose? 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. 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@AD principal but you can't (I guess) establish trust until proper DNS records are in place ... For 'experimental' phase I would go with pre-populated CCcache, i.e. admin will manually do kinit Administrator@AD and then run FreeIPA installer. 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. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
