On 22.10.2013 19:31, Simo Sorce wrote:
On Tue, 2013-10-22 at 18:14 +0200, Petr Spacek wrote:
On 22.10.2013 16:44, Martin Kosek wrote:
On 10/21/2013 10:57 PM, Simo Sorce wrote:
On Mon, 2013-10-21 at 18:48 +0200, Petr Spacek wrote:
On 1.10.2013 17:11, Petr Spacek wrote:
Doesn't this scheme means you always have to do 2 searches ? One to find
if the object is in the view and one to the base ?

We could use multivalued RDNs to achieve something similar but that will
require you only one search (assuming it matters).

Reading = 0 searches :-D Psearch/SyncRepl delivers the data from LDAP
asynchronously to the plugin, almost immediatelly after each change in LDAP.

This is true only with the current specific implementation, I think we
want to create a schema that can be used with an alternative
implementation w/o forcing the use of syncrepl/psearch and

Good point!

- values added on top of inherited set are represented as normal DNS
attributes: e.g. aRecord:
- values deleted from inherited set - *are open question*: It would be great
if we could store it under the same object as additions, it would make
implementation a bit simpler.
- Would it be acceptable to store override 'delete TXT record "hello"' as
attribute 'tXTRecord;x-deleted: test'?

I think this would be acceptable, however what happens if then someone
deletes the base object and later on again recreates it ?

Will the view still 'mask' it ?
My original idea was: "Yes, it will." The main reason is that user can have
some tools which do LDAP delete/add instead of replace/modify, so some data
from the base could be accidentally exposed if we delete 'override'
automatically with base object.


Is this the actual desired outcome maybe ?
This is a good question :-) This is most generic/powerful mechanism but it
could create some nasty surprises. One drawback is that you have to go and add
'mask'/'delete' record to affected views (if necessary) when you add a record
to the base.

As long as it is possible it is not surprising, I would expect that when
using inheritance.

Another variants:
aa) Do overrides on name-level instead of record level. I.e. records for
particular name will not be inherited if the override is present.

Base definition:
- gateway.example.com. A
- gateway.example.com. TXT "this record came from base"
- example.com          MX  10 gateway.example.com.

View definition:
- gateway.example.com. A

Result - view:
- gateway.example.com. A
- example.com          MX 10 gateway.example.com.

I think this is preferable indeed.

=> A and TXT records from base were not inherited because override for the
name 'gateway' was present in the view.
=> MX record for name 'example.com' was inherited because there is no override
with this name in the view.
=> Modification done in 'base' will not affect view in any way if the override
is present, so there can't be information leak.
=> This approach doesn't require ;x-deleted or cn=deleted trick.

It till requires an empty object to mask though, but that is fine I
think, I like this better.

Me too. Reasonable use will be to fill 'the base' with all shared names/records and use views mainly for addition and minor edits, so empty objects will not appear so often.

ab) No inheritance at all.
This is what BIND9 does if dynamic updates are enabled. After first update the
inheritance relationship is broken and views operate independently.

I am not sure what this means exactly, our server uses Dynamic Updates
by default, so I am not sure that 'breaking inheritance' on dynamic
updates makes much sense, we'd have no inheritance at all.

"we'd have no inheritance at all."
Exactly. BIND9 simply copies inherited records to each view during start up and then views operate independently. (If you use dynamic updates.)

Obviously, this is simplest and clearest solution. Maybe that it is enough for
most users, look at the support in open source software ...

Maybe that some UI support for copying from one view to the other would be 

It is certainly a first implementation option.
Start w/o inheritance but do not preclude the option of adding it later.

This is exactly why we have this discussion now. I want to prepare some future-proof plan. We have to find if 1:1 mapping between 'name+view' pair will be always here (even with views, inheritance and the other stuff).

All bind-dyndb-ldap depend on this relationship (at the moment), so I want to know if we are going to break it or not. I don't want to finish DNSSEC and then start re-writing it again because of views ...

Should we allow Dynamic Updates in Views at all ?
It would be too simple without dynamic updates :-)

I think that we should allow updates, otherwise we can drop all the code for
DNS updates from SSSD, ipa-client-install etc.

Of course, we can implement first version without support for updates and add
it later, if there is a demand. We just need to keep it in mind during design.

The problem with updates in views is that generally views are returned
based on the origin of the client.

now if you have laptops and you get the laptop outside of the company
then it could try to issue DNS updates, but given it is "outside" it
would be associated to the "external" view ?
Yes, it would be.

I do not think you'd want to allow a laptop to update the external view
in that case.
We are lucky, because BIND 9 allows us to define different update policies per-'zone+view' pair. E.g. particular zone in an internal view can allow updates as usual but the some zone in an external view can deny any updates.

We just need to store update policy somewhere. I guess that zone object stored in view container could be the right place, i.e. idnsName=zone1, idnsView=view1, cn=dns.

Granted a company like that should probably have an internal zone for
laptops that is not exposed at all ... but there will certainly be
cases, esp in small setups.

Perhaps it should be somehow optional.

- The other option is to store deleted attributes in separate object:
DN: cn=deleted, idnsName=record1, idnsName=zone1, idnsView=view1, cn=dns

This sound cumbersome and require a 3rd search for every query, nack :)
Again, 0 searches because of syncrepl :-)

Shouldn't depend on syncrepl for the general schema design imo, unless
there is a very strong degradation of performance trying not to.

I like variant A, I think it is the most sensible and the only one
really needed. People have an internal view and want to 'filter' it some
for the external world or similar.

Proposal - variant B (shared record groups)
- not so simple to implement, especially update-performance could be an issue
- multiple zones can share the same record group
- each view can contain arbitrary zones anf those zones can inherit arbitrary
record groups - inheritance is fully configurable
- the data in views can be modified via DNS updates, a change done to
inherited data creates an override (BIND9 does the same): e.g. name 'r1.z.' is
shared between View1 and View2. Value change in View1 doesn't affect View2.
- particular record from any shared record group can be overriden
(deleted/replaced) in any zone in any view
- changes done to the shared record group are propagated to all views (this is
the hard part!)

Sound very complex not only to build, but to explain to admins as well,
is anyone actually going to need this level of complexity, what scenario
would really benefit from this that can't be done with A ?
I can see one use case:

Domains 'flower-eshop.com' and 'parfums-eshop.com' are hosted in 'data centre
1', while domains 'car-eshop.com' and 'software-eshop.com' are hosted in 'data
centre 2'.

Typically it means that sites in one DC/group share the same set of NS
records, MX records etc.

So the admin will define record group "DC1":
NS ns1.dc1.examplewebhoster.com.
NS ns2.backup.examplewebhoster.com.
MX 10 mx1.dc1.examplewebhoster.com.
MX 20 mx1.dc2.examplewebhoster.com.

Record group "DC2":
NS ns1.dc2.examplewebhoster.com.
NS ns1.backup.examplewebhoster.com.
MX 20 mx1.dc1.examplewebhoster.com.
MX 10 mx1.dc2.examplewebhoster.com.

Now record group DC1 is assigned to servers hosted at DC1 and so on.
Result = new mail server for DC1 has to be added to single place (the record
group DC1) and all domains hosted at DC1 will automagically pick up the new

So you don't need to construct cycles over all servers in DC1, modify each
record by hand etc.

This sounds nice 'on the paper', but I don't know how big the real demand is ...

I do not see this as being very interesting in a FreeIPA scenario, but
I'd like to hear from actual users here.

I can see two minor use cases with every-day FreeIPA deployments:

1) Each zone managed by FreeIPA should list all DNS-enabled FreeIPA replicas in zone's NS records (for redundancy). => Replica add/delete means that user has to go through all zones and update NS records.
(We don't do it automatically: https://fedorahosted.org/freeipa/ticket/3343)

I'm not sure about this second use case, please correct me if I'm wrong.
2) Clients usually depend on SRV and _kerberos TXT records for auto-discovery.
=> Those records should be present in multiple domains if clients are scattered among those domains. (Is this assumption correct?) => Replica add/delete means that user has to go through all zones and update all relevant SRV records.

I can see another solution for the second case - add only CNAMEs pointing to the records in 'master' FreeIPA domain. In that case record group will only simplify zone addition - you would have to assign one record group instead of creating multiple CNAMEs.

Anyway, I don't think that those two cases are so important. This administrative burden can (and should!) be hidden in replica management scripts.

The main question is - can we set this one-level-inheritance-only schema design (variant A) in stone?

Petr^2 Spacek

Freeipa-users mailing list

Reply via email to