[Opendnssec-user] segfault after system upgrade.
On our test system we have been running ods 2.0.3 with softhsm 2.2.0 for a few weeks without problems. Last week we upgraded the system from SUSE Linux Enterprise Server 12 (x86_64) SP1 to SP2. After this upgrade the enforcer exits with a segfault a short time after startup. In the system log we see: 2017-01-09T15:19:37.958829+01:00 kvivs20 ods-enforcerd: [engine] running as pid 17890 2017-01-09T15:19:37.959069+01:00 kvivs20 ods-enforcerd: [engine] enforcer started 2017-01-09T15:19:37.970328+01:00 kvivs20 ods-enforcerd: [enforcer] update zone: 15.125.129.in-addr.arpa 2017-01-09T15:19:37.978189+01:00 kvivs20 ods-enforcerd: [enforcer] update zone: 27.125.129.in-addr.arpa 2017-01-09T15:19:37.983407+01:00 kvivs20 ods-enforcerd: [enforcer] update zone: 37.125.129.in-addr.arpa 2017-01-09T15:19:37.988586+01:00 kvivs20 ods-enforcerd: [enforcer] update zone: 40.125.129.in-addr.arpa 2017-01-09T15:19:38.173046+01:00 kvivs20 kernel: [432557.821200] ods-enforcerd[17892]: segfault at 7efc1b23aff8 ip 7efc1cd1d6bc sp 7efc1b23b000 error 6 in libc-2.22.so[7efc1cca4000+19a000] 2017-01-09T15:19:47.908556+01:00 kvivs20 systemd-coredump[17896]: Process 17890 (ods-enforcerd) of user 0 dumped core. It looks as if there is a problem with zone 40.125.129.in-addr.arpa or 56.125.129.in-addr.arpa, because somewhere in the processing of these zones the error occurs each time. 40 is the last one mentioned, 56 is the first one not mentioned. If have tried to get a trace-back with valgrind, but that fails with an internal error in valgrind: # valgrind ods-enforcerd -d ==16788== Memcheck, a memory error detector ==16788== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==16788== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==16788== Command: /usr/local/sbin/ods-enforcerd -d ==16788== vex: the `impossible' happened: isZeroU vex storage: T total 535943568 bytes allocated vex storage: P total 640 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==16788==at 0x3803D1C8: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x3803D2F4: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x3803D531: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x3803D55A: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x38057F02: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x380FF028: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x3810BF2D: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x3810F9E1: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x38110A5E: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x38112345: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x381133F3: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x380FC885: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x3805A3D3: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x3808AD1A: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x3808C9DF: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==16788==by 0x3809BA7A: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 16788) ==16788==at 0x6101260: ??? (in /lib64/libcrypto.so.1.0.0) ==16788==by 0x60E4011: EC_POINT_mul (in /lib64/libcrypto.so.1.0.0) ==16788==by 0x60EBC97: EC_KEY_check_key (in /lib64/libcrypto.so.1.0.0) ==16788==by 0x60EC06D: EC_KEY_set_public_key_affine_coordinates (in /lib64/libcrypto.so.1.0.0) ==16788==by 0x61A0542: FIPS_selftest_ecdsa (in /lib64/libcrypto.so.1.0.0) ==16788==by 0x619BEE9: FIPS_selftest (in /lib64/libcrypto.so.1.0.0) ==16788==by 0x619ABF4: FIPS_module_mode_set (in /lib64/libcrypto.so.1.0.0) ==16788==by 0x607616B: FIPS_mode_set (in /lib64/libcrypto.so.1.0.0) ==16788==by 0x6072B5F: OPENSSL_init_library (in /lib64/libcrypto.so.1.0.0) ==16788==by 0x400EC09: call_init.part.0 (in /lib64/ld-2.22.so) ==16788==by 0x400ECF2: _dl_init (in /lib64/ld-2.22.so) ==16788==by 0x4001189: ??? (in /lib64/ld-2.22.so) ==16788==by 0x1: ??? ==16788==by 0xFFF00078E: ??? ==16788==by 0xFFF0007AC: ??? Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. Then I found the other thread in this mailing list about segfaults. I am not familiar with the debugger.
Re: [Opendnssec-user] OpenDNSSEC 2.0.3 released
I have been on holidays, so I noticed this message only last week. I will try the new version to check whether the problem with ZSK rollovers is solved, when using more than one ZSK. This will take some time. I already noticed that the output of "ods-enforcer backup list" has not yet been changed into something readable. Is that still in the planning? "Yuri Schaeffer" schreef in bericht news:365a8432-514f-62eb--e4df8b1d3...@nlnetlabs.nl... Dear community, Hereby we announce the OpenDNSSEC 2.0.3 release. Most of the changes are related to further smoothing the migration path from OpenDNSSEC 1.4 to 2.0. If you still need to migrate from 1.4.10 please migrate to 2.0.3 directly rather than from 2.0.1. Another important fix is a memory leak in the signer. It would cause a high memory usage for installations with very frequent outgoing IXFR's. Changes: * OpenDNSSEC-839: update all no longer deletes zones or policies. Policy import now has a --remove-missing-policies option. (thanks David Peall) * OpenDNSSEC-840: Fix migration script to correctly interpret SOA serial strategy. * OPENDNSSEC-843: MaxZoneTTL defaults to 0 instead of 1 day. * Migration script can handle converting a database with zones in rollover better. * Fixed incorrect behaviour when more than 2 ZSKs involved in roll. * SUPPORT-201: Remove old keys from converted DB. * OPENDNSSEC-845: Memory leak on IXFR out. Download: * https://dist.opendnssec.org/source/opendnssec-2.0.3.tar.gz * https://dist.opendnssec.org/source/opendnssec-2.0.3.tar.gz.sig * Checksum SHA256: ebeb5481d696cf83c21c5dfbecce6ab5dcc73df1a08573ef257f2f6fe10f6214 Kind regards, The OpenDNSSEC team ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] ods 2.0.1 ZSK roll-over problem
Hi Yuri, Is there any progress on this matter? I have a strong impression that the problem is not (only) caused by migration problems. It seems to happen always if a standby ZSK is configured. When after some days of changing keys states the system enters a more stable situation, then I see that there are two active ZSKs. Both ZSKs have the attribute in the signer configuration and both of them are found in the signed zone, although only one is used in the RRSIG records. (So, it would be better if the enforcer would show one as active and the other one as ready, but that is a minor problem.) When I force a ZSK roll-over, then both ZSKs go to the retire state and a new ZSK goes to the publish and later to the ready state. But only one of the retiring ZSKs is still present in the signed zone and unfortunately, it is the wrong one, the one that is not used in the RRSIG records. So, there are then many RRSIG records using an ZSK that is no longer present in the signed zone. When I set standby to 0, then after some days only one ZSK is left in the active state. If I then force a roll-over no problem is seen. The retiring ZSK stays in the signed zone untill all RRSIG records using this ZSK have been replaced. During the transition, there is no active ZSK, but one ZSK is in the retire state and the new ZSK is in the publish or ready state. (I would expect already an active state, but that is a minor problem.) During the transition the ZSKs used in the RRSIG are always present in the signed zone. So, I have now set standby to 0, hoping that this will avoid further problems. I wonder if you can reproduce this problem with standby ZSKs? Regards, Fred.Zwarts. "Fred.Zwarts" schreef in bericht news:nsar1v$2af$1...@blaine.gmane.org... Hi Yuri, I have been away a few days, so sorry for the late response. I am not sure that your diagnosis is the whole story. We have had two cases of this problem. In the first case your diagnosis may apply, because it happened rather soon after the migration. However, at the moment of the migration, there was no roll-over in progress, but there were two KSKs (one active, one standby) and two ZSKs (one active, one standby). Soon (two days) after the migration a scheduled ZSK roll-over started. The second case, on a different system, however, (from which I sent you the database) happened when ods had been running for about one month. There were no keys left from the migration, because a KSK and a ZSK roll-over had completed already. At that moment there was one KSK and there was one active ZSK and one ready (standby) ZSK. Then I forced a ZSK roll-over. So, I still think that the problem is not (only) the migration, but also the use of a standby ZSK. But, anyhow, it is good to make sure the signer doesn't keep signatures of a key that is no longer active or publish. But the question remains: what should the signer do if there are no ZSKs active of publish? We now have the situation with two retiring ZSKs and one ready ZSK. How long do we have to wait, till the ready ZSK will become active? Thanks, for your help, Fred.Zwarts. "Yuri Schaeffer" schreef in bericht news:2c127074-c0c2-2132-6da0-0fe173054...@nlnetlabs.nl... Hi Fred, Thanks for sharing the data, I now understand what has happened. The root cause must have been an error in the migration script. I'll write it down in detail so you can verify your part of the events. 1) Before migration there where two ZSKs in a rollover. Lets call those ZSK1(old) and ZSK2(new). 2) migration script was executed. ZSK2 was wrongfully marked as entirely propagated. (but in fact only some of the signatures where generated with this key) 3) enforcer ran, concluded ZSK1 could be removed, instructed the signer to stop publishing the DNSKEY of ZSK1. But the signer kept reusing signatures of this key. 4) Now the user issued a rollover to ZSK3 to fix the situation. But now we are in a situation where we still have signatures from ZSK1 and ZSK2. Both will be replaced by signatures of ZSK3 over the course of 14 days. (signature validity in KASP). To come out of this situation you could issue a ods-signer clear kvi.nl All signatures will then be regenerated at the next sign run. All of them with ZSK3 For us to do: 1) Fix migration script to better recognise current rollover. 2) Make sure the signer doesn't keep signatures of a key that is no longer active or publish. Regards, Yuri ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] ods 2.0.1 ZSK roll-over problem
Sorry, I forgot the database. See attachment. kasp.db Description: Binary data ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] ods 2.0.1 ZSK roll-over problem
I forced another ZSK roll-over on our test system and the same problem
popped up.
There are now two retiring ZSKs and one ready ZSK, but no active ZSK.
In the zone file, many records are still signed with the retiring ZSK.
However, this ZSK itself is no longer in the signed zone file.
Could it be that the option 1 causes these problems?
I know it is experimental, but it worked well in 1.4.10.
"Yuri Schaeffer" schreef in bericht
news:84b78896-1d8a-aadb-2628-672f977cf...@nlnetlabs.nl...
Hi Fred,
Can you send me the output of:
ods-enforcer key list -d
If possible, can you send me off list your kasp.db (assuming sqlite),
your kasp.xml. and the produced signconf for that zone? Then I can see
if it is perhaps I migration related issue.
Regards,
Yuri
On 16-09-16 22:38, Fred Zwarts, KVI, Groningen wrote:
We have ods 2.0.1 running for some time, but now a ZSK roll-over is
giving a problem.
Currently the situation is as follows:
# ods-enforcer key list --verbose
Keys:
Zone: Keytype: State:Date of next
transition: Size: Algorithm: CKA_ID:
Repository: KeyTag:
KVI.nl KSK retire2016-09-17 11:00:06
2048 8 d70448361bf9ded4888de4bb681a9963 SoftHSM 23384
KVI.nl ZSK retire2016-09-17 11:00:06
1024 8 664dd2e6d61153c53f99ac2dcafddbda SoftHSM 31771
KVI.nl KSK active2016-09-17 11:00:06
2048 8 333e0824ef6fc70c2729b02a88be92c7 SoftHSM 61849
KVI.nl ZSK retire2016-09-17 11:00:06
1024 8 6d31f5b7f2db0bc65fcb35f60ecceb1e SoftHSM 15381
KVI.nl ZSK ready 2016-09-17 11:00:06
1024 8 3c246656cd56b7cfd5294f5cb8e02229 SoftHSM 43923
key list completed in 0 seconds.
Parts from the signed zone as written by ods:
kvi.nl. 86400 IN SOA dns1.kvi.nl. hostmaster.kvi.nl.
2016091613 43200 3600 345600 10800
kvi.nl. 86400 IN RRSIG SOA 8 2 86400 20160930151204
20160916173547 43923 KVI.nl.
a1quYQgmEnAmt2BUdt3PAcEQ4mFCoLIULLEKKoICataE7OuXAbdhfjE9hT0nJeJPiLm6jmJmyj6fM2PwEb9DHS+PMulUc1L
snwayUoylsXm0HUFiAvG7+/tt2UYgybGCrXYWrrTJuu/VxMPSb4Qy5uEdwfEQRKs5w5Aeqci7aUQ=
kvi.nl. 3600IN DNSKEY 257 3 8
AwEAAb9i0ycPgnT71XuBrWg7XuvEcUcmhLsWtXsO/vmg3xpWiYR1wW15rEMvloZ7Bl7O4/42to8GlQHx0yY1r1Kx4mkFtH6Mol31QXE8vwk4JaG7dW3UJKCWAjLD2mrBhp0umzDQK5dlkE+9o
m0sjcz2aUASNAQqwh38qOl8+3jNGbfjaw9MGK1WMYRv805NGGgPnmQ1BoB/4d99nhzqAfAWLWRLCoxD2FWjbUm+cQCft+YMtzEk46Ua1H/g/0B38E/2A71fUMWfGM5tE0XuArpFc7ri81MAzEHl5gsYGgn4QnGlsg8ip0wFZns/1NndgXpnjMlSel
vp4EEC8RCBKJ7E5IM= ;{id = 61849 (ksk), size = 2048b}
kvi.nl. 3600IN DNSKEY 256 3 8
AwEAAbuEIkm1DbfRGZVFEfJ2BfD2h1us5RD85wTAZpXI9UfHpEjj86ApLn4uctHza1/ekkNAwy4aOgsz+TxLrvAhfKLfQL17q44ty6PDw8jQcinA8LIqB9xo9umvVagCHQeTTkoTRdHjh3DLQ
Fw9ice4N+7emoi+NTtTEa5pg9r1L41X ;{id = 43923 (zsk), size = 1024b}
kvi.nl. 3600IN RRSIG DNSKEY 8 2 3600 20160930105859
20160916140006 61849 KVI.nl.
LB2yvkZT3+8gKzLYlnlrhxbCmugYAe0R4mICsodskbBJaRDZUncObYJZv8a4ogZo6IIwswHj8EfwzofW6ZXfcrXAymNYQ
adD38Iht7Xc2S3axpAwZ2jKA/CnlBI9trB4WIwb8zLBbH1sCKrFIofa+2r8h1J2Gv6AU7hjbLHK5dCMP7MlkqO54t9ENDqC6AgvKMn6/miw7xrI+9hK6VLvxjv/zQddWa8S+EX8waYVUC9sZI2f2SYWVgS3xAkOyn0PXyr7/mZ6llssSLJ7UZ9AGB
sitpJpimw+1FqjiX5jls4tr8VsSONhsb+a7v/d8n5EoPgCwuhUT8viJxoSFcm5Iw==
kvi.nl. 86400 IN NS dns1.kvi.nl.
kvi.nl. 86400 IN NS dns2.kvi.nl.
kvi.nl. 86400 IN NS dwalin.nikhef.nl.
kvi.nl. 86400 IN RRSIG NS 8 2 86400 20160929021424
20160914141121 31771 KVI.nl.
xmrTUJo4xM9vzhah0tQ1sPoEub2KEajKEjUjgrKCXNFsdmrVge/3iP8rpcjukSxOXQ4zHTGprFKxzyBFgWtkzZRQHX9dD/DI
iLIWoJ2Wh1xKTfWSTydmrP5C3E7HR6y6fEZqJ16p6Wu/eAjbf3yPcRKHLXePWjbNFVXVrbuycw4=
The retiring keys are not present in the zone.
The retiring KSK is the old backup KSK from ods 1.4.10.
One of the retiring ZSK is the old backup ZSK from ods 1.4.10.
The other retiring ZSK is the old active ZSK.
The ready ZSK is the new ZSK. However, there is no active ZSK.
The ready ZSK is used to sign the SOA record, but the retiring ZSK 31771
is still used to sign other records, but it is not present in the zone.
So, now many of the records do not have a validated signature.
Any idea how this can be solved? Will the ready key become active at the
next transition?
___
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] ods 2.0.1 ZSK roll-over problem
Hi Yuri, I have been a few days away, so I read your message now. I am a bit confused about your reply. Does it refer to my first question, in an earlier mail, about the refusal of the signer to sign the zone because of the serial? This was indeed solved with "ods-enforcer policy import". However, a few days later we got this new problem with a ZSK roll-over, where ods 2.0.1 completely ruined the zone. No active ZSK was left. The retiring keys were not in the signed zone, but most of the records were still signed with the retiring keys. Some more "ods-enforcer policy import" did not help (of course). Only a few records were signed with the ready ZSK, which was also in the zone. Only those records could be used with DNSsec verification. Finally, my collegue deleted the zone from the database. So, I am not able to send you any other information. Could it be that this problem was also caused by a migration problem, or is it something else? Regards, Fred.Zwarts. "Yuri Schaeffer" schreef in bericht news:0bc2193f-292a-4952-5791-92ec713bc...@nlnetlabs.nl... Hi Fred, My colleague Hoda found the error. The SOA serial strategy is numbered differently between 1.4 and 2.0. This is actually a problem with the migration script not taking this in to account. What should solve your issue is running ods-enforcer policy import Your kasp.xml will be reread and any differences applied. Alternatively you could do it manually in your database (assuming default policy): UPDATE policy SET zoneSoaSerial=1 WHERE name = 'default'; I expect that field in your database to be 3. Which was 'datacounter' in 1.4. But maps to 'keep' in 2.0. For us left to do is update the migration script. Regards, Yuri ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] Serial problem after rollover in 2.0.1
"Yuri Schaeffer" schreef in bericht news:7b52287e-c6d9-7862-dcdc-3c9db8c8f...@nlnetlabs.nl... We never had this problem with 1.4. From our /etc/opendnssec/kasp.xml: PT15H PT86400S PT10800S datecounter The kasp.xml has not been touched since December 2015. So, there must be something else. Could it be that the migration of the database changed it from datacounter to keep? Should I update the configuration after the migration? The log message really seem to suggest 'keep' is used. Can you check the SOA section of /var/opendnssec/signconf/kvi.nl (or similar path)? If it says 'keep' in the signconf you should make sure the enforcerd reads the kasp.xml from the correct location. If it does -something odd has happend during conversion- you can issue a 'ods-enforcer policy import' to have the enforcer reread the kasp.xml. Regards, Yuri Thanks! The signconf indeed had a 'keep'. Using an enforcer policy import changed it into 'datecounter'. However, the system log shows some strange messages during the import operation: 2016-09-16T12:48:12.257225+02:00 kvir07 ods-enforcerd: INFO: The XML in /etc/opendnssec/kasp.xml is valid 2016-09-16T12:48:12.257576+02:00 kvir07 ods-enforcerd: WARNING: No policy named 'default' in /etc/opendnssec/kasp.xml. This means you will need to refer explicitly to the policy for each zone 2016-09-16T12:48:12.257742+02:00 kvir07 ods-enforcerd: WARNING: In policy SIDN, Y used in duration field for Keys/KSK Lifetime (P1Y) in /etc/opendnssec/kasp.xml - this will be interpreted as 365 days 2016-09-16T12:48:12.257897+02:00 kvir07 ods-enforcerd: WARNING: In policy SIDN, M used in duration field for Keys/ZSK Lifetime (P3M) in /etc/opendnssec/kasp.xml - this will be interpreted as 31 days 2016-09-16T12:48:12.258054+02:00 kvir07 ods-enforcerd: WARNING: In policy RuG, Y used in duration field for Keys/KSK Lifetime (P1Y) in /etc/opendnssec/kasp.xml - this will be interpreted as 365 days 2016-09-16T12:48:12.258315+02:00 kvir07 ods-enforcerd: WARNING: In policy RuG, M used in duration field for Keys/ZSK Lifetime (P3M) in /etc/opendnssec/kasp.xml - this will be interpreted as 31 days 2016-09-16T12:48:12.258789+02:00 kvir07 ods-enforcerd: [policy_import] policy SIDN updated 2016-09-16T12:48:12.259838+02:00 kvir07 ods-enforcerd: [policy_import] policy RuG updated 2016-09-16T12:48:12.260044+02:00 kvir07 ods-enforcerd: [signconf_cmd] performing signconf for all zones 2016-09-16T12:48:12.261957+02:00 kvir07 ods-enforcerd: [signconf_cmd] signconf done, notifying signer 2016-09-16T12:48:12.265637+02:00 kvir07 ods-enforcerd: [enforce_task] No changes to any signconf file required 2016-09-16T12:48:12.267431+02:00 kvir07 ods-signerd: [nsec3] invalid salt 0 2016-09-16T12:48:12.267635+02:00 kvir07 ods-signerd: [nsec3] unable to create: create salt failed 2016-09-16T12:48:12.267804+02:00 kvir07 ods-signerd: [signconf] unable to read signconf /var/opendnssec/signconf/KVI.nl.xml: nsec3params_create() failed 2016-09-16T12:48:12.267963+02:00 kvir07 ods-signerd: [signconf] unable to update signconf: failed to read file /var/opendnssec/signconf/KVI.nl.xml (Memory allocation error) 2016-09-16T12:48:12.268116+02:00 kvir07 ods-signerd: [zone] unable to load signconf for zone KVI.nl: signconf /var/opendnssec/signconf/KVI.nl.xml Memory allocation error 2016-09-16T12:48:12.268271+02:00 kvir07 ods-signerd: [tools] unable to load signconf for zone KVI.nl: Memory allocation error 2016-09-16T12:48:12.268427+02:00 kvir07 ods-signerd: [worker[1]] continue task [sign] for zone KVI.nl 2016-09-16T12:48:12.466672+02:00 kvir07 ods-enforcerd: [signconf_cmd] performing signconf for all zones 2016-09-16T12:48:12.468766+02:00 kvir07 ods-enforcerd: [signconf_cmd] signconf done, notifying signer 2016-09-16T12:48:12.472990+02:00 kvir07 ods-enforcerd: [signconf_cmd] performing signconf for all zones 2016-09-16T12:48:12.474993+02:00 kvir07 ods-enforcerd: [signconf_cmd] signconf done, notifying signer 2016-09-16T12:48:12.485463+02:00 kvir07 ods-signerd: [signconf] zone KVI.nl signconf: RESIGN[PT2H] REFRESH[P3D] VALIDITY[P14D] DENIAL[P14D] KEYSET[PT0S] JITTER[P1D] OFFSET[PT1H] NSEC[50] DNSKEYTTL[PT1H] SOATTL[P1D] MINIMUM[PT3H] SERIAL[datecounter] 2016-09-16T12:48:12.839254+02:00 kvir07 ods-signerd: [STATS] KVI.nl 2016091604 RR[count=1 time=0(sec)] NSEC3[count=676 time=0(sec)] RRSIG[new=682 reused=2963 time=0(sec) avg=0(sig/sec)] TOTAL[time=0(sec)] 2016-09-16T12:48:12.880746+02:00 kvir07 ods-signerd: [worker[1]] continue task [sign] for zone KVI.nl I use explicit policies, so the default policy is not needed. I am worried a bit about the signer messages about salt and about Memory allocation error. It seems that it recovered from that, but I am not sure. I will monitor it the next few hours to see if it keeps running. At least the "ods-signer sign --all" can now be used several times without the need to update the input
Re: [Opendnssec-user] Serial problem after rollover in 2.0.1
"Yuri Schaeffer" schreef in bericht news:46da313f-2c47-92b1-8c3d-cc1af1ec6...@nlnetlabs.nl... Hi Fred, The log message "If this is the result of a key rollover ..." suggests (at least to me) that it is normal that a manual intervention is needed during a roll-over, but we are not used to it. Is this a bug, or is it the intended behavior? Are there new options to be included in the configuration? I'm guessing you use 'keep' strategy[0] for the SOA. Then you are responsible to increment the serial yourself and the signer is unable to push out updates when that hasn't happened. The reason for the message is that the enforcer can have the signer notified that a resign needs to happen. (because a key rollover for example). But with this serial strategy the signer can't without a SOA bump. So make sure your serial in the input zone is greater than 2016091511. But better would be to use 'datecounter' to let the signer manage the serial. Regards, Yuri We never had this problem with 1.4. From our /etc/opendnssec/kasp.xml: PT15H PT86400S PT10800S datecounter The kasp.xml has not been touched since December 2015. So, there must be something else. Could it be that the migration of the database changed it from datacounter to keep? Should I update the configuration after the migration? ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] Serial problem after rollover in 2.0.1
Recently we upgraded to ods 2.01. from 1.4.10. During key roll-overs we never needed to update our input zones as long as we used version 1. This night ods was still in the process of retiring the backup keys, used in version 1.4.10, when it started a ZSK key roll-over. After that the signer refused to sign zones. The log file shows messages from the signer each hour, see the attachment. The fix was easy, we incremented the serial of the input zone. The log message "If this is the result of a key rollover ..." suggests (at least to me) that it is normal that a manual intervention is needed during a roll-over, but we are not used to it. Is this a bug, or is it the intended behavior? Are there new options to be included in the configuration? 2016-09-16T05:03:06.542733+02:00 kvir07 ods-signerd: [namedb] zone KVI.nl cannot keep SOA SERIAL from input zone (2016090700): previous output SOA SERIAL is 2016091511 2016-09-16T05:03:06.543058+02:00 kvir07 ods-signerd: [adapter] unable to add soa to zone KVI.nl: failed to replace soa serial rdata (Conflict detected) 2016-09-16T05:03:06.543216+02:00 kvir07 ods-signerd: [adapter] If this is the result of a key rollover, please increment the serial in the unsigned zone KVI.nl 2016-09-16T05:03:06.543368+02:00 kvir07 ods-signerd: [adapter] unable to add rr: failed to process soa record 2016-09-16T05:03:06.543514+02:00 kvir07 ods-signerd: [adapter] error adding RR at line 672: KVI.nl. INSOA DNS1.KVI.nl. HOSTMASTER.KVI.nl. 2016090700 12h 1h 4d 3h 2016-09-16T05:03:06.543662+02:00 kvir07 ods-signerd: [tools] unable to read zone KVI.nl: adapter failed (Conflict detected) 2016-09-16T05:03:06.543807+02:00 kvir07 ods-signerd: [worker[2]] CRITICAL: failed to sign zone KVI.nl: Conflict detected 2016-09-16T05:03:06.543953+02:00 kvir07 ods-signerd: [worker[2]] backoff task [read] for zone KVI.nl with 3600 seconds ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] ODS 2.0.1 did not start after reboot.
"Petr Spacek" schreef in bericht news:2e3a5fd7-0746-c621-d15a-f95abe280...@redhat.com... On 30.8.2016 10:12, Wytze van der Raay wrote: On 08/30/2016 09:46 AM, Fred.Zwarts wrote: ODS 2.0.1 has now been running satisfactory on our test system for several weeks. However, recently we noticed that each time we reboot the system, ods does not startup properly. It turns out that after each reboot, the directory /var/run/opendnssec has disappeared, so opendnssec can not start, because it wants to create sock and pid files in this directory. I have worked around this problem, by modifying /usr/local/sbin/ods-control, where I added a mkdir for this directory just before the startup of the enforcer. It is not clear to me how this directory disappears. The test system runs SLES 12 SP1. I hope that this information helps to improve this software. I recognize the problem ... we are running ODS 2.0.1 on OpenSUSE 13.2, which is presumably quite similar to SLES 12 SP1. The /var/run directory is a symbolic link to the /run directory. /run is created as tmpfs on every reboot, ie its content does not persist. This change has been made in SUSE and several other Linux distros to accomodate systemd, see for example http://www.h-online.com/open/news/item/Linux-distributions-to-include-run-directory-1219006.html for some background. I *think* that if one uses a proper systemd script for starting/stopping ODS, it is possible to have the opendnssec directory created automatically more or less, but my current hack is to put a "mkdir -p /var/run/opendnssec" in its (oldfashioned init-style) startup script. The same issue exists with nsd, and I solved it in the same way. "Proper systemd-way" is to use tmpfiles.d config file: https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html It allows to specify what directories and files should be re-created as needed. I'm attaching config file which is shipped right now by Fedora 24. It would be awesome if OpenDNSSEC could ship its tmpfiles.d config file somewhere in contrib directory in source tree or so. It would allow all systemd-based distros to use the proper config file instead of inventing own buggy ones. Petr Spacek @ Red Hat Thanks. I made a conf file in /etc/tmpfiles.d and it works! No messing in files that are overwritten with new versions of opendnssec. ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] *****SPAM***** ODS 2.0.1 did not start after reboot.
Spam detection software, running on the system "dicht.nlnetlabs.nl", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: ODS 2.0.1 has now been running satisfactory on our test system for several weeks. However, recently we noticed that each time we reboot the system, ods does not startup properly. It turns out that after each reboot, the directory /var/run/opendnssec has disappeared, so opendnssec can not start, because it wants to create sock and pid files in this directory. I have worked around this problem, by modifying /usr/local/sbin/ods-control, where I added a mkdir for this directory just before the startup of the enforcer. [...] Content analysis details: (5.5 points, 5.0 required) pts rule name description -- -- 0.2 STOX_REPLY_TYPENo description available. 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 1.9 STOX_REPLY_TYPE_WITHOUT_QUOTES No description available. 2.2 TO_NO_BRKTS_MSFT To: lacks brackets and supposed Microsoft tool --- Begin Message --- ODS 2.0.1 has now been running satisfactory on our test system for several weeks. However, recently we noticed that each time we reboot the system, ods does not startup properly. It turns out that after each reboot, the directory /var/run/opendnssec has disappeared, so opendnssec can not start, because it wants to create sock and pid files in this directory. I have worked around this problem, by modifying /usr/local/sbin/ods-control, where I added a mkdir for this directory just before the startup of the enforcer. It is not clear to me how this directory disappears. The test system runs SLES 12 SP1. I hope that this information helps to improve this software. --- End Message --- ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] *****SPAM***** Whats wrong in my ods 2.0o.1 setup.
Spam detection software, running on the system "dicht.nlnetlabs.nl", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Last week I migrated the ods 1.4.10 system on our test system to ods 2.0.1. As mentioned my previous mails, there were some problems to understand what was happening, but at the end I thought that al was running well. [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description -- -- 0.2 STOX_REPLY_TYPENo description available. 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 1.9 STOX_REPLY_TYPE_WITHOUT_QUOTES No description available. 2.5 TO_NO_BRKTS_MSFT To: lacks brackets and supposed Microsoft tool --- Begin Message --- Last week I migrated the ods 1.4.10 system on our test system to ods 2.0.1. As mentioned my previous mails, there were some problems to understand what was happening, but at the end I thought that al was running well. This morning I am confused again. I see the following: # date Mon Aug 15 09:06:30 CEST 2016 # ods-enforcer queue There are 2 tasks scheduled. It is now Mon Aug 15 09:06:33 2016 (1471244793 seconds since epoch) Next task scheduled Sat Aug 13 14:22:00 2016 (1471090920 seconds since epoch) On Sat Aug 13 14:22:00 2016 I will [enforce] 40.125.129.in-addr.arpa On Fri Nov 18 11:10:04 2016 I will [resalt] policies queue completed in 0 seconds. # ods-enforcer key list --verbose --zone 40.125.129.in-addr.arpa Keys: Zone: Keytype: State:Date of next transition: Size: Algorithm: CKA_ID: Repository: KeyTag: 40.125.129.in-addr.arpa KSK retire2016-08-13 14:22:00 2048 8 e1702efbbc4f0649b30b480751a6 SoftHSM 43985 40.125.129.in-addr.arpa KSK active2016-08-13 14:22:00 2048 8 956d1b9309f7db3f5dd407c5a2153d64 SoftHSM 64277 40.125.129.in-addr.arpa ZSK retire2016-08-13 14:22:00 1024 8 f3234adb1562a65782baf23fbb03fb47 SoftHSM 1558 40.125.129.in-addr.arpa ZSK active2016-08-13 14:22:00 1024 8 0db0fe4431642f178a1130330e87420e SoftHSM 57468 40.125.129.in-addr.arpa ZSK ready 2016-08-13 14:22:00 1024 8 41501fedde3f3380fa05753010f2f022 SoftHSM 53019 key list completed in 0 seconds. # The enforcer has scheduled a task in the past. How is that possible? A second question. I also noticed messages in the system log file of a few days ago. They appear for all domains. I list it here for one domain: 2016-08-10T11:56:24.269750+02:00 kvivs20 ods-signerd: [namedb] zone KVI.nl cannot keep SOA SERIAL from input zone (2014042300): previous output SOA SERIAL is 201608100 3 2016-08-10T11:56:24.270169+02:00 kvivs20 ods-signerd: [adapter] unable to add soa to zone KVI.nl: failed to replace soa serial rdata (Conflict detected) 2016-08-10T11:56:24.274181+02:00 kvivs20 ods-signerd: [adapter] If this is the result of a key rollover, please increment the serial in the unsigned zone KVI.nl 2016-08-10T11:56:24.274784+02:00 kvivs20 ods-signerd: [adapter] unable to add rr: failed to process soa record 2016-08-10T11:56:24.275224+02:00 kvivs20 ods-signerd: [adapter] error adding RR at line 594: KVI.nl. INSOA DNS1.KVI.nl. HOSTMASTER.KVI.nl. 2014042300 12h 1h 4d 1h 2016-08-10T11:56:24.275677+02:00 kvivs20 ods-signerd: [tools] unable to read zone KVI.nl: adapter failed (Conflict detected) - These messages started early in the morning, continued for about 4 hours (about 10 times for each domain with increasing intervals between 1 minute and one hour) and then stopped, without any change in the configuration. Also the input zones were not changed. Is this something to worry about? Are we assumed to increment the serial of the unsigned zone during a rollover? At the moment everything looks normal. The unsigned zone is still unchanged and the signed zone is dated Aug 15 08:33 and shows a serial of 2016081504. Regards, Fred.Zwarts. --- End Message --- ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] Date of next transition in the past.
Thanks for the information. This was not really a problem, it was only confusion me. Fred.Zwarts. "Yuri Schaeffer" schreef in bericht news:dcd38baa-6595-ea86-74ae-0d7076fbc...@nlnetlabs.nl... Is it normal that only KVI.nl is mentioned in the queues, not the other domains? Yes it is. There is one enforce task that will enforce all zones (that need it). KVI.nl happens to be the first one. The future ods2.1 will address this and schedule a task for each zone. Bij stopping en starting ods, the dates shown are now in the future: This suggests that the dates are only updated at startup. The times are actually updated when the enforce task runs (which also happens on startup). Next time try a explicit enforce. See: ods-enforcer help enforce Your output of the queue command reassures me that this was only a display problem. The enforce task was scheduled properly. Not sure at this point why but we'll sort it out for the next release. //Yuri ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] Date of next transition in the past.
# ods-enforcer key list --zone 37.125.129.in-addr.arpa Keys: Zone: Keytype: State:Date of next transition: 37.125.129.in-addr.arpa KSK retire2016-08-11 04:53:24 37.125.129.in-addr.arpa KSK active2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK retire2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK active2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK ready 2016-08-11 04:53:24 key list completed in 0 seconds. # ods-enforcer queue There are 2 tasks scheduled. It is now Fri Aug 12 09:13:24 2016 (1470986004 seconds since epoch) Next task scheduled Fri Aug 12 16:33:10 2016 (1471012390 seconds since epoch) On Fri Aug 12 16:33:10 2016 I will [enforce] KVI.nl On Fri Nov 18 11:10:04 2016 I will [resalt] policies queue completed in 0 seconds. # date Fri Aug 12 09:14:01 CEST 2016 # Is it normal that only KVI.nl is mentioned in the queues, not the other domains? Fred.Zwarts. "Yuri Schaeffer" schreef in bericht news:fa5bd541-5887-e339-3932-61dfc6b50...@nlnetlabs.nl... Today I noticed something else on our test system with ods 2.0.1: # date Thu Aug 11 15:48:31 CEST 2016 # ods-enforcer key list --zone 37.125.129.in-addr.arpa Keys: Zone: Keytype: State:Date of next transition: 37.125.129.in-addr.arpa KSK retire2016-08-11 04:53:24 37.125.129.in-addr.arpa KSK active2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK retire2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK active2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK ready 2016-08-11 04:53:24 key list completed in 0 seconds. # Should it worry me that all dates-times are in the past? Not necessarily. That date of next transition is for displaying purposes only. To be able to print something that is like ODS 1.4. Though it is unexpected. Could you check the output of ods-enforcer queue It should be the time the zone is enforced again by the way. Not specifically the key. So all having the same time is normal. //Yuri ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] *****SPAM***** Date of next transition in the past.
Spam detection software, running on the system "dicht.nlnetlabs.nl", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Today I noticed something else on our test system with ods 2.0.1: # date Thu Aug 11 15:48:31 CEST 2016 # ods-enforcer key list --zone 37.125.129.in-addr.arpa Keys: Zone: Keytype: State: Date of next transition: 37.125.129.in-addr.arpa KSK retire 2016-08-11 04:53:24 37.125.129.in-addr.arpa KSK active 2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK retire 2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK active 2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK ready 2016-08-11 04:53:24 key list completed in 0 seconds. # [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description -- -- 0.2 STOX_REPLY_TYPENo description available. 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 1.9 STOX_REPLY_TYPE_WITHOUT_QUOTES No description available. 2.5 TO_NO_BRKTS_MSFT To: lacks brackets and supposed Microsoft tool --- Begin Message --- Today I noticed something else on our test system with ods 2.0.1: # date Thu Aug 11 15:48:31 CEST 2016 # ods-enforcer key list --zone 37.125.129.in-addr.arpa Keys: Zone: Keytype: State:Date of next transition: 37.125.129.in-addr.arpa KSK retire2016-08-11 04:53:24 37.125.129.in-addr.arpa KSK active2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK retire2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK active2016-08-11 04:53:24 37.125.129.in-addr.arpa ZSK ready 2016-08-11 04:53:24 key list completed in 0 seconds. # Should it worry me that all dates-times are in the past? --- End Message --- ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] key export in ods 2.0.1
Thanks, this helps a bit. But "dead", "unknown" and "mixed" still result in "unknown keystate, Error parsing arguments" when used to export keys. What should I use to export keys in the states "waiting for ds-seen" and "waiting for ds-gone"? (These are the ones (with the -ds option) that are needed during roll-overs to update the parent zone.) Thanks for your patience. Fred.Zwarts. "Yuri Schaeffer" schreef in bericht news:37170e1f-d553-1db6-545c-ac2fc7002...@nlnetlabs.nl... So, to get the export the --keystate option of ods-enforcer must be used. I could not find in the documentation how the different keystates can be specified. I see that "retire" and "active" are accepted, but "ds-seen", or "waiting for ds-seen" result in "unknown keystate, Error parsing arguments". Where can I find a list of acceptable keystates? I made an issue for us to fix this code and documentation. For now, the code defines the following states: "generate", "publish", "ready", "active", "retire", "dead", "unknown", "mixed" //Yuri ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] key export in ods 2.0.1
So, to get the export the --keystate option of ods-enforcer must be used. I
could not find in the documentation how the different keystates can be
specified. I see that "retire" and "active" are accepted, but "ds-seen", or
"waiting for ds-seen" result in "unknown keystate, Error parsing arguments".
Where can I find a list of acceptable keystates?
Fred.Zwarts.
"Fred.Zwarts" schreef in bericht news:noem06$4sl$1...@blaine.gmane.org...
# ods-enforcer key list --zone KVI.nl
Keys:
Zone: Keytype: State:Date of next transition:
KVI.nl KSK retire2016-08-12 16:33:10
KVI.nl ZSK active2016-08-12 16:33:10
KVI.nl ZSK ready 2016-08-12 16:33:10
KVI.nl KSK active2016-08-12 16:33:10
key list completed in 0 seconds.
# ods-enforcer key export --zone KVI.nl -t KSK
key export completed in 0 seconds.
# ods-enforcer key export --zone KVI.nl --keystate active
KVI.nl. 3600IN DNSKEY 257 3 8
AwEAAcVFSs7AaspVxBjZSX8WP6nsIBcSwxM4JW3ZCmxCE9J3RIe9iujl2T0UT9oPqyLC8gI42Pbg0bLJweEjJXGFnA2NDDmUq4mcdflg0s8S2R36eX7uaK22lmv/n6etgRv5haoeEQOn+2tbb5+JUzty/NS+HoPNGf0zzPewkkZg+1gKmW+lgBnWw4thMPwcGsDz8b0vUpneOPiKlA5jx0EBmKLcSh3S5RBmgSMxFdn+gIAsoFw96fJcimF74a9acf9Z19WnPOOJ3nIsp7dMpwEiWqOlEgoPPxgGIZKwF6b5kZ/uPrSsbHHDOIVv4k6gkSmqaLV8HNqTxXpl1svPNtUOzqE=
;{id = 38854 (ksk), size = 2048b}
key export completed in 0 seconds.
#
So, adding "-t KSK" did not help, but adding "--keystate active" did.
Apparently, the default is not ready and active, but "waiting for ds-seen"?
Fred.Zwarts.
"Yuri Schaeffer" schreef in bericht
news:7be600ce-153f-7c42-046e-5c4ce5ad5...@nlnetlabs.nl...
Hi Fred,
On 09-08-16 17:14, Fred.Zwarts wrote:
There are active and ready keys:
# ods-enforcer key list --zone KVI.nl
Keys:
Zone: Keytype: State:Date of next
transition:
KVI.nl KSK retire2016-08-12 16:33:10
KVI.nl ZSK active2016-08-12 16:33:10
KVI.nl ZSK ready 2016-08-12 16:33:10
KVI.nl KSK active2016-08-12 16:33:10
key list completed in 0 seconds.
# ods-enforcer key export --zone KVI.nl
key export completed in 0 seconds.
I'll rephrase Hoda's words to make it a bit more accurate: key export
prints the keys that need to be submitted to the parent zone and are not
ds-seen yet. So if it would say "waiting for ds-seen" your key export
would also show you the DNSKEY record.
try:
ods-enforcer key export --zone KVI.nl -t KSK
//Yuri
___
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] Migrating to SoftHSM2
Thanks for your response. So, I was at the right track, but the version of SoftHSM2 that is currently released, does not yoet support a migration from SoftHSM v1. I will wait for a new release of SoftHSM that will support the migration. Any idea when we can expect the next release of SoftHSM2? Fred.Zwarts. -Oorspronkelijk bericht- From: Rickard Bellgrim Sent: Sunday, January 10, 2016 8:07 AM To: Fred Zwarts, KVI, Groningen Cc: Rick van Rein ; Opendnssec-user@lists.opendnssec.org List Subject: Re: [Opendnssec-user] Migrating to SoftHSM2 2015-12-23T09:27:09.152565+01:00 kvivs20 ods-signerd: [hsm] sign init: CKR_GENERAL_ERROR 2015-12-23T09:27:09.152600+01:00 kvivs20 ods-signerd: [hsm] error signing rrset with libhsm 2015-12-23T09:27:09.152635+01:00 kvivs20 ods-signerd: [rrset] unable to sign RRset[99]: lhsm_sign() failed 2015-12-23T09:27:09.152671+01:00 kvivs20 ods-signerd: SecureDataManager.cpp(359): Invalid IV in encrypted data 2015-12-23T09:27:09.152706+01:00 kvivs20 ods-signerd: [hsm] sign init: CKR_GENERAL_ERROR 2015-12-23T09:27:09.152741+01:00 kvivs20 ods-signerd: [hsm] error signing rrset with libhsm 2015-12-23T09:27:09.152780+01:00 kvivs20 ods-signerd: [rrset] unable to sign RRset[28]: lhsm_sign() failed 2015-12-23T09:27:09.152817+01:00 kvivs20 ods-signerd: [worker[2]] sign zone KVI.nl failed: 673 RRsets failed 2015-12-23T09:27:09.152852+01:00 kvivs20 ods-signerd: [worker[2]] CRITICAL: failed to sign zone KVI.nl: General error 2015-12-23T09:27:09.152887+01:00 kvivs20 ods-signerd: [worker[2]] backoff task [sign] for zone KVI.nl with 60 seconds Do you have any idea what can be done for further diagnosis, or for repair? The issue was fixed in https://github.com/opendnssec/SoftHSMv2/pull/163 The fix has not been released, but is merged into the develop branch on GitHub. // Rickard ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
Re: [Opendnssec-user] Migrating to SoftHSM2
You did not quote enough. My reaction was related to what Rickard wrote: The issue was fixed in https://github.com/opendnssec/SoftHSMv2/pull/163 The fix has not been released, but is merged into the develop branch on GitHub. As you will have seen in this thread, SoftHSM2 contains a migration tool, that I tried to use. This attempt failed, because of a bug. So, I want to wait for a release that includes this fix, so that I can test the migration in a supported environment. Our production system uses only released versions of the software. We want to test the migration in the same enviroment as our production system. Fred.Zwarts. "Jaap Akkerhuis" schreef in bericht news:20160109.u0bb9wsh020...@bela.nlnetlabs.nl... "Fred.Zwarts" writes: > Thanks for your response. So, I was at the right track, but the version > of > SoftHSM2 that is currently released, does not yoet support a migration > from > SoftHSM v1. I will wait for a new release of SoftHSM that will support > the > migration. Any idea when we can expect the next release of SoftHSM2? > Which release are you lookiong at? The one from <https://www.opendnssec.org/2015/07/softhsm-2-0-0/> says: $ tar tvf softhsm-2.0.0.tar.gz | grep migrate drwxrwxr-x 0 1000 10000 Jul 17 17:33 softhsm-2.0.0/src/bin/migrate/ -rw-rw-r-- 0 1000 1000 447 Jun 1 2015 softhsm-2.0.0/src/bin/migrate/Makefile.am -rw-rw-r-- 0 1000 1000 1323 Jun 1 2015 softhsm-2.0.0/src/bin/migrate/softhsm2-migrate.1 -rw-rw-r-- 0 1000 100025093 Jul 17 17:21 softhsm-2.0.0/src/bin/migrate/Makefile.in -rw-rw-r-- 0 1000 100018713 Jun 1 2015 softhsm-2.0.0/src/bin/migrate/softhsm2-migrate.cpp -rw-rw-r-- 0 1000 1000 2768 Jun 1 2015 softhsm-2.0.0/src/bin/migrate/softhsm2-migrate.h $ jaap ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] Re: opendnssec 1.4.8
"Yuri Schaeffer" schreef in bericht news:56128ae3.9060...@nlnetlabs.nl... -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Make sure you get 1.4.8.2 which actually includes said scripts... //Yuri On 05-10-15 15:36, Yuri Schaeffer wrote: Hi Fred, On 05-10-15 13:17, Fred.Zwarts wrote: Apparently, the upgrade from 1.4.7 to 1.4.8 is not as straightforward as with previous versions. What is the correct upgrade procedure? Thanks for your report. I just uploaded 1.4.8.1 to include a database migration script. See the MIGRATION file in the root of the tarball. Please also recompile OpenDNSSEC from this source as the database version number will be bumped by running this script. Regards, Yuri ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user I downloaded 1.4.8.2 and this time it seems to work. I can start opendnssec again and I do no longer see strange messages in the system log. The commands I tried show reasonable output. Thanks for the support. ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] opendnssec 1.4.8
I noticed that opendnssec 1.4.8 has been released today. I tried to use it on our test system, which has been running 1.4.7 for some months now without problems. Compilation and linking went without problems. The installation seems to copy the files to the right directories. Then I stopped the running 1.4.7 system and started the new 1.4.8 system. In the system log file I now see some messages that I did not see before: When setting up policies: Oct 5 12:59:08 KVIVS13 ods-enforcerd: ERROR: no such parameter with name revoked Oct 5 12:59:08 KVIVS13 ods-enforcerd: Could not predict ksk requirement for next interval for POLICY1 Oct 5 12:59:08 KVIVS13 ods-enforcerd: ERROR: no such parameter with name revoked Oct 5 12:59:08 KVIVS13 ods-enforcerd: Could not count current ksk numbers for policy POLICY1 When setting up zones: Oct 5 12:59:08 KVIVS13 ods-enforcerd: ERROR: no such parameter with name revoked Oct 5 12:59:08 KVIVS13 ods-enforcerd: Error allocating zsks to zone a.b.c.d opendnssec does not seem to be started proberly. Most commands fail: # ods-ksmutil key list --verbose SQLite database set to: /var/opendnssec/kasp.db Keys: ERROR: error executing SQL - no such column: k.rfc5011 Error: failed to list keys Apparently, the upgrade from 1.4.7 to 1.4.8 is not as straightforward as with previous versions. What is the correct upgrade procedure? Our system: SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 4 SoftHSM 1.3.7 ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] Re: opendnssec 1.4.8
"Yuri Schaeffer" schreef in bericht news:56127ccf.8020...@nlnetlabs.nl... -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Fred, On 05-10-15 13:17, Fred.Zwarts wrote: Apparently, the upgrade from 1.4.7 to 1.4.8 is not as straightforward as with previous versions. What is the correct upgrade procedure? Thanks for your report. I just uploaded 1.4.8.1 to include a database migration script. See the MIGRATION file in the root of the tarball. Please also recompile OpenDNSSEC from this source as the database version number will be bumped by running this script. Regards, Yuri I dowloaded 1.4.8.1 and recompiled. Then I read the MIGRATION text, which mentions a script enforcer/utils/migrate_1_4_8.sqlite3, but I can't find this script. There are several other migration scripts in enforcer/utils, but the ones for 1.4.8 I can't find. ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] Re: Zone stuck, not updating
We have 12 zones and we see this situation a few times per week. We have developed a cron script which compares the serial of the unsigned DNS server with the serial in the /var/opendns/tmp/zone.xfrd-state file. If a mismatch is detected, the work-around is to stop OpenDNSSEC, delete this file and restart OpenDNSSEC again. A similar problem occurs sometimes if the unsigned zone is not changed for some weeks. OpenDNSSEC then does not update its state anymore. Then, after some days the zone expires and no outgoing zone transfers are possible anymore. This case is more difficult to detect before the expiration of the zone. The work-around is similar. Havard Eidnes schreef in bericht news:20141023.221714.213271382...@uninett.no... Hi, I'm using DNS zone transfers in and out of OpenDNSSEC with OpenDNSSEC version 1.4.6. It looks like one of the zones have become wedged, and OpenDNSSEC refuses to transfer a new copy, despite a new SOA being announced via DNS notify. ods-signerd logs: timestamp+host ods-signerd: [query] ignore notify from a.b.c.d: zone xxx.yyy.no transfer in progress What makes it think it's currently transferring the zone, and is there something I can do to clear that state? I've done a full restart of OpenDNSSEC via ods-control stop and ods-control start, to no avail. ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] Re: XFR debugging (was: Notify debugging)
Fred Zwarts, KVI, Groningen schreef in bericht news:42037E788A9B4313B3545379EA96110F@Lenovo... Now there is a similar, though slightly different problem with another zone kvi-cart.rug.nl. The signer responded with servfail when requested for the SOA record, or for zone transfers for this zone. In the systlog, there where a log of messages like: May 16 20:32:42 dns ods-signerd: [axfr] zone kvi-cart.rug.nl expired at 1400245434, and it is now 1400265162: not serving soa May 16 20:32:42 dns ods-signerd: [axfr] zone kvi-cart.rug.nl expired at 1400245434, and it is now 1400265162: not serving soa May 16 20:32:42 dns ods-signerd: [axfr] zone kvi-cart.rug.nl expired at 1400245434, and it is now 1400265162: not serving soa May 16 20:32:43 dns ods-signerd: [axfr] zone kvi-cart.rug.nl expired at 1400245434, and it is now 1400265163: not serving soa May 16 20:32:43 dns ods-signerd: [axfr] zone kvi-cart.rug.nl expired at 1400245434, and it is now 1400265163: not serving soa May 16 20:32:43 dns ods-signerd: [axfr] zone kvi-cart.rug.nl expired at 1400245434, and it is now 1400265163: not serving soa Apparently, also for this zone the transfers of the unsigned zone where not processed correctly, but we did not notice it until the zone expired. So, I used the same work-around and now the zone is served correctly. I have the impression, that something is wrong with the processing of the incoming zone transfers and I would like to know what I can do to further diagnose this problem, before yet another zone will pop up with a similar problem. Fred.Zwarts. -Oorspronkelijk bericht- From: Rick van Rein Sent: Thursday, May 15, 2014 10:43 PM To: Fred.Zwarts Cc: opendnssec-user@lists.opendnssec.org Subject: Re: [Opendnssec-user] Notify debugging Hi Fred, The /var/opendnssec/tmp/rug.nl-xfrd-state file still shows the old soa serial 2014051506, where the unsigned system is already at 2014051520. To me it looks as if opendnssec receives the zone, but does not process it. Any other ideas to diagnose this problem? Can you have a look at /var/opendnssec/unsigned/rug.nl* ? If the zone changes arrive (I assume the mutliple arrivals are due to zone updates, each resulting in a NOTIFY) then you should find it there, probably as rug.nl.axfr. That should help you distinguish if it is a transport problem or a signer-trigger problem. You can manually trigger resigning to see if it is a matter of the new arrival not triggering the signer properly, with ods-signer sign rug.nl -Rick In the mean time we upgraded to opendnssec-1.4.6. The last few days I had again problems with zone transfers for several zones. The first symptom is that the signer gives a SERVFAIL error when requested for the SOA record of the (signed) zone. In the log files I see messages like: Sep 24 09:40:53 dns ods-signerd: [axfr] zone erdg.usor.nl expired at 1411534059, and it is now 1411544453: not serving soa Sep 24 09:41:03 dns ods-signerd: [axfr] zone erdg.usor.nl expired at 1411534059, and it is now 1411544463: not serving soa Sep 24 09:41:03 dns ods-signerd: [axfr] zone erdg.usor.nl expired, not transferring zone Sep 24 09:41:13 dns ods-signerd: [axfr] zone erdg.usor.nl expired, not transferring zone Sep 24 09:41:13 dns ods-signerd: [axfr] zone erdg.usor.nl expired at 1411534059, and it is now 1411544473: not serving soa The signer, in turn, gets these zones (unsigned) from another system. When I log in on the opendnssec system, there is no problem to get these zones from this other systems with e.g., dig. The unsigned zone has not been changed for several weeks. In other cases, where the unsigned zones are updates more frequently, we some times notice that updates are not processed bu opendnssec. It looks as if for some reason, opendnssec stops to refresh the zones. As I learned in May, the work around is to stop opendnssec, delete the files associated with the zone in /var/opendnssec/tmp and start opendnssec. I have automated this work-around in a cron job, but I would, of course, prefer to have a real solution for this problem. My question is whether version 1.4.6 has more logging options to diagnose why it stop doing zone transfers to refresh the zones. ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] Notify debugging
We use adapters in addns.xml to receive the unsigned zones via zone transfers. This worked well. An update of the zone on the source server was received and processed by opendnssec in a few seconds. Recently I installed ods 1.4.5. I now have the impression that a notify from the source system is not received by opendnssec any more. In the logs of the source system, I see that a notify is sent, but opendnssec does not read the new zone with a zone transfer. I have two questions: 1) In the log files notify messages are not mentioned at all. The logging verbosity in config.xml is set to 3. Is there a verbosity that will show logging of incoming notify messages for further diagnostics? 2) Is there a way to force opendnssec to read the new zone with a zone transfer? BTW, in the log files I see for many zones messages like : May 15 09:58:09 dns ods-signerd: [axfr] axfr fallback zone erdg.usor.nl May 15 09:58:09 dns ods-signerd: [axfr] zone erdg.usor.nl journal not found for serial 2014051501 May 15 09:58:09 dns ods-signerd: [axfr] axfr fallback zone erdg.usor.nl In an attempt to force a zone transfer, I restarted both the enforcer and the signer daemons. For some zones I see in the log file messages like: May 15 12:11:48 dns ods-signerd: [backup] bad ixfr journal: trailing RRs after final SOA May 15 12:11:51 dns ods-signerd: [zone] corrupted journal file zone erdg.usor.nl, skipping (General error) Is this normal? If not, should I do something to fix it, or is it fixed automatically? (Note, this i not the zone that has a problem with the notify, but I mention it, because it could indicate a more general problem.) ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] Re: Key NOT ALLOCATED
Hi Sara, Thanks for the fast response. This may explain it. We use shared keys and this key is used indeed for other zones. Is there is simple way to exclude the unallocated keys and get the old listing behaviour? (I now use | grep -v NOT ALLOCATED. This incompatible change broke one of my scripts, so I used this work-around to fix it, but I wonder whether there are other cases that may pop up later.) Fred.Zwarts. Hi Fred, An extension was made to the ‘key list’ command in 1.4.4 based on a number of user requests (from the release notes): * OPENDNSSEC-358: ods-ksmutil: Extend 'key list' command with options to filter on key type and state. This allows keys in the GENERATE and DEAD state to be output. and the new syntax is described here: https://wiki.opendnssec.org/display/DOCS/ods-ksmutil#ods-ksmutil-Command:keylist One side effect of this is that additional keys may now also be listed in the default output because the results are no longer limited to only those keys that are allocated to zones. The NOT ALLOCATED text was added for such cases and would typically only be seen when viewing generated keys (for example, pre-generated keys are associated with a policy but are not allocated to zones until they are used). In your case I see that the keys have the same CKA_ID, which suggests they were used on a shared policy. They may have been allocated to zones that were later deleted (and the keys were not deleted because they were in use by other zones)? Sara. On 8 May 2014, at 09:17, Fred.Zwarts f.zwa...@kvi.nl wrote: I installed opendnssec 1.4.5 over an opendnssec 1.4.3 installation. Now when I use the ods-ksmutil key list --verbose command I see lines that I did not see with the previous version: NOT ALLOCATED KSK dsready When required (keypub) 20488 310a8e2e58cbafab7aa934e2a3fd8598 SoftHSM and NOT ALLOCATED KSK dssub waiting for ds-seen (dspub)20488 310a8e2e58cbafab7aa934e2a3fd8598 SoftHSM The words NOT ALLOCATED are seen where normally the domain name appears. I assume that NOT ALLOCATED means that it is not allocated for a domain. I don't understand how a key that is not allocated for a domain can be in the state dsready, or dssub. Can somebody explain this? ___ Opendnssec-user mailing list mailto:Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] Transition time in the past.
We are running ODS 1.4.3 for some weeks now. We have some zones for which we use policies with shared keys. It has been running well. I have seen a few zones that performed a ZSK roll-over at the wschedules times. But now I discovered a zone for which the active ZSK has a transition time a few days in the past. It looks as if it did not roll over in time. Each night, ODS is stopped in order to make a consistent backup of its state and started afterwards again with ods-control stop/start, resp., but this does not trigger a roll-over for transition times in the past. Is there a good explanation for this behaviour, or is it a bug? ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
[Opendnssec-user] Re: Transition time in the past.
Hi Sion, Thanks for the fast reaction. ods-ksmutil key list --verbose shows the following for the zone: erdg.usor.nlKSK dsready When required (keypub) 20488 67f63f125f0bdecc4d944d63acbc02b6 SoftHSM 29011 erdg.usor.nlKSK active2014-12-17 09:33:44 (retire) 20488 de3caeee0bb69f71f028c360029f328e SoftHSM 54566 erdg.usor.nlZSK active2014-03-19 16:24:03 (retire) 10248 1c3824bbf4435bc34878845cc44f8194 SoftHSM 39801 erdg.usor.nlZSK ready next rollover (active) 10248 97a9eb2b25236af4bb0e1ee998e0131d SoftHSM 37948 In the log file I see messages like: Mar 25 02:00:05 dns ods-enforcerd: Not enough keys to satisfy zsk policy for zone: erdg.usor.nl I can generate keys manually, but shouldn't these keys be generated automatically, if needed? Could it be that other zones with the same (shared keys) policy were created later and are not yet at there roll-over time? Thanks for any advise. Siôn Lloyd schreef in bericht news:5331818c.6010...@nominet.org.uk... On 25/03/14 13:06, Fred.Zwarts. wrote: We are running ODS 1.4.3 for some weeks now. We have some zones for which we use policies with shared keys. It has been running well. I have seen a few zones that performed a ZSK roll-over at the wschedules times. But now I discovered a zone for which the active ZSK has a transition time a few days in the past. It looks as if it did not roll over in time. Each night, ODS is stopped in order to make a consistent backup of its state and started afterwards again with ods-control stop/start, resp., but this does not trigger a roll-over for transition times in the past. Is there a good explanation for this behaviour, or is it a bug? Hi Fred, Is there a replacement key published in the zone? If so what state is it in? Are there any log messages to do with that zone that might give a clue as to what is happening? Stopping and starting the enforcer should be fine, assuming it starts back up properly of course (log messages should indicate if it failed to restart). Sion ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
