Re: [Opendnssec-user] hsm unable to get key

> freebsd 13.1 > opendnssec 2.1.10 > softhsm 1.3.8 > > things running happily for months. suddenly, i have logs full of > > Apr 9 21:22:12 rip ods-enforcerd[35513]: [hsm_key_factory_delete_key] > looking for keys to purge from HSM > Apr 9 21:22:15 rip ods-signerd[35519]: [hsm] unable

Re: [Opendnssec-user] OpenDNSSEC losing its marbles on restart?

Hi, and thanks for the follow-up. I'll just repond to one of the items for now: >> This is with OpenDNSSEC 2.1.8 and SoftHSM2 2.6.1. (I see I am >> a couple of versions behind the curent OpenDNSSEC.) > > Which distribution are you on? I am moving to add binary packaged > to some

[Opendnssec-user] OpenDNSSEC losing its marbles on restart?

Hi, I had occasion to do a base OS upgrade on my long-running OpenDNSSEC signer host. This was a minor kernel version upgrade, so should be uneventful. For the OS itself, that turned out to be true, but for OpenDNSSEC, "not so much": Jun 11 12:24:34 signer-host ods-signerd: [zone] zone

Re: [Opendnssec-user] Unexpected DS state transition UNSUBMITTED to SUBMITTED (v 2.1.5)

> It is not clear when one should execute 'ods-enforcer key ds-seen'. > Is that as soon as the DS record first appears in the parent zone? In my setup I use a small perl script which checks that all the publishing name servers for the parent zone respond with the newly published DS record before

Re: [Opendnssec-user] Unexpected DS state transition UNSUBMITTED to SUBMITTED (v 2.1.5)

> Based on what I read at the Key States Explained page of the > wiki, I expected to see an intermediate SUBMIT state where I > would then tell the enforcer that it has been submitted (but > not yet seen). I think I've muttered here before that the required operator interactions with OpenDNSSEC

Re: [Opendnssec-user] Changing policy for some domains

>> I'm now one week later looking at the state of the keys with >> ods-enforcer, and while the new KSK is generated and sits in the >> zone, it doesn't look like OpenDNSSEC is doing a KSK roll-over to >> complete the algorithm roll-over. Is it waiting for the normal >> roll-over time to come for

Re: [Opendnssec-user] Changing policy for some domains

>> Relevant commands: >> vi kasp.xml >> ods-enforcer policy import >> ods-enforcer zone set-policy -z example.com -p newpolicy >> ods-enforcer enforce -z example.com >> >> One caveat to think of, I probably wouldn't use this on >> combined signing keys (CSKs). >> >> If possible test this

Re: [Opendnssec-user] Changing policy for some domains

> What should work, but haven't a test-case for it, is to use the > contributed set-policy from the enforcer. Create a new policy > in your kasp.xml with all the same parameters, except from the > new algorithm. Then (re)import the policy. Then one be one > move zones to the new policy. You

Re: [Opendnssec-user] Error converting from 1.4.14 to 2.1.8

>> Does anyone successfully run OpenDNSSEC 2.x with SoftHSM 2.x >> while using sqlite3 as the SoftHSM backend and with a >> WorkerThreads setting in OpenDNSSEC larger than 1? > > Hi Håvard, > > We're one of them. ~80 domains under FreeBSD 12.2-RELEASE: > > opendnssec2-2.1.7 >

[Opendnssec-user] ods-enforcer key ds-submit & ds-retract?

Hi, the man page for ods-enforcer contains among other things: key ds-submit --zone (--keytag | --cka_id ) Issue a ds-submit to the enforcer for a KSK. key ds-seen --zone (--keytag | --cka_id ) Issue a ds-seen to the enforcer for a KSK. key

[Opendnssec-user] Suggestion for migration instructions

Hi, referring to https://www.opendnssec.org/migration-from-1-4-to-2-1/ I would like to make the following suggestion. 7. Migration during a key roll (i.e. keys in state publish) especially KSK, will involve assumptions in the migration, so if possible perform the migration outside

Re: [Opendnssec-user] Error converting from 1.4.14 to 2.1.8

Hm, no answer/follow-up? Perhaps I need to ask shorter and not ramble...: Does anyone successfully run OpenDNSSEC 2.x with SoftHSM 2.x while using sqlite3 as the SoftHSM backend and with a WorkerThreads setting in OpenDNSSEC larger than 1? Best regards, - Håvard

Re: [Opendnssec-user] Error converting from 1.4.14 to 2.1.8

Hi, following up to my own message: ... > However... I did find a point of correlation: if I try to run > with the Signer's WorkerThreads set to 4, it fails as above. If > I set it to 1, lo and behold, it works just fine: ... > Do note, we are currently using sqlite3 for the SoftHSM2 >

Re: [Opendnssec-user] Error converting from 1.4.14 to 2.1.8

> 2) We seem to have issues related to SoftHSM2, which we're > converting to at the same time. The problem we're having is that > the level of error messages related to SoftHSM2 is nearly binary: > either it works or it doesn't, and not a word about "why" when it > doesn't. As an operator this

Re: [Opendnssec-user] Error converting from 1.4.14 to 2.1.8

>> I've done the conversion from 1.4.14 to an earlier 2.1.x version >> on another host (which worked at the time), but have come to the >> realization that the test installation needs to be re-done in an >> attempt to re-create the issues we ran across last night. For >> some reason I do not

Re: [Opendnssec-user] Error converting from 1.4.14 to 2.1.8

The good and bad news is that we've now re-created the problem on our test signer: Mar 5 18:30:57 test-signer ods-signerd: [zone] unable to publish keys for zone 0.2.6.2.3.2.7.4.nrenum.net: error creating libhsm context Mar 5 18:30:57 test-signer ods-signerd: [tools] unable to read zone

Re: [Opendnssec-user] Error converting from 1.4.14 to 2.1.8

Hi, more follow-up, this one is a minor buglet. The sqlite3 conversion script contains -- We need the following mapping 1.4 -> 2.0 for denialType -- 0 -> 1 -- 3 -> 0 UPDATE policy SET denialType = ( SELECT (CASE value WHEN 0 THEN 0 WHEN 1 THEN 0 WHEN 3 THEN 1 ELSE 1 END) FROM

Re: [Opendnssec-user] Error converting from 1.4.14 to 2.1.8

>>> 1) We're using for denial-of-existence. NSEC3 uses a >>> "salt" value as an input value to the process. If we move away >>> the old /var/opendnssec/signconf/ directory and create it anew, >>> OpenDNSSEC will populate it with an xml file per zone. However, >>> they all have this part: >>>

Re: [Opendnssec-user] Error converting from 1.4.14 to 2.1.8

> On Fri, Mar 05, 2021 at 12:58:16AM +0100, Havard Eidnes via Opendnssec-user > wrote: >> 1) We're using for denial-of-existence. NSEC3 uses a >> "salt" value as an input value to the process. If we move away >> the old /var/opendnssec/signconf/ directory

[Opendnssec-user] Error converting from 1.4.14 to 2.1.8

Hi, we have now made our second failed attempt at converting our production OpenDNSSEC 1.4.14 installation to 2.1.8. So far we have found one specific problem and one more vague problem: 1) We're using for denial-of-existence. NSEC3 uses a "salt" value as an input value to the process. If

Re: [Opendnssec-user] Restarting 2.1.6 after long semi-idle...

> I think this issue might have been fixed already in 2.1.7, either > as issue "Crash on OpenBSD systems in ixfr_del_rr" (SUPPORT-260) > or possibly in a fix that appeared in the 2.1.8 release candidate 1. > I think in the 2.1.7 becasue of the exact location, but the other > issue refers

Re: [Opendnssec-user] Restarting 2.1.6 after long semi-idle...

>> Yesterday a new RC has been released [1] which fixes a signer crash. You >> could try to use that version to see if it stays alive. >> >> [1] >> https://lists.opendnssec.org/pipermail/opendnssec-user/2021-February/004574.html > > Thanks! I have now installed this one and restarted OpenDNSSEC,

Re: [Opendnssec-user] Restarting 2.1.6 after long semi-idle...

>> it looks like I'll have to follow up on this one, sadly. I left >> ods-signerd running overnight, and when I came to attend to it in >> the morning it had crashed at exactly the same spot. I found the >> zone file it was working on at that time and moved it away >> (forcing a re-transfer),

Re: [Opendnssec-user] Restarting 2.1.6 after long semi-idle...

Hm, it looks like I'll have to follow up on this one, sadly. I left ods-signerd running overnight, and when I came to attend to it in the morning it had crashed at exactly the same spot. I found the zone file it was working on at that time and moved it away (forcing a re-transfer), but there

[Opendnssec-user] Restarting 2.1.6 after long semi-idle...

Hi, I'm finally gearing up to transition my local OpenDNSSEC + SoftHSM over to "supported" versions (2.x all around). Quite a while back I set up a test system to perform the migration on, and left it running. Apparently ods-signerd had stopped or crashed and I didn't notice (the enforcer

Re: [Opendnssec-user] (no subject)

> Sep 22 00:42:21 rip ods-enforcerd[87403]: [enforcer] updateZone Ready for > transition but key material not backed up yet > (5b5ac7ce18f5d7e30f3520ee8bbfa840) > ... > so i google around and find > > rip.psg.com:# ods-ksmutil backup prepare > -bash: ods-ksmutil: command not

Re: [Opendnssec-user] KSK stuck in "retire" state

Hi, a while earlier I reported: > we're still running OpenDNSSEC 1.4.14 for our operational signer > host. This works mostly OK, but recently one of our KSKs appear > to have become stuck in the "retire" state: > > ods @ signer: {1} ods-ksmutil key list | grep KSK | grep -v active >

[Opendnssec-user] KSK stuck in "retire" state

Hi, we're still running OpenDNSSEC 1.4.14 for our operational signer host. This works mostly OK, but recently one of our KSKs appear to have become stuck in the "retire" state: ods @ signer: {1} ods-ksmutil key list | grep KSK | grep -v active mail.uninett.no KSK

Re: [Opendnssec-user] ODS 2.14, double signatures during ZSK rollover

Hi, picking up on an "inner" comment from earlier in the discussion: >> On 15/01/2020 08.49, Erik P. Ostlyngen via Opendnssec-user wrote: >>> On 14/01/2020 10.00, Berry A.W. van Halderen via Opendnssec-user >>> wrote: Dear Erik, It will also depend on the TTL of your keyset. The

[Opendnssec-user] TSIG Notify: Migrating from 1.x to 2.x

Hi, I promise, a single-issue message this time... :) One thing which tripped me up in my upgrade, using DNS/IXFR/AXFR both inbound and outbound from OpenDNSSEC, and using TSIG both for IXFR/AXFR/NOTIFY from the upstream name server: While OpenDNSSEC 1.4.x in the "addns.xml" file could have

Re: [Opendnssec-user] Key and DS states

Hm, my questions went unanswered? That's slightly disappointing... Here's a new and different formulation. I apologize for the length and the inclusion of multiple issues in the same e-mail message -- I don't appear to have become good friends with OpenDNSSEC 2.x yet... The scripts I

[Opendnssec-user] Key and DS states

Hi, I'm continuing on my path to transition to OpenDNSSEC 2.x, and naturally the question of the documentation for the Key and DS states come up. This was brought up already by Casper Gielen in https://lists.opendnssec.org/pipermail/opendnssec-user/2017-October/004117.html and I agree with

Re: [Opendnssec-user] Migrating from SoftHSM1 to 2

...and a related question: With SoftHSM 1.x and OpenDNSSEC 1.x, we were given a recipe to perform backup of the SoftHSM database periodically. As I understood it, OpenDNSSEC could be configured to "require backup" before using a KSK, and we have our 1.x configured with . My upgrade notes to

Re: [Opendnssec-user] TTL values through to signed zone?

> Hm. Need to look at the source, I think. ...and the log: Dec 3 22:16:20 signer-host ods-signerd: In zone file eduvpn.uninett.no: TTL for the record 'vpn.eduvpn.uninett.no. 600 IN A 158.38.2.19' set to 86400 This comes from zone_add_rr() in signer/zone.c: ... } else {

Re: [Opendnssec-user] TTL values through to signed zone?

> In /etc/opendnssec/kasp.xml, do you have a... > > PT86400S > > ...inside your context? The context there says in my case: PT900S PT3600S PT900S datecounter which is quite similar to what's specified in the "Zone information" section in

[Opendnssec-user] TTL values through to signed zone?

Hi, with OpenDNSSEC 1.4.14, with zone transfers in + out, we've tried to publish an RRset with a relatively short TTL: % dig @ vpn.eduvpn.uninett.no. a ... vpn.eduvpn.uninett.no. 600 IN A 158.38.4.11 vpn.eduvpn.uninett.no. 600 IN A 158.38.2.19 ... However, when

Re: [Opendnssec-user] Thanks

>>> server 127.0.0.1 { >>> keys { opendnssec-out; }; >>> edns no; >>> }; >> >> Oh, this is trying to mix "modern BIND" with OpenDNSSEC? >> >> This could then be an instance related to >> >> https://issues.opendnssec.org/browse/SUPPORT-242 >> >> which is OpenDNSSEC which fails to skip

Re: [Opendnssec-user] Thanks

> thanks for all the help, I finally got it working. My named wasn't > capable using tsig with edns in the default view. > Adding the following in the default view made it work: > > server 127.0.0.1 { > keys { opendnssec-out; }; > edns no; > }; > > Regards > Uli Oh, this is trying to

Re: [Opendnssec-user] New BIND: EDNS incompatibility with 1.4.x?

Following up on my own message (yes, I'll submit this also as a formal bug report) -- it looks like this patch fixes the issue; OpenDNSSEC wasn't "consuming" the entire EDNS OPT record, and the addition of the COOKIE option made the remaining part have non-zero length: ---

[Opendnssec-user] New BIND: EDNS incompatibility with 1.4.x?

Hi, I recently upgraded our downstream name server of our OpenDNSSEC installation to BIND version 9.14.2, up from version 9.10.x-Py. With that upgrade, it looks like BIND and "dig" is no longer successfully talking to our OpenDNSSEC 1.4.x installation: sns:~> dig @ods-host -y

Re: [Opendnssec-user] Is KSK Lifetime 10Y too long to be accepted in OpenDNSSEC 2.1.3?

> Hope the information below sheds some light on the subject. Yes, thanks for taking the time to explain! I guess I'll just grudgingly for now have to accept that OpenDNSSEC 2.x is different from OpenDNSSEC 1.x on this particular point. Regards, - Håvard

Re: [Opendnssec-user] Is KSK Lifetime 10Y too long to be accepted in OpenDNSSEC 2.1.3?

>> That is almost exactly the same Keys config as I have >> in kasp.xml. Only differences are that my ZSK Lifetime >> is P90D and my ZSK Algorithm length is 1024. >> >> The strange thing is that my KSK keys only have 90 days >> until next transition from when they were created, as shown >> with

Re: [Opendnssec-user] SOA queries -> ServFail?

>> Doesn't OpenDNSSEC periodically query the upstream hidden master about >> its SOA version number, and update the "serial_xfr_acquired" timestamp >> after it has verified that no change in the SOA version number has >> occurred at the master? > > We just had a discussion about this. It seems

Re: [Opendnssec-user] SOA queries -> ServFail?

>> Turns out that this is in response to the SOA queries it issues: >> 14:49:39.571605 IP .42494 > .domain: 21758 [2au] SOA? >> 58.39.128.in-addr.arpa. (140) >> 14:49:39.572698 IP .domain > .42494: 21758 ServFail- 0/0/2 (140) >> >> Is this expected behaviour, i.e. are SOA queries

[Opendnssec-user] SOA queries -> ServFail?

Hi, I'm using DNS AXFR/IXFR to transfer zones out of my OpenDNSSEC installation. Today I had occasion to look a bit closer at what the downstream BIND was logging, and it logged all too frequently that OpenDNSSEC returned a "SERVFAIL" error response. Turns out that this is in response to the

[Opendnssec-user] Multiple input axfr/ixfr sources?

Hi, I'm going to ask a question I could possibly find myself if wiki.opendnssec.org was responding... Is it possible to configure OpenDNSSEC 1.4 to have multiple "upstream" DNS name servers? In other words, can addns.xml contain multiple entries under and multiple entries under ? Regards,

Re: [Opendnssec-user] Timing/triggers for ODS2 Enforcer's & ?

>> Is ODS enforcer polling for a specific trigger to fire each script? > > It decides based on its internal state. When a KSK is ready to be > submitted to the parent the script > will run. After that it waits for an external signal (ds-ssen). Given > by either the operator of a script. > >> Or

Re: [Opendnssec-user] CRITICAL: failed to sign zone example.com: General error

> This is opendnssec 1.4.12 and FreeBSD 11-STABLE. > > Today I found the following error message in my logs: > > | ods-signerd: [worker[4]] CRITICAL: failed to sign zone example.com: > | General error > > After removing all files in /usr/local/var/opendnssec/signconf and >

Re: [Opendnssec-user] NSEC3 resalting again

>>> it looks like the earlier problem I've had with a failure to remove >>> the old NSEC3PARAM resource records in a re-salt event is back again, >>> this time with OpenDNSSEC 1.4.10. >> >> We have been able to reproduce the problem today. The offending sequence >> of events is: >> >> - ods-signer

Re: [Opendnssec-user] ods2 AXFR request to nameserver fails , reports "bad packet: ... received error code NOTAUTH", but no traffic (tcpdump) seen ?

> ods2 > currently configured to listen on two interfaces > (I've also tried with just one ...), port 15354 Even though XML invites list operations, not every construct appear to be backed by handling in the code of a multi-valued / list value... But you say

Re: [Opendnssec-user] termination of obs2 DelegationSignerSubmitCommand input stream missing?

>>> In case the enforcer logged an error it should prepend it with >>> 'keystate_ds_x_cmd'. So please grep your logs for that. >> >> I've something amiss re state mgmt. >> >> at verbosity = 6, on exec >> >> /usr/local/opendnssec/sbin/ods-enforcer zone add -z example.info -p lab >> >> there's

Re: [Opendnssec-user] "not serving soa" warning message

> Thanks for the extensive report. I created an issue > https://issues.opendnssec.org/browse/OPENDNSSEC-853 which summarizes the > problem like this: > > serial_xfr_acquired time in the xfrd state file is not updated properly. > This may cause an issue on restart if serial_xfr_acquired+expire <

[Opendnssec-user] "not serving soa" warning message

Hi, since I've had to restart OpenDNSSEC a few times lately due to the bug in the signer when a zone is removed, I've taken a look at the logs (I know, bad idea...), and I noticed a warning message from the axfr component in the signer saying "zone xxx expired at nnn, and it is now :

Re: [Opendnssec-user] 1.4.10: removing zones -> ods-signerd crash

>> Hmm, is this perhaps OPENDNSSEC-838, which is fixed in 1.4.12? If so, >> I need to get into gears upgrading... > > Yes, that seems highly likely. It has the same stacktrace produced by... > you. :D Heh! > The fix indeed ended up in the 1.4.12 release. This upgrade should be > fairly painless

Re: [Opendnssec-user] NSEC3 resalting again

>> it looks like the earlier problem I've had with a failure to remove >> the old NSEC3PARAM resource records in a re-salt event is back again, >> this time with OpenDNSSEC 1.4.10. > > We have been able to reproduce the problem today. The offending sequence > of events is: > > - ods-signer

[Opendnssec-user] NSEC3 resalting again

Hi, it looks like the earlier problem I've had with a failure to remove the old NSEC3PARAM resource records in a re-salt event is back again, this time with OpenDNSSEC 1.4.10. I'm seeing zones on my public master with 2 NSEC3PARAM resource records, the oldest one being published last, and this

[Opendnssec-user] ods-signerd 1.4.10 crash

Hi, I recently added and removed a few zones from our OpenDNSSEC setup, and this appears to have caused ods-signerd to crash: pid 1361 (ods-signerd), uid 1072: exited on signal 11 (core dumped) stack trace: Core was generated by `ods-signerd'. Program terminated with signal 11, Segmentation

Re: [Opendnssec-user] Sudden failure related to NSEC3, Re: Sudden failure related to NSEC3

>>> You are running 1.4.10 I presume? >> >> I'm actually running 1.4.9 with some fixes applied, some of them >> remnants from debugging earlier problems. In particular, the >> earlier fix which added zone_del_nsec3params() which came from >> your end is part of my running code. > > I think my

Re: [Opendnssec-user] Sudden failure related to NSEC3, Re: Sudden failure related to NSEC3

>> I took a copy of the tmp/ directory in OpenDNSSEC (and then >> removed the files there), and have a copy of the "bad" zones >> which came out at the other end if someone wants to take a look >> at it to possibly find out how this could happen. > > This sound bad, please send me as much you can

[Opendnssec-user] Sudden failure related to NSEC3

Hi, I just had the misfortune of experiencing OpenDNSSEC emit zones which were malformed related to NSEC3. I have a script which on our public distribution master (which is just downstream of OpenDNSSEC) which checks zones for DNSSEC consistency, and this evening it suddenly flagged this same

Re: [Opendnssec-user] NSEC3 failure?

>> ...and if I'm not terribly mistaken, the three zones which have been >> flagged in this way (yep, two more popped up) so far have all been >> added to our OpenDNSSEC setup after we upgraded to 1.4.9. > > I think there is a relation but no causation in this case. They are > probably added around

Re: [Opendnssec-user] NSEC3 failure?

>>> Does anyone have an idea what more needs to be done to zero in on >>> this problem? >> >> Hmm. My first guess would be that it involves a resalt. Your log lines >> seem to indicate that no new NSECS are being generated. Yet a resign >> solves the problem. Could you compare the NSEC3PARAM from

Re: [Opendnssec-user] NSEC3 failure?

>> Does anyone have an idea what more needs to be done to zero in on >> this problem? > > Hmm. My first guess would be that it involves a resalt. Your log lines > seem to indicate that no new NSECS are being generated. Yet a resign > solves the problem. Could you compare the NSEC3PARAM from the

Re: [Opendnssec-user] NSEC3 failure?

Hm, seems I need to follow up on my own posting, as I see that all the three "bad" zones have *two* NSEC3PARAM records: 255.39.128.in-addr.arpa. 0 IN NSEC3PARAM 1 0 5 45F39B9A60C14581 255.39.128.in-addr.arpa. 0 IN NSEC3PARAM 1 0 5 D9E0ED2449E3721D while the good one only has one:

Re: [Opendnssec-user] kaspConnect() causes ods-enforcer brittleness

> the ods-enforcer daemon loops, periodically looking for things > which need to be done / scheduled. Inside its service loop it > has this piece of code: > > log_msg(config, LOG_INFO, "Connecting to Database..."); > kaspConnect(config, ); > > followed by misleadingly-indented

Re: [Opendnssec-user] Error allocating ksks / zsks

> If key_pair_id = 0 is indeed invalid, I guess the database has gotten > into a state where OpenDNSSEC refuses to mend it automatically. > > Guidance sought. Listing all the keys with "ods-ksmutil key list --verbose --all" revealed: NOT ALLOCATED KSK generate (not

Re: [Opendnssec-user] Error allocating ksks / zsks

> a new occurrence of this problem has surfaced. > > Somehow my SoftHSM database had become owned by root (ouch!). While > that was done, a new zone was added. Of course key allocation failed > since the enforcer could not write to the SoftHSM database. > > However, the file ownership problem is

Re: [Opendnssec-user] Error allocating ksks / zsks

Hi, a new occurrence of this problem has surfaced. Somehow my SoftHSM database had become owned by root (ouch!). While that was done, a new zone was added. Of course key allocation failed since the enforcer could not write to the SoftHSM database. However, the file ownership problem is now

Re: [Opendnssec-user] Is there script for checking if DS is in TLD

>> Am 28.08.2014 um 10:29 schrieb Bas van den Dikkenberg >> >: >>> >>> Does anyone have script to check if the DS records are published at >>> the TLD, and if so do a ds-seen. >>> >>> I want to automate the ds-seen process And to add some

Re: [Opendnssec-user] 1.4.9: Zones not properly updating -- fallout from upgrade?

Hi, further on this problem, I took a closer look at the .ixfr file for this particular zone, comparing to the other bits and pieces: 1) .backup2 file contains ;;Zone: name korunikhum.no class 1 inbound 2015062912 internal 2016022600 outbound 2016022600 ; ... korunikhum.no. 3600IN

Re: [Opendnssec-user] Version 1.4.7 IXFR problems

> I noticed a problem with OpenDNSSEC 1.4.7 and IXFRs. Me too. I think I discussed this already under the slightly misleading subject "TTL clamped to minimum 3600". It turns out that only change of TTL does not flag those records for inclusion in an IXFR, and my last message on the subject of

Re: [Opendnssec-user] 1.4.9: Zones not properly updating -- fallout from upgrade?

...and to those wondering if this should not be reported as a bug, I've now taken the time to do that as well, https://issues.opendnssec.org/browse/SUPPORT-187 Regards, - Håvard ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org

[Opendnssec-user] SOA version number decremented!

Hi, on the 26th of February I upgraded our OpenDNSSEC installation from 1.4.7 + the right-before-Christmas patches to 1.4.9, since the patches have now been integrated. Thus, I needed to restart OpenDNSSEC. However, we're now experiencing a problem with one of our zones, norid.no, which we can

Re: [Opendnssec-user] Error allocating ksks / zsks

>> so I worried that the key in the "generate" state for the >> godegrep.no zone might mess things up (orphaned?), so it is now >> history: > > This removal of the apparently orphaned key in "generate" state > seems to have unwedged this one. [...] ... > ods @ hugin: {29} ods-ksmutil key list

Re: [Opendnssec-user] Error allocating ksks / zsks

> so I worried that the key in the "generate" state for the > godegrep.no zone might mess things up (orphaned?), so it is now > history: This removal of the apparently orphaned key in "generate" state seems to have unwedged this one. In the log I now found Feb 3 09:34:40 hugin ods-enforcerd:

Re: [Opendnssec-user] Error allocating ksks / zsks

For the other zone, the 2.1.2.6.1.9.3.7.7.4.nrenum.net zone, I tried another approach, namely I tried to initiate a manual key rollover for both the ZSK and the KSK: ods @ hugin: {22} ods-ksmutil key list --all --zone 2.1.2.6.1.9.3.7.7.4.nrenum.net Keys: Zone: Keytype:

Re: [Opendnssec-user] Error allocating ksks / zsks

> I also ran into this a couple of times. I "fixed" this by using the > "ods-ksmutil key generate" command. Hmm... I'm wary of doing that, since the problem doesn't appear to be that softhsm can't generate new keys (it does so just fine for all the other zones we have), so I don't understand

Re: [Opendnssec-user] Error allocating ksks / zsks

>> For now I made an issue in our tracker for it >> https://issues.opendnssec.org/browse/OPENDNSSEC-752 > > This happened to me today, but I traced it back to only having > 16MB free on my disk. Just for the record, that's not the situation at our end: /dev/sd0f 308G73G

Re: [Opendnssec-user] Error allocating ksks / zsks

> For now I made an issue in our tracker for it > https://issues.opendnssec.org/browse/OPENDNSSEC-752 Thanks again, - Håvard ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org

[Opendnssec-user] ods-signerd memory leak?

Hi, in conjunction with handling the "Error allocating ksks / zsks" messages I noticed that my ods-signerd process which had ran since ... right before Christmas had grown considerably in virtual size, causing me to restart my OpenDNSSEC installation. It seems that right after startup, my

Re: [Opendnssec-user] TTL clamped to minimum 3600?

> Does the CNAME record on disk (in the working directory) also have this > "fixed" TTL, or do you only see it when querying for the data? Both uninett.no.axfr and uninett.no.backup2 have correct entries for the CNAME I'm reproducing the problem with now. >From uninett.no.axfr: test.uninett.no.

Re: [Opendnssec-user] TTL clamped to minimum 3600?

> [...] So it looks like only a TTL change doesn't make the > record show up in IXFR (while it should), so the previous TTL > will stick around. ...and I'm wondering if this piece of code has something to do with the absence of the "only-ttl-changed" records in the IXFR: signer/zone.c's

Re: [Opendnssec-user] TTL clamped to minimum 3600?

Hm, > we have some users who tried to register a TTL for some > particular resource records which is quite a bit lower than 1 > hour. > > However, after the zone has been signed by OpenDNSSEC, the TTL is > set to 1 hour (exactly). I can't seem to find any information > that such clamping is

Re: [Opendnssec-user] Problems adding largish # of zones

Hi, this is just to notify that after the initial frustration I managed to create for myself by mis-applying the patch, my OpenDNSSEC installation has (knock on wood!) been stable and apparently well-behaved: it still responds properly to notify messages by transferring the zone, signing it and

Re: [Opendnssec-user] Problems adding largish # of zones

> On 12/23/2015 02:05 PM, Havard Eidnes wrote: >> spoke too soon again, found another cut+paste error of mine. >> We'll see how it fares how. > > Please let us know how you fare with the changes. Just to inform > you also that we haven't dropped the issue. Although our

Re: [Opendnssec-user] Problems adding largish # of zones

Bah, spoke too soon again, found another cut+paste error of mine. We'll see how it fares how. Regards, - Håvard ___ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user

Re: [Opendnssec-user] Problems adding largish # of zones

> So far the newly started pair of processes seem to be a lot > better behaved. It appears I spoke too soon. Today I awoke to data not flowing through OpenDNSSEC, and on inspection, it had stopped responding to notify messages. Even if i upped the logging level to 10 there was no "action"

Re: [Opendnssec-user] Problems adding largish # of zones

>> Notice develop (1.4.8+) has a slightly different database layout >> than 1.4.7. I'll work on a patch that applies on your version so >> you don't have to upgrade.. > > Fetch it from here. > > https://github.com/opendnssec/opendnssec/tree/1.4.7-tcp_queue_fix > > It has the patches applied on top

Re: [Opendnssec-user] Problems adding largish # of zones

Hi, I've modified the diff to xfrd_tcp_release() so that it doesn't decrease the available TCP sessions if the FD passed was already -1, as can happen e.g. if you exceed the number of allowable open FDs (bouncing into that is an error in itself, but this appears to help ... somewhat): if

Re: [Opendnssec-user] Problems adding largish # of zones

Hi, I think I found the culprit which ran me out of FDs. It was a cut+paste error of mine; I had left in code which caused two TCP sessions to be opened via xfrd_tcp_open() where I should only do one, at the end of xfrd_tcp_release()... So far the newly started pair of processes seem to be a

Re: [Opendnssec-user] The signer's expiry handling

>> my signer managed to hit the dreaded "soamin not set" assertion >> sometime yesterday. > > My analysis so far points to that this assertion is not caused by by > the state in tmp on disk. (Although something seems not quite right in > the *.ixfr files you send me. I'm looking at that

[Opendnssec-user] The signer's expiry handling

Hi, my signer managed to hit the dreaded "soamin not set" assertion sometime yesterday. Today I've applied this patch: The part->soamin assertion seems to trigger. Be helpful and log the zone name before the assert. --- signer/src/signer/ixfr.c.orig 2014-12-04 15:17:14.0 +

Re: [Opendnssec-user] Problems adding largish # of zones

Hi, I'll try to digest the rest of your message more properly, but this is just my initial feedback: > So to cut to the chase. Based on my testing, on short term your > troubles should go away by increasing the number of this define in > tcpset.h > > #define TCPSET_MAX 50 > > Make this something

Re: [Opendnssec-user] signer: "assertion part->soamin failed"

>> As I said, if any of you are interested in copies of the "bad" >> .ixfr files (and the presumed-good ones as well), I can send them >> privately. > > We've raised our priorities looking for these xfr related issues. I'd > like to see these files. Please send them over. Many thanks! I've sent

Re: [Opendnssec-user] signer: "assertion part->soamin failed"

>> Can someone familiar with this piece of code please explain what >> problem this assertion might indicate? The text in the log >> message itself isn't very descriptive. Looking at the code this >> appears to be related to use of IXFR, but I can't figure out the >> sequence of events which

[Opendnssec-user] signer: "assertion part->soamin failed"

Hi, we have recently been plagued by this particular assertion being triggered in the signer. The logged message is: Dec 11 15:13:52 x ods-signerd: signer/ixfr.c:230: part_print: assertion part->soamin failed When this is logged, that's the last we hear from ods-signerd, i.e. it exits.

[Opendnssec-user] kaspConnect() causes ods-enforcer brittleness

Hi, the ods-enforcer daemon loops, periodically looking for things which need to be done / scheduled. Inside its service loop it has this piece of code: log_msg(config, LOG_INFO, "Connecting to Database..."); kaspConnect(config, ); followed by misleadingly-indented code (that's

[Opendnssec-user] signer / softHSM issues?

Hi, it seems I'm still not on friendly terms with my OpenDNSSEC installation. A couple of notes: 1) It seems that ods-signer doesn't (anymore?) do zone transfers of its own initiative, only when prodded by notify messages. Can someone please tell me how ods-signer's incoming zone

[Opendnssec-user] Re: signer / softHSM issues?

> 2) It seems ods-signer can get into a state where one of its >threads is more or less busy-spinning consuming CPU. Attaching gdb to an apparently-spinng ods-signerd gives: hugin# gdb ./signer/src/ods-signerd GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License

Re: [Opendnssec-user] Problems adding largish # of zones

> Great work to track down the problems in this area, this gives us the > hints we need to take this issue up and reproduce the stuck zones on > XFRs. I can understand your state of mind because this indeed is not > easy to track down and takes up a lot of time to do so. > > We're next try to

  1   2   >