,
Yuri Schaeffer
[1] http://svn.opendnssec.org/tags/OpenDNSSEC-enforcer-ng-20111018/
[2]
http://svn.opendnssec.org/tags/OpenDNSSEC-enforcer-ng-20111018/README.enforcer_testers
--
Yuri Schaeffer
NLnet Labs
http://www.nlnetlabs.nl
___
Opendnssec-user
Not completely sure, but this looks like a valid patch:
--- util.c.patch2011-12-23 13:44:21.0 +0100
+++ util.c 2011-12-23 13:44:38.0 +0100
@@ -255,7 +255,7 @@
int year = 1970;
int new_year;
- while (days 0 || days = (int64_t)
I think this patch is correct. The confusion is that days represent
'days since' rather than 'day of year'
On second thought, I think the patch is not correct. Not only the day
will be off but also the year. My daughter does not give me opportunity
to think right now. But I suspect it is in
the zone file right now. Supporting
this is not trivial.
Regards,
Yuri
If such an option would exists, it should be a sane default as well,
so it would make sense to have the default policy configured like that
too...
--
Yuri Schaeffer
NLnet Labs
http://www.nlnetlabs.nl
safely
use the new DS. Your script _will_ break validation of your domain for
at least some resolvers.
Regards,
Yuri Schaeffer
[1] https://wiki.opendnssec.org/display/DOCS/Key+States
___
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
Hi Paul,
Are there any plans to change that to support failover/backup signers
that would not depend on a constant feed of db files?
In my opinion ODS is not a component that _must_ offer uninterrupted
service so failover does not really make sense to me. If your ODS
instance would crash and
Hi Paul,
If a large TLD gets a new registration, it needs to go out in minutes.
So a signer always needs to be ready to sign right now. Therefor, TLDs
or other large/dynamic zones will always need to have the option to
switch from one hardware setup to another (identical) one.
There is no
Hi Harald,
3. make check throws errors (Files e.g. TestFactoryRegistry.h nowhere to
be found in the sources)
I think you need to install libcppunit.
Thank you for testing! We really appreciate your feedback. 2.0a3 is a
bit out of date by now. In case you'd like to do some further testing
you
Woops, my reply did not make it to the list. Take 2:
As a side-effect, I have found another bug (I guess):
I have terminated ods-enforcer from the previous example with SIGINT
(Ctrl+C) because I was impatient and not willing to wait for 2190 new
ZSKs.
I suppose you pulled it from our Git
On 12-03-14 10:17, Petr Spacek wrote:
However, can AutomaticKeyGenerationPeriod explain the difference between
first and second zone add run with the same policy?
Default policy:
# ods-enforcer zone add --zone def1.test.
generating 1 KSKs of 2048 bits for policy 'default'.
generating 5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aug 31 20:30:47 mydns2 ods-enforcerd: pidfile
/var/run/opendnssec/enforcerd.pid already exists, a process with
pid 19382 is already running. If no ods-enforcerd process is
running, a previous instance didn't shutdown cleanly, please remove
this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01-09-14 10:57, Abdalmonem Tharwat Galila wrote:
I am afraid , I am already do that but nothing new.
So what says the log after you've done that?
//Yuri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In the same way that NSD has the AXFR flag to specify only to try
AXFR transfers... would it not be appropriate for OpenDNSSEC to
have something similar - so the logfile ends up with no failed IXFR
attempts?
How about having that log line look
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Petr,
there are results from code review which was done as part of our
code-import procedures. Opendnssec-1.4.6 was scanned with static
code analyzers and it uncovered couple interesting bugs (however I
don't see any security problem in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petr,
I fixed most of the issues and merged them in the 1.4 develop branch
on github. All memory leaks in ods-ksmutil are untouched. It is a
short lived program and I want to prevent make it /Farpotshket/.
//Yuri
On 05-10-14 23:03, Yuri Schaeffer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Havard,
-xfrd-soa.ttl = htonl(soa_ttl); +
xfrd-soa.ttl = soa_ttl;
Thanks for the analyses!
I suspect soa_ttl will fail now. xfrd.c:2100 contains
(unsigned) ntohl(xfrd-soa.ttl));
So that line needs to be in the patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jan-Piet,
When OpenDNSSEC creates a new KSK and publishes it in the zone, it
waits a period before asking an admin to confirm that the DS has
been seen in the parent zone (ds-seen).
Why does it do that, by which I mean, what's the waiting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Antti,
I don't see this as a strange approach. In many environments the
zone data is periodically transferred from a provisioning system
to OpenDNSSEC signer and then the signing process is triggered by
issuing ods-signer sign zone after
running every day that limit should never be reached.
Unfortunately I'm still missing something.
Thanks.
Emil
On Wed, Mar 18, 2015 at 12:34 PM, Yuri Schaeffer
y...@nlnetlabs.nl mailto:y...@nlnetlabs.nl wrote:
Hi Antti,
I don't see this as a strange approach. In many environments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Juan,
This is probably architecture related. We've had an earlier and
similar rapport from another Rpi user. It is on our todo list to port
the code to ARM. But admittedly not very high on said list.
Regards,
Yuri
On 11-06-15 12:48, Juan Orti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So would it be okay to change timing/ttl parameters in the policy
itself?
Well... You could do it but you need to be careful. It gets tricky
when you reduce a TTL in the KASP. Some resolvers may cache some
records too long (the old TTL), missing a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28-07-15 11:12, Sebastian Wiesinger wrote:
* Yuri Schaeffer y...@nlnetlabs.nl [2015-07-28 11:06]:
OpenDNSSEC pre-generates keys for later use. Likely a
formerly generated but unused key was still available.
But the keylist was empty
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Sebastian,
I had the zone running on the 'lab' policy and changed it to the
'default' policy. I *expected* that the zone would be reconfigured
to the new timers etc.
Switching policies is not supported. When you do, there is no
guarantee your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For the record, there was a stray non hex digit in the rdata. Which
ldns righfully refuses to parse.
//Yuri
On 06-08-15 14:13, Yuri Schaeffer wrote:
Hi Paul,
If you are able to share that record (perhaps including the line
before and after
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Håvard,
Thank you for your detailed rapport. Sorry to hear the aftermath of
this crash turned out to be so catastrophic. We'll look in to it.
Regards,
Yuri
On 10-07-15 16:12, Havard Eidnes wrote:
Hi,
we're running OpenDNSSEC 1.4.7.
Today
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Lukas,
> I couldn't find any information on this problem, so I've tried
> looking into it. Here is what I think is happening:
Thanks for your report and excellent description. I've opened a
issue[0] for it. It's on low priority right now, but we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Nagai,
On 08-10-15 08:14, GMO Internet Yuya Nagai wrote:
> In order to reproduce test, I set Denial->NSEC3->Resalt=PT900S in
> kasp.xml for updating it in short period. occurrence could be
> confirmed by an unspecified domain name each times.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Nagai,
On 08-10-15 08:14, GMO Internet Yuya Nagai wrote:
> I found a bug which inserts two NSEC3PARAM records in a signed
> zone. It happens in all OpenDNSSEC 1.4 versions.
>
> In order to reproduce test, I set Denial->NSEC3->Resalt=PT900S in
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I just find it odd that if I can do ‘ods-ksmutil backup …’ commands
> to generate a kasp.db.backup…that I can’t restore from that backup
> on the same server and/or a different server seamlessly.
I find it odd that if I can pull the tablecloth from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Fred,
> # 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
Ah, that is too bad. I've checked the need for migration scripts.
-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
-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
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Gaolei,
> According to RFC 5011 and RFC 7583, a KSK must be revoked before
> it is removed from the zone. It means that the corresponding DNSKEY
> RRSet should have the Revoked Bit set to '1'.
RFC5011 does state that. Though this is really only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14-12-15 11:33, Havard Eidnes wrote:
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Havard,
Admittedly I have not looked very good to this patch, I'm in my 'quiet
weeks'. But I do have my doubts about it. I think, from the top of my
head xfrd_tcp_release() is called for every TCP connection that it
tried to open. Regardless of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Havard,
I believe I have fixed the issue where zones are getting stuck when
adding/notifying more than ~50 zones. You will find it in the 1.4
development tree on github.
https://github.com/opendnssec/opendnssec/tree/1.4/develop
It appears the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> https://github.com/opendnssec/opendnssec/tree/1.4/develop
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..
//Yuri
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
> My initial reaction is that this will make OpenDNSSEC into the
> local network villain, and will create a "thundering herd" of TCP
> connections on startup, possibly overwhelming the upstream auth
> name server (which in our case also does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi gaolei,
> A key in 'retire' status seems to still being used to sign new RR.
> But the 'active' key was not used to generate signature of RR. Does
> it mean the OPENDNSSEC was working abnormally?
That indeed seems abnormal. My guess is that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Håvard,
For now I made an issue in our tracker for it
https://issues.opendnssec.org/browse/OPENDNSSEC-751
Regards,
Yuri
On 25-01-16 15:42, Havard Eidnes wrote:
> Hi,
>
> in conjunction with handling the "Error allocating ksks / zsks"
> messages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Håvard,
For now I made an issue in our tracker for it
https://issues.opendnssec.org/browse/OPENDNSSEC-752
Regards,
Yuri
On 25-01-16 15:35, Havard Eidnes wrote:
> Hi,
>
> I had reason to inspect the log from the physical console on our
> signer
Hi Dean,
> We use the opendnssec version is 1.4.7 .
> Yesterday I noticed that ods-signerd thread work unsteadiness in
> our test env , if run after 8 hours this thread will disappear ... and
> get system log as below :
We fixed a couple of bugs in the last few months regarding
> ...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 the
Hi Håvard,
> Apr 1 02:50:06 hugin ods-signerd: [STATS] 255.39.128.in-addr.arpa 2016040100
> RR[count=0 time=0(sec)] NSEC3[count=0 time=0(sec)] RRSIG[new=2 reused=237
> time=0(sec) avg=0(sig/sec)] TOTAL[time=0(sec)]
> Apr 1 04:50:07 hugin ods-signerd: [STATS] 255.39.128.in-addr.arpa
>> It's not a big deal, I could write a wrapper that takes a configuration
>> file and make the appropriate calls to ods-enforcer add/remove, but the
>> old system worked fine for me.
>
> It is still possible at the moment, but it is really a or-or situation.
> Or use the configuration file for
Hi Arun,
> I can see that "Date of next transition" for KSK is at 2016-05-04
> 09:47:36 to READY. Is it supposed to happen automatically? The state
> did not change until I stop and start ods-control.
Yes it will happen automatically. Though in OpenDNSSEC 1.4 the enforcer
daemon will run
Hi Dean,
On 18-04-16 08:35, yaohongyuan wrote:
> Last week we do some changes with source wire/notify.c:477 and
> have solved above problem , the change as below :
Thanks for your patch. We will take a look at it and if we agree with
you we'll merge it in. Meanwhile be advised that 0 is
> 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
Hi Fred,
> This morning I am confused again. I see the following:
> 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)
> The enforcer has scheduled a task in the past. How is that possible?
I'm
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
Dear community,
Hereby we announce the OpenDNSSEC 2.0.1 release. This release is
primarily focused on ironing out the issues on the migration path from
1.4 to 2.0. Besides that there are no functional changes.
Changes:
* Fixed crash and linking issue in ods-migrate.
* Fixed case where 2.0.0
Hi Wytze,
I found a couple of errors in the migration script. Causing confusion in
the enforcer about the role of a key (ksk/zsk). I would advice you to
run the migration again but since you are live that might not be feasible.
If you are adventurous we could try to patch your database? Assuming
Hi Volker,
Quite a bit of problems since 1.4.6 have surfaced regarding SOA serial
and XFR (bump-in-wire setups). We have worked very hard to resolve those
and the latest result of that is 1.4.10. Please consider upgrading, it
is very likely to fix whatever bug you are facing.
Your message
Hi Wytze,
> However, then the 2.0 migration instructions point me to
> enforcer/utils/1.4-2.0_db_convert/README.md. This instructs me
> to execute the convert_sqlite script. The script starts off with
> a reference SCHEMA=../../src/db/schema.sqlite, but that schema.sqlite
> file does not exist
Alternatively I prepared a new release which includes the files:
https://dist.opendnssec.org/source/opendnssec-2.0.0-1.tar.gz
Tonight I'll test it and make it an official release.
//Yuri
On 15-07-16 13:46, Yuri Schaeffer wrote:
> Hi Wytze,
>
>> However, then the 2.0 migration
Hi Wytze,
I'll try to answer as much as possible with what comes to mind. Further
analysis will have to wait a bit.
> Thanks for the quick response and all follow-up actions, including
> the new release. I managed to complete the upgrade (from 1.4.10 now)
> to 2.0.0-1, but things were not as
Hi Paul,
Yes it was released. I'm working on putting it up on www.opendnssec.org.
Everything should be sorted out during today.
//Yuri
On 07-07-16 10:40, Paul Wouters wrote:
>
> I was notified there is now opendnssec-2.0.0 but I have not seen any
> announcement of this yet?
>
> It seems to
Hi Havard,
> 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
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
> Reading
>
> https://www.opendnssec.org/documentation/using-opendnssec/
>
> "Configure the if you want to have a
> program/script receiving the new KSK during a key rollover. This will
> make it possible to create a fully automatic KSK rollover, where
> OpenDNSSEC feed your program/script on
Hi Marc,
> we have the ODS signer configured with multiple listener IPs.
>
> Now, when sending out the notify messages to the external auth server,
> once a zone has been (re)signed, we want those notifies to be sent
> out using a specific IP.
>
> According to
>
>
Hi Marc,
> As it is not an upcoming, but a missed rollover (as the "Date of next
> transition" has long passed), shouldn't it log the
> ods-enforcerd: WARNING: KSK Retirement reached
> message instead ??
It is not really a missed rollover. It merely hasn't happened yet. It is
waiting for
> IIUC there is no current "wait for ds-seen" mechanism or script hook in
> ODS 2.1.x, is there? I.e., needs to be done externally (cron job, etc)?
Yes. So a possible solution would be to have the
DelegationSignerSubmitCommand upload the DS and then initiate a cron job
that polls the parent on
> What are the trigger conditions / different usage for
>
> vs
>
> Are they both triggered automatically based on internal key state?
> Which, specifically? And what's relative timing?
These are fired automatically. Based in the internal state. specifically:
When a new key is
Hi,
On 22-02-17 19:59, PGNet Dev wrote:
> E.g., if @ an external observer, I identify a DNSKEY I want removed,
>
> dig DNSKEY example.com | grep 257
> example.com. 300 IN DNSKEY 257 3 14 YJ9...
> example.com. 300 IN
Hola Luciano,
I'm afraid I'm having difficulty parsing your question. I'll make an
educated guess what your question is.
> Hi, this is my first query, person if it is repeated. I would like to
> consult if any of you could change friendly unixtime
> by some command that increases the area on
Hi Michael,
Please check for the availability of the key in the hsm:
ods-hsmutil -c /etc/opendnssec/conf.xml list
It may have trouble finding one of the keys from your signconf:
0347526dbd7d57ff891f017c26a30846
a55ae0ef264253145c8f29c491829d29
Also make sure you pass the correct conf.xml file.
> After that I think we have exhausted all possible access permissions.
> And we are left with the puzzling question why the other domains
> aren't seeing the same issue. It would mean that just the generation
> of keys isn't working.
It could be that they simply haven't initiated a rollover yet
> I don't mean that, perhaps the policy has been changed such that now
> an algorithm or key length is being requested that isn't supported?
Ah. I wondered why you asked. :)
Yes, exactly that, an unsupported algorithm or keylength or a bad
combination of the two might spurr similar errors on
Hi Arun,
> Any idea, if it is possible to prompt for the softhsm pin when the
> enforcer starts?, instead of hardcoding the pin on conf.xml.
https://wiki.opendnssec.org/display/DOCS/Running+OpenDNSSEC#RunningOpenDNSSEC-HSMlogin
You could script something to get what you want.
//Yuri
> Any additional news on this? Is there perhaps now a patch I can
> apply on top of 1.4.12?
Yes, you could apply this [1] commit; Though I recommend checking out
the 1.4/develop branch for a couple of other fixes as well. I'll suggest
in the team whether it is maybe a good time to do a 1.4
Dear community,
As of now OpenDNSSEC 2.0.4 is released. This version is a minimal change
over 2.0.3, fixing a reported crash of the Enforcer daemon. No
additional migration steps are required. In the near future, we aim at
the end of January, we are planning to release the next feature version
Please note that Michael is running 1.4 which has an entirely different
enforcer than 2.0. It is clear now that the signer can't sign the zone
because you removed the signconf. And the enforcer isn't generating a
signconf because it is stuck generating a new key.
It is hard to imagine anything
> dns|root> ods-hsmutil -v test SoftHSM
Hmm this shows that generating new keys is not a problem perse. Can you
send me your kasp.xml?
> Segmentation fault (core dumped) Hmmm!? What does that mean? I guess
> I should be worried.
A crash in ods-hsmutil. It should have created a coredump file.
Hi Emil
> ERROR 1062 (23000) at line 474: Duplicate entry '81' for key 'PRIMARY'
As Berry said, it has to to with the shared keys option. The fix is
pretty straight forward. I think a DISTINCT keyword in the right place
solves the issue. However with your database in hand I came across
multiple
Hi Emil,
> Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
> the empty non-terminal is only derived from an insecure delegation
> covered by an Opt-Out NSEC3 RR.
>
> If I understand the above correctly, NSEC3 records should not be created
> for insecure
On 30-08-16 16:10, Mark Elkins wrote:
> Much to my annoyance, OpenDNSSEC converts to lower case the Left Hand
> side of all zones (the name part, before the TTL). Can this modification
> of data be switched off?
Agreed and the next release will have a fix for this.
Hi Ted,
> Is there some difference between the syntax rules for BIND and
> opendnssec? Any help would be greatly appreciated. I have not been able
> to find an answer in the documentation or via Google.
A TXT record can contain one or more character strings. Which applies to
your record at line
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
> 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.
> Yes, now supported. It has been called passthrough.
Indeed, also note this is distinct from
https://wiki.opendnssec.org/pages/viewpage.action?pageId=10125376#HowdoI...?-StopusingDNSSECforazone
Where the enforcer gracefully retracts all keys ans sigs. The signer
will strip all dnssec related
Hi Mark,
On 06-10-16 17:58, Mark Elkins wrote:
> Oct 6 17:45:01 signer1 ods-signerd: [namedb] zone za cannot keep SOA
> SERIAL from input zone (2016100627): previous output SOA SERIAL is
> 2016100627
> Oct 6 17:45:01 signer1 ods-signerd: [zone] unable to update zone za soa
> serial: Conflict
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,
Hi Simon,
> I am working with DNSSEC 2.0.1 and have the problem that
>
> ods-signer sign --all
>
> does not schedule immediate resigning of all zones but does so only with
> a delay of 10 min. In the previous version 1.4 I was using this happened
> immediately.
There should be no
> 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?
Oh yes sorry, I replied to the wrong thread.
>
>
> Could it be that this problem was also caused by a migration 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.
Hi Fred,
We are currently in the process of finding out why the retired ZSK after
the migration gets unpublished to fast. It seems an issue in the
migration script. Working on it.
This issue seems unrelated. Judging from the output the old ZSK DNSKEY
is still being published in the DNSKEY set.
> 1) A bug in the enforcer where it outputs the wrong signconf. Please
> check the entry for the 63b58e329df2a6bfa09671425146b72d key in the
> signconf. it should have a element.
Oops. That should be a element for key
63b58e329df2a6bfa09671425146b72d.
The (meaning use it for signing as ZSK)
> So my understanding is that for the time being I’m going to have to run the
> following after adding or removing a zone.
> ods-enforcer loneliest export
>
> To avoid any foot-shootery?
Yes, you can do a 'zonelist export' to make sure the zonelist.xml
contains all configured zones. BUT you
Hi Juan,
> We have compiled ods (at version 1.4.10) on a RHEL7 and added some numb
> zones for testing but ods-signerd is crashing:
>
> Sep 16 12:49:38 plat ods-signerd: ObjectFile.cpp(122): The attribute
> does not exist: 0x0002
> Sep 16 12:49:38 plat kernel: ods-signerd[12271]: segfault at
On 26-09-16 18:43, David Peall wrote:
> OpenDNSSEC shooting its own DB seems to be a rather drastic bug, what is
> the timeline on a fix for this?
I am going to guess you added your zones via the command line interface
and proceeded later with a 'ods-enforcer update all'. Which indeed
deletes all
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
Hi Havard,
> 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
The fix indeed ended up in the 1.4.12 release. This upgrade should be
fairly painless so
> How can shorten the time of keystate generate to publish it's now 1 day .
You can lower in the KASP. Default it is 1 day. The pace of
ZSK rollovers is mostly dictated by the TTL of the records, but the
enforcer component does not access the actual zone data. MaxZoneTTL is
used to indicate the
> I'm experimenting with .signconf files for 2.0 using the
> flag, and while playing around I've also checked signconf.rng to see the
> syntax.
>
> Even with the flag for a zone, the syntax for .signconf
> files demands quite a bit of signing setup:
> - Signatures/*
> - Denial/NSEC3/Hash/* or
>> Yes. This concept doesn't exist in 2.0.
>
> For both KSK and ZSK? I had the impression that standby keys are still
> possibkle for ZSK. I used them in 2.0.1, but then the rollover failed
> badly. Has it been removed completely in 2.0.3?
Standby keys where never a thing in any 2.0 release. The
> Solved the problem i remove port number.
> Maybe I should be removed from documentation ?
Changed 'port' with 'Port' in 1.4 and 2.0 documentation.
//Yuri
signature.asc
Description: OpenPGP digital signature
___
Opendnssec-user mailing list
Hi Havard,
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 <
Hi Juan,
The conf.xml has a in the enforcer
section. If not specified it defaults to a year. If you use a policy
with a very short key lifetime, such as lab, you might want to set it
*much* lower.
https://wiki.opendnssec.org/display/DOCS20/conf.xml#conf.xml-Enforcer
Best regards,
Yuri
On
1 - 100 of 175 matches
Mail list logo
