[Freeipa-users] DNS views: request for comments

[Petr Spacek]

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
> synchronization.

Good point!

>>>>> - values added on top of inherited set are represented as normal DNS
>>>>> attributes: e.g. aRecord: 192.0.2.1
>>>>> - 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.
>
> Ok.
>
>>>> 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.
>>
>> Example:
>> Base definition:
>> - gateway.example.com. A   203.0.113.66
>> - gateway.example.com. TXT "this record came from base"
>> - example.com          MX  10 gateway.example.com.
>>
>> View definition:
>> - gateway.example.com. A 10.1.1.1
>>
>> Result - view:
>> - gateway.example.com. A  10.1.1.1
>> - 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 enough?
>
> 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.
Exactly.

> 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
>> server.
>>
>> 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