The OpenDNSSEC project announces the development of Open Source software that manages the security of domain names on the Internet. The project intends to drive adoption of Domain Name System Security Extensions (DNSSEC) to further enhance Internet security.

• More information about OpenDNSSEC
• List of authors
• OpenDNSSEC features
• Documentation
• Where to download OpenDNSSEC
• Where to get support

The latest news about OpenDNSSEC can be found below!

Version 1.3.5 of OpenDNSSEC has now been released.

• Auditor: Include the zone name in the log messages.
• ldns 1.6.12 is required for bugfixes.
• ods-ksmutil: Suppress database connection information when no -v flag is given.
• ods-enforcerd: Stop multiple instances of the enforcer running by checking for the pidfile at startup. If you want to run multiple instances then a different pidfile will need to be specified with the -P flag.
• ods-ksmutil: “zone delete” renames the signconf file; so that if the zone is put back the signer will not pick up the old file.
• Signer Engine: Verbosity can now be set via conf.xml, default is 3.

Bugfixes:

• Bugfix OPENDNSSEC-174: Configure the location for conf.xml with –config or -c when starting the signer.
• Bugfix OPENDNSSEC-192: Signer crashed on deleting NSEC3 for a domain that becomes opt-out.
• Bugfix OPENDNSSEC-193: Auditor crashed with certain empty non-terminals.
• Signer Engine: A file descriptor for sockets with value zero is allowed.
• Signer Engine: Only log messages about a full signing queue in debug mode.
• Signer Engine: Fix time issues, make sure that the internal serial does not wander off after a failed audit.
• Signer Engine: Upgrade ldns to avoid future problems on 32-bit platforms with extra long signature expiration dates. More information in separate announcement.

Download the tarball from: opendnssec-1.3.5.tar.gz

Version 1.3.1 of SoftHSM has now been released.

• The library is now installed in $libdir/softhsm/

Bugfixes:

• Do not give a warning about the schema version if the token  has not been initialized yet.
• The tools now return the correct exit code.

Download the tarball from: softhsm-1.3.1.tar.gz

During the end of last year, a bug was uncovered in the library ldns. The bug had an off-by-one error which caused some signatures to have the expiration date set to December 31 2012. 64-bit versions are unaffected.

Affected versions: ldns < 1.6.12 (32-bit)
Fixed versions: ldns >= 1.6.12 (32-bit)

Description:
The 32-bit version of ldns has code for converting days since epoch to the day of year. That code had a bug which handled the end of the year in the wrong way. The result of the bug was that some signatures got the intended validity period extended by a year. The signature will be reused by the Signer Engine until the key is rolled. However, the Enforcer is not aware that there exist signatures with such a long validity period. Any affected signature will thus have no post-publication of its corresponding DNSKEY, possibly resulting in validation failure. There is also the risk that the affected signature will be used in a replay attack.

Test for affected signatures:
The affected signatures can be spotted by reviewing your signed zone. E.g. by using the following command:
> grep “20121231[0-9]\{6\} 2011″ signed.zone.file

Remove the affected signatures:
If there are signatures in the zone with extra long validity periods, then it is recommended to recreate all of the signatures. This is done by clearing the internal storage of the Signer Engine. You then wait for the next scheduled re-sign, but you can also force an immediate re-sign (the second command below) to speed up the process:
> ods-signer clear <zone>
> ods-signer sign <zone>

Mitigate replay attacks:
Once the affected signatures are removed from the zone, it may also be advisable to roll your keys. If you have a non-static zone and are changing your zone data, then there is a chance for an attacker to replay old data since the signature is still valid. You need to assess the risk and possible cost of such an attack. If you need to mitigate such an attack, then you need to roll your keys. Rolling keys will invalidate any signatures that an attacker may have stored for later use. If the signature of the DNSKEY RRset was affected, then you also need to roll the KSK:
> ods-ksmutil key rollover –zone <zone> –keytype ZSK
> ods-ksmutil key rollover –zone <zone> –keytype KSK

Solution:
The issue has been fixed in ldns 1.6.12. You should upgrade ldns before the end of this year.