After some debugging, I found the error:

==== cut =====
ipa         : DEBUG    stderr=
ipa.ipapython.dnssec.bindmgr.BINDMgr: INFO     attrs: {'idnsseckeyref':
['pkcs11:object=a00001'], 'dn':
'cn=KSK-20140731111634Z-a00001,cn=keys,idnsname=myzone.com.,cn=dns,dc=int,dc=gtrs,dc=de',
'cn': ['KSK-20140731111634Z-a00001'], 'idnsseckeypublish':
['20140731111634Z'], 'objectclass': ['idnsSecKey'], 'idnsseckeysep':
['TRUE'], 'idnssecalgorithm': ['RSASHA1NSEC3SHA1'], 'idnsseckeyzone':
['TRUE'], 'idnsseckeycreated': ['20140731111634Z'],
'idnsseckeyactivate': ['20140731111634Z']}
ipa         : DEBUG    Starting external process
ipa         : DEBUG    args=/usr/sbin/dnssec-keyfromlabel-pkcs11 -K
/var/named/dyndb-ldap/ipa/master/myzone.com/tmp5dI2FC -a
RSASHA1NSEC3SHA1 -l
pkcs11:object=a00001;pin-source=/var/lib/ipa/dnssec/softhsm_pin -I none
-D none -P 20140731111634 -A 20140731111634 -f KSK myzone.com.
ipa         : DEBUG    Process finished, return code=1
ipa         : DEBUG    stdout=
ipa         : DEBUG    stderr=dnssec-keyfromlabel: fatal: unknown
algorithm RSASHA1NSEC3SHA1

Traceback (most recent call last):
  File "/usr/libexec/ipa/ipa-dnskeysyncd", line 112, in <module>
    while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
  File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 409,
in syncrepl_poll
    self.syncrepl_refreshdone()
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py",
line 118, in syncrepl_refreshdone
    self.bindmgr.sync(self.dnssec_zones)
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
line 209, in sync
    self.sync_zone(zone)
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
line 182, in sync_zone
    self.install_key(zone, uuid, attrs, tempdir)
  File "/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py",
line 117, in install_key
    result = ipautil.run(cmd, capture_output=True)
  File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line
479, in run
    raise CalledProcessError(p.returncode, arg_string, str(output))
subprocess.CalledProcessError: Command
'/usr/sbin/dnssec-keyfromlabel-pkcs11 -K
/var/named/dyndb-ldap/ipa/master/myzone.com/tmp5dI2FC -a
RSASHA1NSEC3SHA1 -l
pkcs11:object=a00001;pin-source=/var/lib/ipa/dnssec/softhsm_pin -I none
-D none -P 20140731111634 -A 20140731111634 -f KSK myzone.com.' returned
non-zero exit status 1
==== cut =====

dnssec-keyfromlabel-pkcs11 expects NSEC3RSASHA1 for algorithm 7, but it
gets RSASHA1NSEC3SHA1 instead (just the plain attribute value from LDAP).

I've changed a few lines in
/usr/lib/python2.7/site-packages/ipapython/dnssec/bindmgr.py in method
install_key:

==== cut ====
108c108,112
<         cmd = [paths.DNSSEC_KEYFROMLABEL, '-K', workdir, '-a',
attrs['idnsSecAlgorithm'][0], '-l', uri]
---
>         algo = attrs['idnsSecAlgorithm'][0]
>         if algo == 'RSASHA1NSEC3SHA1':
>               algo = 'NSEC3RSASHA1'
>         cmd = [paths.DNSSEC_KEYFROMLABEL, '-K', workdir, '-a', algo,
'-l', uri]
==== cut ====

Now, everything seems to work correctly: The DNSKEY records are
published with the correct algorithms and the ZSK is signed by both KSKs
(the imported one and the IPA generated one).

-Guido



On 17.08.2016 15:08, Petr Spacek wrote:
> On 17.8.2016 14:38, Guido Schmitz wrote:
>>>> Still, there is one problem:
>>>> My old KSK uses algorithm 7 (RSASHA1NSEC3SHA1) and IPA (by default) uses
>>>> algorithm 8 (RSASHA256). The old key is correctly marked as algorithm 7
>>>> in LDAP (under attribute idnsSecAlgorithm in the entry
>>>> cn=KSK-timestamp-id,cn=keys,idnsname=myzone.com,cn=dns), but BIND seems
>>>> to ignore this attribute and assumes that it is always algorithm 8.
>>>
>>> Hmm, algorithm mismatch will cause DNSSEC validation to break horribly. The
>>> generated records will not match what is indicated in DS record of the 
>>> parent
>>> zone...
>>>
>>> Please look into
>>> /var/named/dyndb-ldap/ipa/master/myzone.com/keys
>>> and inspect BIND key files (*.private). Cross-check values in files with
>>> values shown by OpenDNSSEC. All the values should match.
>>>
>>> If they do not match, we have a bug somewhere in the synchronization
>>> mechanism, which is possible.
>>
>> The imported KSK does not exist in this directory (neither on the master
>> server nor on the replica). The keys created by IPA are present in this
>> directory.
>>
>> Now, I also checked, if the imported KSK is used to sign the ZSK, but
>> there are no matching RRSIG records. (When I wrote earlier that BIND
>> uses the imported KSK, I only checked whether a DNSKEY record for this
>> KSK is present. The DNSKEY record is present, but with the wrong algorithm.)
> 
> Okay, so we need to go back to see where the problem is.
> 
> Part A - key material:
> 0. I assume that you double-checked key attributes in OpenDNSSEC.
> 
> 1. ipa-ods-exporter service on IPA DNSSEC key master server should not report
> any errors when exporting keys (triggered by ods-signer ipa-full-update)
> 
> 2. Output of these two commands should match:
> all IPA DNS servers$ \
> python2 /usr/lib/python2.*/site-packages/ipapython/dnssec/localhsm.py
> 
> any IPA DNS server$ \
> python2 /usr/lib/python2.*/site-packages/ipapython/dnssec/ldapkeydb.py
> 
> This verifies that key material was replicated correctly.
> 
> 
> Part B - key metadata:
> These are read by ipa-dnskeysyncd daemon from LDAP and stored in BIND key 
> files.
> 
> Please check logs of ipa-dnskeysyncd service and watch out for errors.
> debug=True in /etc/default.conf will tell you more if needed.
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to