[Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview

[Petr Spacek]

On 16.10.2014 19:43, Jan Cholasta wrote:
> Dne 16.10.2014 v 17:59 Martin Basti napsal(a):
>> On 10/10/14 09:17, Martin Kosek wrote:
>>> On 10/09/2014 03:57 PM, Petr Spacek wrote:
>>>> Hello,
>>>>
>>>> it would be great if people could look at current state of DNSSEC
>>>> patches for
>>>> FreeIPA.
>>>>
>>>> It consist of several relatively independent parts:
>>>> - python-pkcs#11 interface written by Martin Basti:
>>>> https://github.com/spacekpe/freeipa-pkcs11
>>>>
>>>> - DNSSEC daemons written by me:
>>>> https://github.com/spacekpe/ipadnssecd
>>>>
>>>> - FreeIPA integration written by Martin Basti:
>>>> https://github.com/bastiak/freeipa/tree/dnssec
>> Here is updated repo with installers, please review:
>> https://github.com/bastiak/freeipa/tree/dnssec-4
>> branch dnssec-4
>>
>> TODO: integrate ipadnssecd daemons and pkcs11 helper, when finished

...

> 3)
>
> Not something you can fix in this commit, but shouldn't ipa-ods-exporter be
> named ipa-odsexportd, so that the naming is consistent with the rest of our
> daemons?

Side note: ipa-ods-exporter is not a daemon :-) It is single-shot binary 
activated via socket. It is replacement for "ODS signer" and uses the same 
protocol.

Anyway, I don't care much. Feel free pick a new name and let me know.

> 2)
>
> Why do you use the default /etc/softhsm2.conf file, instead of using e.g.
> /etc/ipa/dnssec/softhsm2.conf and passing it to SoftHSM in the SOFTHSM2_CONF
> environment variable?

I don't like the idea. The same library is used from named and ods-enforcerd 
so we would have to modify environment variables for all of them and do some 
monkey patching in /etc/systemd.

AFAIK current ipactl/framework is sooo clever so it deletes service files 
related to all services "managed" by IPA if they are located in /etc/systemd. 
As a result we don't have any way how to override values supplies by other 
packages now.

> 4)
>
> I think /etc/ipa/softhsm_pin_so should be moved to
> /etc/ipa/dnssec/softhsm_pin_so.

Is it a good idea to store both PINs on the same spot? softhsm_pin_so is not 
necessary at run-time so it can be readable only by root:root.

> Commit "DNSSEC: validate forwarders":
>
> 1)
>
> I'm not sure if failing on DNSSEC-disabled forwarders by default is a good
> idea. Perhaps there could be some auto-detection code? Something along the
> lines of:
>
>     if forwarders_support_dnssec:
>         if not options.no_dnssec_validation:
>             enable_dnssec_in_ipa()
>     else:
>         print "WARNING: DNSSEC will not be enabled"

We have discussed this with Martin and the intent is to tell people that their 
infrastructure is broken and has to be fixed - sooner is better.

There is an option --no-dnssec-validation for people who like broken 
infrastructure.

-- 
Petr^2 Spacek