On 10/01/2013 04:45 AM, Petr Spacek wrote:
On 23.9.2013 19:06, Dmitri Pal wrote:
On 09/23/2013 10:25 AM, Petr Spacek wrote:
On 20.9.2013 19:29, Dmitri Pal wrote:
5) Met with James (the blogger) and the community guy who created puppet
scripts for IPA. He was trying to convince me that we need to support
the use case when IPA is the DNS that provides two different sets of the IPA addresses for the IPA clients running inside the subnet and outside
the subnet. I see a clear use case and value. So that get back to the
views. Why do we thing views will be a problem in IPA?


In principle - it is technically possible. Just pretty hard.

- It requires re-designing of LDAP schema for DNS.
- It implies that we will have to adapt all parts of FreeIPA and
bind-dyndb-ldap which touches the LDAP.
- And also re-design CLI and WebUI, because views adds one level of
indirection: Your will need some tool to see what is in the particular
view, move records from one view to another, share records between
views, do exceptions etc.

We tried to design schema for views approximately year ago, but there
wasn't a clear agreement on that.

Hm. OK. That means that we are probably over complicating things. Do you
have a pointer to design?

It has been more 'discussion' without clear outcome then real design:
https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html
https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html

Let us table the actual design conversation for now but when we start
3.5 planning I want to take a closer look.

We should move the discussion to freeipa-devel at thins point ...


I have spent some time thinking about DNS views and I think that we should design support for DNS views as soon as possible.

Opening up the discussion.  This is FreeIPA general stuff:

I think that the idea of different internal and external views is not specific to DNS. Other things that might be different between internal and external:

Kerberos might only want to let a subset of users get tickets from outside the VPN, and only provide service tickets for services in the DMZ
You might want to run an Kerberos KDC proxy outside of the IPA instance
LDAP might be limited to read only when accessed from outside, and only a subset of users, or a subset of the data from other entities would be exposed
Dogtag might want to only publish CRL  and expose OCSP to the outside world
IPA ui might be limited to self service

Perhaps a better abstraction is an IPA proxy, a server that is an incomplete replica of an IPA server. As such it would get:

1.  A subset of the data from the canonical LDAP server
2. Some of that data would be modified, such as the A records marked for external use 3. It will not push updates to the centralized server. It will be configured to not accept updates from the outside world.




Resulting design will significantly influence bind-dyndb-ldap internals & also DNSSEC support. At the moment, the code relies on assumption that one LDAP object = one DNS name.

We have to find out if DNS views will break this assumption as soon as possible. IMHO views will change things significantly, including this 1:1 mapping - which will require major code re-design.

I would like to avoid re-designing for DNSSEC and then immediate re-design for DNS views.


_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to