Banu Blog

Lease version 1.99.12 has been released (tagged at 1.99.12.20260429174723.026e1fc40c). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Lease 1.99.12:

• RT1875: Add missing cocci files to dist
• RT1870: Fix configure.ac warnings
• RT1869: Update main copyrights to 2026

Some more development releases will be made from this branch until Lease 2.0 is ready to be branched. You can read about Lease branches and version numbering.

Loop version 1.99.12 has been released (tagged at 1.99.12.20260429174723.026e1fc40c). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.12:

• RT1898: Return EDE for unsupported message opcodes and unsupported message class
• RT1897: Use macros instead of option codes
• RT1866: Add named support for draft-ietf-dnsop-structured-dns-error and draft-muks-dns-filtering
• RT1876: Fix logging example in the Loop user manual
• RT1875: Add missing cocci files to dist
• RT1873: Update logging to include file and line numbers
• RT1871: Update Vulkan manager log messages
• RT1870: Fix configure.ac warnings
• RT1869: Update main copyrights to 2026
• RT1868: Rename macro
• RT1863: Update Vulkan related named.conf(5) manpage options; add more Vulkan manager logging

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

Border version 1.99.12 has been released (tagged at 1.99.12.20260429174723.026e1fc40c). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Border 1.99.12:

• RT1891: Fix first release date from 1.99 branch
• RT1879: Upgrade NPM dependency packages
• RT1875: Add missing cocci files to dist
• RT1870: Fix configure.ac warnings
• RT1869: Update main copyrights to 2026

Some more development releases will be made from this branch until Border 2.0 is ready to be branched. You can read about Border branches and version numbering.

Border version 1.99.11 has been released (tagged at 1.99.11.20260302081434.1cfd6e70ac). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Border 1.99.11:

• RT1857: Upgrade NPM dependency packages
• RT1837: Upgrade NPM dependency packages
• RT1842: Add libxcrypt to dependencies
• RT1840: Fix release notes text

Some more development releases will be made from this branch until Border 2.0 is ready to be branched. You can read about Border branches and version numbering.

Lease version 1.99.11 has been released (tagged at 1.99.11.20260302081434.1cfd6e70ac). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Lease 1.99.11:

• RT1840: Fix release notes text

Some more development releases will be made from this branch until Lease 2.0 is ready to be branched. You can read about Lease branches and version numbering.

Loop version 1.99.11 has been released (tagged at 1.99.11.20260302081434.1cfd6e70ac). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.11:

• RT1806: Add Vulkan manager thread to named and related named.conf(5) options
• RT1854: Refactor jumps in cache lookups
• RT1849: Fix segfault in dnsperf
• RT1840: Fix release notes text
• RT1838: Update RFC notes of RFC 9276
• RT1836: Fix incorrect buffer size in debit_log()

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

Loop version 1.99.10 has been released (tagged at 1.99.10.20260302081434.1cfd6e70ac). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.10:

• RT1826: Limit NSEC3 iterations per RFC 9276. The max-sec3-iterations named.conf(5) option was added to configure the limit, and it defaults to 10. dnssec-signzone(1) warns if a non-zero NSEC3 additional iterations value or a non-zero length NSEC3 salt is used when signing a zone.
• RT1831: Return EDE option when queries fail due to recursive clients going over quota. The Over Quota (32) INFO-CODE in the EDNS Extended DNS Errors option is returned.
• RT1827: Return EDE option when responses are truncated due to RRL. The Rate Limited (31) INFO-CODE in the EDNS Extended DNS Errors option is returned.
• RT1820: Fix check for max-rsa-exponent-size option
• RT1825: Add RFC notes section to the Loop user manual
• RT1811: Remove unnecessary assignment that causes Sphinx warning
• RT1709: Add RPZ intent config clause with values blocking/censoring/filtering; the Blocked (15), Censored (16), and Filtered (17) INFO-CODEs in the EDNS Extended DNS Errors option are returned depending on the configured intent of the RPZ zone.
• RT1820: Limit max RSA public exponent bits size to a default of 64; values up to 256 are allowed.
• RT1820: Further limit RSA public exponent to 64 bits
• RT1720: Return EDE option for SERVFAIL if a zone is not ready to be queried. The Not Ready (14) INFO-CODE is returned if the zone data has not been loaded. The Invalid Data (24) INFO-CODE Is returned if the zone data is stale or missing.
• RT1819: Fix Debian package homepage URLs
• RT1780: Return the Not Authoritative (20) INFO-CODE in the EDNS Extended DNS Errors option when the server is not authoritative for the zone

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

We wanted to merge a couple of large branches into this release, but there was insufficient time. We will likely break them up and merge them phase by phase in future releases.

Border version 1.99.10 has been released (tagged at 1.99.10.20260302081434.1cfd6e70ac). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Border 1.99.10:

• RT1819: Fix Debian package homepage URLs

Some more development releases will be made from this branch until Border 2.0 is ready to be branched. You can read about Border branches and version numbering.

Lease version 1.99.10 has been released (tagged at 1.99.10.20260302081434.1cfd6e70ac). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Lease 1.99.10:

• RT1819: Fix Debian package homepage URLs

Some more development releases will be made from this branch until Lease 2.0 is ready to be branched. You can read about Lease branches and version numbering.

Loop version 1.99.9 has been released (tagged at 1.99.9.20260214065406.a608344ce2). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.9:

• RT1812: Add Debian and Ubuntu to supported platforms
• RT1781: Fix .name TLD DNSSEC verification failure
• RT1801: Fix warning about possible thread name buffer overflow (pthread_setname_np())
• RT1777: Rename heap callback function types and args
• RT1774: Remove CYGWIN specific code
• RT1757: Rename *.orig files to *.template
• RT1755: Add Debian packaging
• RT1753: Add tsigreplay system test to dist
• RT1752: Add printing of tests that failed to loop-system-tests.sh
• RT1751: Fix the pkcs11 system test
• RT1750: Set exit status when running loop-system-tests.sh
• RT1746: Fix user creation in RPM spec file for new RPM versions
• RT1743: Disable parallel make in docs directories when using Sphinx
• RT1740: Update list of supported platforms
• RT1739: Switch from ans.pl to ans.py
• RT1738: Use standard C integer types
• RT1718: Change the word chapter to section

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

We now use restructured build infrastructure to build Loop, Lease, and Border packages. We are able to build and test for many more platforms now, and the builds also complete faster. The RPM builders now run the entire system test suite against the binaries built for each RPM, so that the binaries that users install and use are exactly equal to the tested binaries.

We wanted to merge a couple of large branches into this release, but there was insufficient time. We will likely break them up and merge them phase by phase in future releases.

Lease version 1.99.9 has been released (tagged at 1.99.9.20260214065406.a608344ce2). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Lease 1.99.9:

• RT1812: Add Debian and Ubuntu to supported platforms
• RT1801: Fix warning about possible thread name buffer overflow (pthread_setname_np())
• RT1760: Remove socket interface code
• RT1760: Remove unused socket code
• RT1760: Remove raw socket implementation code
• RT1760: Remove log messages about HP JetAdmin software
• RT1760: Update text in manpage
• RT1760: Remove NIT code
• RT1760: Remove DLPI code
• RT1760: Remove UPF code
• RT1760: Move icmp.c function protos to icmp.h
• RT1760: Remove local version of inet_aton()
• RT1776: Use separate heap indexes for tracking active and inactive heaps
• RT1777: Rename heap callback function types and args
• RT1772: Refactor and port mdb6_unittest.c
• RT1775: Save and restore lease's heap index
• RT1774: Remove CYGWIN specific code
• RT1771: Refactor and port duid_unittest.c
• RT1770: Refactor and port leaseq_unittest.c
• RT1769: Refactor and port simple_unittest.c
• RT1768: Refactor and port load_bal_unittest.c
• RT1767: Refactor and port hash_unittest.c
• RT1766: Make libdhclient library
• RT1765: Make libdhcpd library
• RT1764: Refactor and port test_alloc.c
• RT1763: Refactor and port ns_name_test.c
• RT1762: Refactor and port misc_unittest.c
• RT1761: Refactor and port dns_unittest.c
• RT1760: Move ddns.c function protos to ddns.h
• RT1760: Move dns.c function protos to dns.h
• RT1760: Make repudiate_zone() statically scoped
• RT1760: Make dns_zone_lookup() statically scoped
• RT1760: Refactor dispatch()
• RT1760: Add include
• RT1760: Fix module name, etc.
• RT1760: Prefix lease to function names
• RT1760: Delete trailing whitespace
• RT1760: Fix old style function decl
• RT1760: Fix function args
• RT1760: Cleanup includes
• RT1760: Replace defines with enum
• RT1760: Delete trailing whitespace
• RT1760: Make variables static scoped
• RT1760: Fix no previous prototype compiler warnings
• RT1755: Add Debian packaging
• RT1746: Fix user creation in RPM spec file for new RPM versions
• RT1743: Disable parallel make in docs directories when using Sphinx
• RT1742: Add installation.rst to EXTRA_DIST
• RT1740: Update list of supported platforms
• RT1738: Use standard C integer types
• RT1737: Move leasechain protos to leasechain.h
• RT1736: Remove unused resolv.c

Some more development releases will be made from this branch until Lease 2.0 is ready to be branched. You can read about Lease branches and version numbering.

Border version 1.99.9 has been released (tagged at 1.99.9.20260214065406.a608344ce2). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Border 1.99.9:

• RT1813: Upgrade NPM dependency packages
• RT1812: Add Debian and Ubuntu to supported platforms
• RT1801: Fix warning about possible thread name buffer overflow (pthread_setname_np())
• RT1799: Upgrade NPM dependency packages
• RT1791: Upgrade NPM dependency packages
• RT1755: Add Debian packaging
• RT1747: Upgrade NPM dependency packages
• RT1746: Fix user creation in RPM spec file for new RPM versions
• RT1743: Disable parallel make in docs directories when using Sphinx
• RT1740: Update list of supported platforms

Some more development releases will be made from this branch until Border 2.0 is ready to be branched. You can read about Border branches and version numbering.

Border version 1.99.8 has been released (tagged at 1.99.8.20251104005426.4e37e60402). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Border 1.99.8:

• RT1674: Reset button in forms clear any previous alerts now.
• RT1679: NPM dependency packages have been upgraded.
• RT1671: libevent and libzip deps are limited to just the border RPM package now.
• RT1681: Installation instructions are now included in the Border User Manual; they were previously missing from the dist.
• RT1682: Form resets are handled more consistently now similar to submit.
• RT1683: Some JavaScript was moved out of the JSX HTML.
• RT1692: NPM dependency packages have been upgraded.
• RT1706: NPM dependency packages have been upgraded.

Some more development releases will be made from this branch until Border 2.0 is ready to be branched. You can read about Border branches and version numbering.

Loop version 1.99.8 has been released (tagged at 1.99.8.20251104005426.4e37e60402). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.8:

• RT1671: libevent and libzip deps are limited to just the border RPM package now.
• RT1086: The TSIG timesigned value is cached and checked now per RFC 8945 section 5.2.3. Not checking the time permits a type of transaction replay attack which has been added as a testcase in our system tests.
• RT1229: Loop's named program returns the EDNS Extended DNS Error option (RFC 8914). Some configuration options such as ede-enable and ede-extra-text-enable have been added to control this feature. The feature is enabled by default, and an Extended DNS Error option is returned in responses whenever additional information is available. A list of the option values that Loop may return in responses, including their RCODE, INFO-CODE, and EXTRA-TEXT values are listed in a table in the Loop User Manual (see the section titled EDNS Extended DNS Error). There are several more conditions identified where the Extended DNS Error option is to be returned, but these need additional changes that have been moved to new tickets and will be available in future releases.

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

Lease version 1.99.8 has been released (tagged at 1.99.8.20251104005426.4e37e60402). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Lease 1.99.8:

• RT1671: libevent and libzip deps are limited to just the border RPM package now.

Some more development releases will be made from this branch until Lease 2.0 is ready to be branched. You can read about Lease branches and version numbering.

Loop version 1.99.7 has been released (tagged at 1.99.7.20250831123527.772ce56e35). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.7:

• RT1428: The packaging of Loop was updated. Loop is part of a source code tree with other components such as Lease and Border, and previously only Loop and Lease were packaged. Other components of the tree are also packaged now as part of a multi-package RPM spec file. The border-release package which installed the border-epel, border-epel-testing, border-fedora, and border-fedora-testing DNF package repositories and their package signing PGP key has been replaced with the akira-release package which installs the akira-epel, akira-epel-testing, akira-fedora, and akira-fedora-testing DNF package repositories and their package signing PGP key.
• RT1660: Functionality to make named(8) a daemon was moved to a new module in the libloop library. This is not a user-visible change.
• RT1661: chroot(2) functionality was moved to the libloop library. This is not a user-visible change.
• RT1662: Privilege dropping functionality (using Linux capabilities API) was moved to a new module in the libloop library. This is not a user-visible change.
• RT1657: syslog functionality was moved to a new module in the libloop library. This is not a user-visible change.
• RT1656: ns_os_shutdownmsg() was moved to live within the server module. This is not a user-visible change.
• RT1654: A gethostname() wrapper was moved to the libloop library. This is not a user-visible change.
• RT1653: PID file functionality was moved to a new module in the libloop library. This is not a user-visible change.
• RT1652: PID file code was refactored. This is not a user-visible change.
• RT1651: Error functions were refactored; UNEXPECTED_ERROR and FATAL_ERROR macros were removed. These are not user-visible changes.
• RT1648: loop_lib_init() now calls tzset(3); it was previously called by the :program:named program's code. This is not a user-visible change. The call may be removed in the future.
• RT1647: CPU count functionality was moved to a new module in the libloop library. This is not a user-visible change.
• RT1646: NULL is now allowed in loop_mem_strdup() which returns NULL. This is not a user-visible change.
• RT1640: A loop_uuid module was added. This is not a user-visible change.
• RT1639: A loop_mime module was added. This is not a user-visible change.
• RT1638: Support to create urlsafe Base64 was added to libloop (see RFC 4648 section 5). This is not a user-visible change.
• RT1632: Some remnant code and documentation of the obsolete named-compilezone program were removed.
• RT1633: The Loop version string was incorrectly reported in some places previously due to some recent changes. Uses of PACKAGE_ macros were changed so that the issue does not occur again.
• RT1613: All the programs of Loop and Lease were updated to use consistent command line options for version, verbosity, help, etc.
• RT1618: DNS names were added to the list of items in the data and privacy section of the Loop and Lease user manuals.

To upgrade from a previous release of Loop on an RPM platform, first remove the obsolete border-release and loop-release RPMs:

[user@host ~]$ sudo dnf remove border-release loop-release

Then, install the akira-release package as described in the installation instructions. This will install the new DNF package repositories.

Then, upgrade the loop package, which should install it from the new DNF package repository:

[user@host ~]$ sudo dnf upgrade loop

You may clean up the old Border Package Signer key using clean-rpm-gpg-pubkey:

[user@host ~]$ sudo dnf install clean-rpm-gpg-pubkey
[user@host ~]$ sudo clean-rpm-gpg-pubkey

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

Border version 1.99.7 has been released (tagged at 1.99.7.20250831123527.772ce56e35). This is the first public release of Border. It is in a series of releases made from the 1.99 development branch.

The following are release notes for Border 1.99.7:

• RT1428: Border is now packaged.
• RT1642: A header was added to Border web licenses.
• RT1664: Border now supports the listen-on statement in border.conf(5).
• RT1665: The border(8) process now runs as a daemon.
• RT1667: The border(8) process now drops privileges when run as root user using capabilities under Linux. It also supports being run in a chroot directory.
• RT1666: The border(8) process now creates PID files in its runstate directory.
• RT1668: The border(8) process is now run as the border user when started from the systemd border.service.
• RT1673: Copyright year was updated in various web source files.

To install Border, please see its installation instructions.

Some more development releases will be made from this branch until Border 2.0 is ready to be branched. You can read about Border branches and version numbering.

Lease version 1.99.7 has been released (tagged at 1.99.7.20250831123527.772ce56e35). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Lease 1.99.7:

• RT1428: The packaging of Lease was updated. Lease is part of a source code tree with other components such as Loop and Border, and previously only Lease and Loop were packaged. Other components of the tree are also packaged now as part of a multi-package RPM spec file. The border-release package which installed the border-epel, border-epel-testing, border-fedora, and border-fedora-testing DNF package repositories and their package signing PGP key has been replaced with the akira-release package which installs the akira-epel, akira-epel-testing, akira-fedora, and akira-fedora-testing DNF package repositories and their package signing PGP key.
• RT1672: A minor syntax error was fixed in the Lease RPM's post-installation script (it did not cause an actual issue other than the error report).
• RT1613: All the programs of Loop and Lease were updated to use consistent command line options for version, verbosity, help, etc.
• RT1618: DNS names were added to the list of items in the data and privacy section of the Loop and Lease user manuals.

To upgrade from a previous release of Lease on an RPM platform, first remove the obsolete border-release RPM:

[user@host ~]$ sudo dnf remove border-release

Then, install the akira-release package as described in the installation instructions. This will install the new DNF package repositories.

Then, upgrade the lease package, which should install it from the new DNF package repository:

[user@host ~]$ sudo dnf upgrade lease

You may clean up the old Border Package Signer key using clean-rpm-gpg-pubkey:

[user@host ~]$ sudo dnf install clean-rpm-gpg-pubkey
[user@host ~]$ sudo clean-rpm-gpg-pubkey

Some more development releases will be made from this branch until Lease 2.0 is ready to be branched. You can read about Lease branches and version numbering.

Lease version 1.99.6 has been released (tagged at 1.99.6.20250811025749.965cadab44). This is the first public release of Lease. It is in a series of releases made from the 1.99 development branch.

The following are release notes for Lease 1.99.6:

• RT1606: Lease packages are now built. Lease is part of a source code tree with other components such as Loop, and previously only Loop was packaged. Other components of the tree are also packaged now as part of a multi-package RPM spec file.

To install Lease, please see its installation instructions.

Some more development releases will be made from this branch until Lease 2.0 is ready to be branched. You can read about Lease branches and version numbering.

Loop version 1.99.6 has been released (tagged at 1.99.6.20250811025749.965cadab44). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.6:

• RT1606: The packaging of Loop was updated. Loop is part of a source code tree with other components such as Lease, and previously only Loop was packaged. Other components of the tree are also packaged now as part of a multi-package RPM spec file. The loop-release package which installed the loop-epel, loop-epel-testing, loop-fedora, and loop-fedora-testing DNF package repositories and their package signing PGP key has been replaced with the border-release package which installs the border-epel, border-epel-testing, border-fedora, and border-fedora-testing DNF package repositories and their package signing PGP key.
• RT1607: The system path for storing PID files, session key files, etc. was updated to use runstatedir instead of localstatedir/run, as RPM packaging makes a distinction in these paths and uses the former.
• RT1608: A documentation link was added to the Systemd named.service file.

To upgrade from a previous release of Loop on an RPM platform, first remove the obsolete loop-release RPM:

[user@host ~]$ sudo dnf remove loop-release

Then, install the border-release package as described in the installation instructions. This will install the new DNF package repositories.

Then, upgrade the loop package, which should install it from the new DNF package repository:

[user@host ~]$ sudo dnf upgrade loop

You may clean up the old Loop Package Signer key using clean-rpm-gpg-pubkey:

[user@host ~]$ sudo dnf install clean-rpm-gpg-pubkey
[user@host ~]$ sudo clean-rpm-gpg-pubkey

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

Loop version 1.99.5 has been released (tagged at 1.99.5.20250803090512.84dee3c593). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.5:

• RT1577: Loop now applies a maximum RSA public exponent size of 256 bits during DNSSEC validation. Previously it was unlimited, and there is also no limit suggested in the DNS standards currently for the RSA public exponent. An unlimited RSA public exponent size can increase RSA signature validation times significantly. There was no vulnerability due to this lack of limit in practice, as other limits in buffer sizes and the OpenSSL library restricted the maximum exponent size that could be successfully used. However, these effects were serendipitous, and an explicit limit of 256 bits has now been set as suggested in FIPS 186-5 and NIST SP 800-56B. The maximum allowed RSA public exponent size can be configured using the max-rsa-exponent-size config option of named.conf(5). 256 bits is also the maximum value allowed for the max-rsa-exponent-size config option. RSA DNSKEYs created by Loop continue to use a fixed public exponent 65537 which is 17 bits long.
• RT1569: dnssec-keygen(1) can now create encrypted DNSKEY private keys, so that private key material can be stored encrypted at-rest on disk. Until now, private key material could only be stored in clear-text unencrypted form in files named Knnnn.+aaa+iiiii.private where <nnnn> is the key name, <aaa> is the numeric representation of the algorithm, and <iiiii> is the key identifier. If one needed better security for the key material, the only other alternative was to store the keys in a hardware security module (HSM). Now, as another option, the DNSSEC programs allow storing and using private keys in an encrypted Knnnn.+aaa+iiiii.pem file alongside the existing Knnnn.+aaa+iiiii.key and Knnnn.+aaa+iiiii.private files. In this case, the private key material fields are stored in the encrypted Knnnn.+aaa+iiiii.pem file instead of the clear-text Knnnn.+aaa+iiiii.private file, whereas the Knnnn.+aaa+iiiii.private file continues to store key metadata. This protects the private key material at rest.
• RT1592: The Loop system tests have been updated to use modern DNSSEC algorithms, and RSASHA1 and NSEC3RSASHA1 are no longer used except to test specific cases where their use is required. This is in preparation awaiting the approval of draft-ietf-dnsop-must-not-sha1 when support for DNSSEC signing with RSA + SHA-1 will be dropped. dnssec-keygen(1) and dnssec-keyfromlabel(1) now print a warning if RSASHA1 or NSEC3RSASHA1 keys are created.
• RT1591: DNSSEC programs such as dnssec-keygen(1) and dnssec-keyfromlabel(1) now require the DNSKEY algorithm to be specified explicitly using the -a command-line argument. There is no longer a default selection of the algorithm. References have been added to the manpage on selecting a suitable algorithm. This is to avoid unexpected surprises when these programs are used in scripts and the default algorithm type has to change.
• RT1579: The platform.h header which catered to differences in obsolete POSIX platforms has been removed as the source code tree has been modernized in recent years. This is not a user-visible change.

Other changes were made to the tree that are not ready for public release.

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

Loop version 1.99.4 has been released (tagged at 1.99.4.20250713141817.bfebf34e59). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.4:

• RT1513: Support for Fedora 40 has been dropped as it has reached EOL upstream.
• RT1524: Support for RHEL 7 has been dropped as it has reached end-of-maintenance support upstream. Compiling Loop packages for RHEL 7 had needed extra dependencies such as a newer C compiler from devtoolset-7-gcc with support for <stdatomic.h>, and several code and build farm customizations. These have now been dropped.
• RT1543: Several files missing from the dist tarball (source code tarball) were added to EXTRA_DIST. These are not user-visible as they're not packaged in the binary packages.
• RT1544: A unittest suite was added for the database versioning functionality (dbversion).
• RT1550: A seperate memory context is now used for OpenSSL 3 library's memory allocations. This allows the user to do accounting of OpenSSL 3 library's memory allocations.
• RT1551: A benchmark program called benchmark-zone-queries was added. This program is not packaged in the binary packages currently.
• RT1557: The task manager (taskmgr) was refactored to use atomic operations and remove mutex locking in several places.
• RT1558: Loop's worker threads (part of the task manager) have been refactored to use event loops instead of condition variables. The user visible aspect of this would be that in backtraces, worker threads would no longer be seen blocked on pthread_cond_wait() waiting for work. Instead they would be seen blocked on epoll_wait() (Linux) or kevent() (FreeBSD).
• RT1560: Some unnecessary arrays (proportional to the <maximum-sockets> value) and mutex arrays (and associated locking) were removed from the socket manager (socketmgr). This was possible due to the use of struct epoll_event->data.ptr and struct kevent->udata fields available as part of epoll and kevent respectively. Now, the <maximum-sockets> value as provided to named -S is simply a limit and does not use any additional resources. It could become an advisory limit in the future.
• RT1562: A member of the socket structure was not initialized leading to a single Valgrind memcheck report which was fixed. There are no more Valgrind memcheck reports generated for named during any of our unit and system tests currently.
• RT1515: The object attribute's value provided to dnssec-keyfromlabel -l is now properly URI percent-encoded per RFC 7512 and RFC 3986.
• RT1564: The PIN command-line argument for DNSSEC programs has been removed. A PIN can now be provided as part of the PKCS#11 URI itself (see RFC 7512 for the pin-source and pin-value attributes).
• RT1516: A PKCS#11 HOWTO has been added to the Loop User Manual.
• RT1565: Release notes are now available in the Loop User Manual.

RT1560 and RT1558 involve significant changes to the socketmgr and taskmgr respectively. If there are any issues observed while using Loop, please contact us.

Other changes were made to the tree that are not ready for public release.

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

This is an example of how to use Loop's PKCS#11 support to perform DNSSEC zone signing with keys stored in HSMs (hardware security modules).

• This example uses the SoftHSMv2 PKCS#11 provider for demonstration.

• In real-world usage, you would use the PKCS#11 provider module provided by your HSM vendor.

• For some smart cards and USB tokens, you may be able to use the PKCS#11 provider provided by the OpenSC project.

To bridge between the PKCS#11 provider module and the OpenSSL library, an OpenSSL provider module called pkcs11-provider is used.

Programs in Loop call the OpenSSL library, which calls the pkcs11-provider OpenSSL provider, which in turn calls the HSM vendor's PKCS#11 provider (SoftHSMv2 in this example).

Install dependencies

As the root user or using sudo, install the SoftHSMv2, pkcs11-provider, and p11-kit packages for your platform. p11-kit provides the program p11tool which you may optionally use to manipulate tokens on the HSM.

For example, on Red Hat Enterprise Linux 10 or Fedora platforms, you may use the following command to install these packages:

[user@host ~]$ sudo dnf install softhsm pkcs11-provider p11-kit

On RHEL, the softhsm package should be available as a part of AppStream.

Create a working directory

For this example, we will create a sub-directory called pkcs11/ as our working directory and store almost everything relative to this directory. In real-world usage, you can store configuration and data in system directories and modify paths accordingly.

[user@host ~]$ mkdir pkcs11
[user@host ~]$ cd pkcs11
[user@host ~/pkcs11]$

Configure SoftHSMv2

Let us configure and setup SoftHSMv2. SoftHSMv2 stores tokens in a directory on the filesystem. We create a sub-directory within the pkcs11/ directory for it, and create a softhsm2.conf file to configure SoftHSMv2 to use this directory. We also set the SOFTHSM2_CONF environment variable to tell SoftHSMv2 that it should use our softhsm2.conf file.

[user@host ~/pkcs11]$ mkdir softhsm2-tokendir
[user@host ~/pkcs11]$ cat > softhsm2.conf
directories.tokendir=softhsm2-tokendir
[user@host ~/pkcs11]$ export SOFTHSM2_CONF=softhsm2.conf
[user@host ~/pkcs11]$

Next, we initialize a SoftHSMv2 token so we may use it. We also assign a PIN of "1234" (you may use a different PIN if you like):

[user@host ~/pkcs11]$ softhsm2-util --init-token --free --label "example" --pin 1234 --so-pin 1234
Slot 0 has a free/uninitialized token.
The token has been initialized and is reassigned to slot 2076677265
[user@host ~/pkcs11]$ softhsm2-util --token example --show-slots
Available slots:
Slot 2076677265
    Slot info:
        Description:      SoftHSM slot ID 0x7bc79491
        Manufacturer ID:  SoftHSM project
        Hardware version: 2.6
        Firmware version: 2.6
        Token present:    yes
    Token info:
        Manufacturer ID:  SoftHSM project
        Model:            SoftHSM v2
        Hardware version: 2.6
        Firmware version: 2.6
        Serial number:    74a2bc56fbc79491
        Initialized:      yes
        User PIN init.:   yes
        Label:            example
Slot 1
    Slot info:
        Description:      SoftHSM slot ID 0x1
        Manufacturer ID:  SoftHSM project
        Hardware version: 2.6
        Firmware version: 2.6
        Token present:    yes
    Token info:
        Manufacturer ID:  SoftHSM project
        Model:            SoftHSM v2
        Hardware version: 2.6
        Firmware version: 2.6
        Serial number:
        Initialized:      no
        User PIN init.:   no
        Label:
[user@host ~/pkcs11]$

(The slot number it assigns may differ for you as it is chosen randomly; it does not matter.)

We can use p11tool to determine the PKCS#11 URI for the token. This URI will be used later in our example.

[user@host ~/pkcs11]$ p11tool --list-token-urls | grep "example"
pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=74a2bc56fbc79491;token=example
[user@host ~/pkcs11]$

You can also notice newly created files in softhsm2-tokendir/:

[user@host ~/pkcs11]$ find softhsm2-tokendir/
softhsm2-tokendir/
softhsm2-tokendir/b595ca7b-14c8-d5fd-74a2-bc56fbc79491
softhsm2-tokendir/b595ca7b-14c8-d5fd-74a2-bc56fbc79491/token.object
softhsm2-tokendir/b595ca7b-14c8-d5fd-74a2-bc56fbc79491/generation
softhsm2-tokendir/b595ca7b-14c8-d5fd-74a2-bc56fbc79491/token.lock
[user@host ~/pkcs11]$

Configure OpenSSL

Let us now configure OpenSSL to use pkcs11-provider, and pkcs11-provider to use SoftHSMv2. We create an openssl.cnf file to configure OpenSSL. We also set the OPENSSL_CONF environment variable to tell OpenSSL that it should use our openssl.cnf file.

[user@host ~/pkcs11]$ cat > openssl.cnf
HOME = .

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
pkcs11 = pkcs11_sect

[default_sect]
activate = 1

[pkcs11_sect]
module = pkcs11.so
pkcs11-module-path = /usr/lib/softhsm/libsofthsm2.so
pkcs11-module-token-pin = 1234
pkcs11-module-quirks = no-deinit
activate = 1
[user@host ~/pkcs11]$ export OPENSSL_CONF=openssl.cnf
[user@host ~/pkcs11]$

In the above configuration, a pkcs11 OpenSSL provider module is configured in the pkcs11_sect section. It uses the pkcs11.so module installed as part of the pkcs11-provider package into the OpenSSL ossl-modules directory (typically somewhere within /usr/lib/).

• pkcs11-module-path configures pkcs11-provider to use the SoftHSM2 PKCS#11 provider. In case this path is incorrect, please use the correct path to libsofthsm2.so on your host.
• pkcs11-mode-token-pin configures the PIN to access the SoftHSMv2 token. It is configured here as it is a tutorial, but you may want to leave it out for security, and you'll be prompted to provide the PIN every time the token is used.
• pkcs11-module-quirks configures quirks in pkcs11-provider. Here, no-deinit is configured to ask pkcs11-provider not to perform deinitialization during shutdown of the PKCS#11 module. On some supported platforms, the currently available version of SoftHSMv2 does not deinitialize properly and crashes. The available quirks are documented in the provider-pkcs11 manpage.

Please consult the OpenSSL documentation for more details about what the various configuration elements mean.

Create a DNSKEY by generating or importing keys

We will create a DNSKEY to sign the example.com. zone. There are two approaches to creating it. We can:

• Generate a new DNSKEY on the HSM
• Import an existing key from the HSM

In both cases, the .private file of the DNSKEY file pair that is created contains a label referring to the HSM. It doesn't contain any private key material (which lives within the HSM). The .key file of the DNSKEY file pair that is created contains the public key as a DNSKEY record.

Both approaches are described in the section below.

Create a DNSKEY by generating it

The dnssec-keygen program can be used to generate a key on a HSM. We have to provide a label or a full PKCS#11 URI for an object to store the key into, using the dnssec-keygen -l argument. In this case, we will use a PKCS#11 URI, and label the key as my-rsa-2048. So we append ;object=my-rsa-2048 to the URI that p11tool returned above.

We create a DNSKEY on the HSM with algorithm RSASHA256; the RSA key is 2048 bits in size:

[user@host ~/pkcs11]$ dnssec-keygen -l "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=74a2bc56fbc79491;token=example;object=my-rsa-2048" -a RSASHA256 -b 2048 -n ZONE example.com
Generating key pair.
Kexample.com.+008+44679
[user@host ~/pkcs11]$ cat Kexample.com.+008+44679.private
Private-key-format: v1.3
Algorithm: 8 (RSASHA256)
Modulus: pyBJmKobVVB4NJpEYqUIsY46DZwH47dYCDCQX4qGJ2d2wbX8h9wdw8onhSpgpF5BiqfJ0uKEBx/OwsPa5FkYRRouTxXtP2BoWpq+ZRWBJssn+H7Z7Zn7BMNVyZpMiYaC5eMqWDT9N6HnD8fa6hTx8mC+5vhTT76A7FE4r5bukH48RXUfIJh4h1ipG2sGbya/nwTI22SJdnZpwhDpanqn1Li4zgH/ciy3ktdkVxD+3cgp07mSO2PowrDv7Qeyga3tRyYGO3rwHxPsbF8syj7FNCpWwFbTOUS67ooykPxV3RhevOOFTj1SRH4mpbuvNa4RY/ekPpUwcbuZuBiX0UAr9Q==
PublicExponent: AQAB
Label: cGtjczExOm1vZGVsPVNvZnRIU00lMjB2MjttYW51ZmFjdHVyZXI9U29mdEhTTSUyMHByb2plY3Q7c2VyaWFsPTc0YTJiYzU2ZmJjNzk0OTE7dG9rZW49ZXhhbXBsZTtvYmplY3Q9bXktcnNhLTIwNDgA
Created: 20250705122326
Publish: 20250705122326
Activate: 20250705122326
[user@host ~/pkcs11]$ cat Kexample.com.+008+44679.key
; This is a zone-signing key, keyid 44679, for example.com.
; Created: 20250705122326 (Sat Jul  5 20:23:26 2025)
; Publish: 20250705122326 (Sat Jul  5 20:23:26 2025)
; Activate: 20250705122326 (Sat Jul  5 20:23:26 2025)
example.com. IN DNSKEY 256 3 8 AwEAAacgSZiqG1VQeDSaRGKlCLGOOg2cB+O3WAgwkF+KhidndsG1/Ifc HcPKJ4UqYKReQYqnydLihAcfzsLD2uRZGEUaLk8V7T9gaFqavmUVgSbL J/h+2e2Z+wTDVcmaTImGguXjKlg0/Teh5w/H2uoU8fJgvub4U0++gOxR OK+W7pB+PEV1HyCYeIdYqRtrBm8mv58EyNtkiXZ2acIQ6Wp6p9S4uM4B /3Ist5LXZFcQ/t3IKdO5kjtj6MKw7+0HsoGt7UcmBjt68B8T7GxfLMo+ xTQqVsBW0zlEuu6KMpD8Vd0YXrzjhU49UkR+JqW7rzWuEWP3pD6VMHG7 mbgYl9FAK/U=
[user@host ~/pkcs11]$

The value of the Label: field printed above from the Kexample.com.+008+44679.private file is a Base64 encoded PKCS#11 URI string of the object. There is no private key material in this file, and this file serves like a symbolic link to the object my-rsa-2048 in the HSM.

[user@host ~/pkcs11]$ echo -n "cGtjczExOm1vZGVsPVNvZnRIU00lMjB2MjttYW51ZmFjdHVyZXI9U29mdEhTTSUyMHByb2plY3Q7c2VyaWFsPTc0YTJiYzU2ZmJjNzk0OTE7dG9rZW49ZXhhbXBsZTtvYmplY3Q9bXktcnNhLTIwNDgA" | base64 -d; echo
pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=74a2bc56fbc79491;token=example;object=my-rsa-2048
[user@host ~/pkcs11]$

(The DNSKEY key ID it assigns may differ for you as it is chosen randomly; it does not matter.)

See the dnssec-keygen(1) manpage for more details on its usage.

Create a DNSKEY by importing it from the HSM

Alternatively, the dnssec-keyfromlabel program can be used to import an existing key from a HSM. The public key is imported. We have to provide a label or a full PKCS#11 URI of an object to import the key from, using the dnssec-keyfromlabel -l argument. In this case, we will use a PKCS#11 URI, and assume the existing object is labeled my-rsa-2048. So we append ;object=my-rsa-2048 to the URI that p11tool returned above.

We create a DNSKEY with algorithm RSASHA256 by importing an existing key labelled my-rsa-2048 from the HSM:

[user@host ~/pkcs11]$ dnssec-keyfromlabel -l "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=74a2bc56fbc79491;token=example;object=my-rsa-2048" -a RSASHA256 -n ZONE example.com
Kexample.com.+008+44679
[user@host ~/pkcs11]$ cat Kexample.com.+008+44679.key
; This is a zone-signing key, keyid 44679, for example.com.
; Created: 20250705125450 (Sat Jul  5 20:54:50 2025)
; Publish: 20250705125450 (Sat Jul  5 20:54:50 2025)
; Activate: 20250705125450 (Sat Jul  5 20:54:50 2025)
example.com. IN DNSKEY 256 3 8 AwEAAacgSZiqG1VQeDSaRGKlCLGOOg2cB+O3WAgwkF+KhidndsG1/Ifc HcPKJ4UqYKReQYqnydLihAcfzsLD2uRZGEUaLk8V7T9gaFqavmUVgSbL J/h+2e2Z+wTDVcmaTImGguXjKlg0/Teh5w/H2uoU8fJgvub4U0++gOxR OK+W7pB+PEV1HyCYeIdYqRtrBm8mv58EyNtkiXZ2acIQ6Wp6p9S4uM4B /3Ist5LXZFcQ/t3IKdO5kjtj6MKw7+0HsoGt7UcmBjt68B8T7GxfLMo+ xTQqVsBW0zlEuu6KMpD8Vd0YXrzjhU49UkR+JqW7rzWuEWP3pD6VMHG7 mbgYl9FAK/U=
[user@host ~/pkcs11]$ cat Kexample.com.+008+44679.private
Private-key-format: v1.3
Algorithm: 8 (RSASHA256)
Modulus: pyBJmKobVVB4NJpEYqUIsY46DZwH47dYCDCQX4qGJ2d2wbX8h9wdw8onhSpgpF5BiqfJ0uKEBx/OwsPa5FkYRRouTxXtP2BoWpq+ZRWBJssn+H7Z7Zn7BMNVyZpMiYaC5eMqWDT9N6HnD8fa6hTx8mC+5vhTT76A7FE4r5bukH48RXUfIJh4h1ipG2sGbya/nwTI22SJdnZpwhDpanqn1Li4zgH/ciy3ktdkVxD+3cgp07mSO2PowrDv7Qeyga3tRyYGO3rwHxPsbF8syj7FNCpWwFbTOUS67ooykPxV3RhevOOFTj1SRH4mpbuvNa4RY/ekPpUwcbuZuBiX0UAr9Q==
PublicExponent: AQAB
Label: cGtjczExOm1vZGVsPVNvZnRIU00lMjB2MjttYW51ZmFjdHVyZXI9U29mdEhTTSUyMHByb2plY3Q7c2VyaWFsPTc0YTJiYzU2ZmJjNzk0OTE7dG9rZW49ZXhhbXBsZTtvYmplY3Q9bXktcnNhLTIwNDgA
Created: 20250705125450
Publish: 20250705125450
Activate: 20250705125450
[user@host ~/pkcs11]$

Unlike the dnssec-keygen command in the previous section, no key size can be specified when using dnssec-keyfromlabel as the key is already present in the HSM and has its existing key size.

The value of the Label: field printed above from the Kexample.com.+008+44679.private file is a Base64 encoded PKCS#11 URI string of the object. There is no private key material in this file, and this file serves like a symbolic link to the object my-rsa-2048 in the HSM.

[user@host ~/pkcs11]$ echo -n "cGtjczExOm1vZGVsPVNvZnRIU00lMjB2MjttYW51ZmFjdHVyZXI9U29mdEhTTSUyMHByb2plY3Q7c2VyaWFsPTc0YTJiYzU2ZmJjNzk0OTE7dG9rZW49ZXhhbXBsZTtvYmplY3Q9bXktcnNhLTIwNDgA" | base64 -d; echo
pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=74a2bc56fbc79491;token=example;object=my-rsa-2048
[user@host ~/pkcs11]$

See the dnssec-keyfromlabel(1) manpage for more details on its usage.

Sign a DNS zone using the DNSKEY

Now that we have the Kexample.com.+008+44679.key and Kexample.com.+008+44679.private files, we can sign a master file for the example.com zone. We use the the dnssec-signzone program to sign zones.

Let's create a sample master file for the example.com. zone, and also check that it is syntactically correct:

[user@host ~/pkcs11]$ cat > example.com.db
$TTL 3600
example.com.      IN SOA  . . 2025070500 600 600 1200 600
example.com.         NS ns1.example.com.
ns1.example.com.     A 127.0.0.1
example.com.         A 127.0.0.1
[user@host ~/pkcs11]$ named-checkzone example.com example.com.db
zone example.com/IN: loaded serial 2025070500
OK
[user@host ~/pkcs11]$

This zone's data can be signed now using the HSM. We use smart signing by calling dnssec-signzone -S so that it discovers the DNSKEY automatically in the Kexample.com.+008+44679.key and Kexample.com.+008+44679.private files.

[user@host ~/pkcs11]$ dnssec-signzone -S -z -o example.com example.com.db
Fetching ZSK 44679/RSASHA256 from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 0 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
example.com.db.signed
[user@host ~/pkcs11]$

The signed zone's data is saved to the master file example.com.db.signed and has the following content:

[user@host ~/pkcs11]$ cat example.com.db.signed
; File written on Sat Jul  5 21:22:21 2025
; dnssec-signzone version 1.99.3.20250623003957.08c26b66c1
example.com.        3600    IN SOA  . . (
                    2025070500 ; serial
                    600        ; refresh (10 minutes)
                    600        ; retry (10 minutes)
                    1200       ; expire (20 minutes)
                    600        ; minimum (10 minutes)
                    )
            3600    RRSIG   SOA 8 2 3600 (
                    20250804122221 20250705122221 44679 example.com.
                    gOVYSFEU+F6oApb4xEFAhj77VI8XGhVxwiU+
                    LzVySfD/j6yL1kCGOez/f/c4jxxZzCP36ztB
                    MLejT6A/fuSfGVIRRsjkQ+2AK+p3z0wiSyYL
                    zSMeDgiQqjh5JwQ+CaR/lAa2+AzQG6goe76k
                    3ZQbda6E/4EK733jA2Ahh3Afl5YUJH3yqvDo
                    ZtVavZxd+Jo1c7FQBKn24NotXDjqewaCZ3XX
                    TxmmFSBzdy1Vv3PpnapF4FzLvnWqsTbR6v/Z
                    JQPqKvxGjUDc5ETp+aOG59JkzSE9vPj/bGZQ
                    OiQhUQ0VL4iDpyiN98+y8oQ3Tvp9Lh7KNwRW
                    beC9Lgf8CFxNg5BgUw== )
            3600    NS  ns1.example.com.
            3600    RRSIG   NS 8 2 3600 (
                    20250804122221 20250705122221 44679 example.com.
                    IdGBtB2RUyTEcpxxCoVqa6XKyYaMgyGaZhp3
                    dj31FNV7xyH2xLM7j9d5A8qr1ORMLm31UCB/
                    0tLcxndqFcH0gXipxm78rppEFGiLSNPEDs1q
                    8owr+zzjJ2Dtkf5Sg008BmDrAMFMHlvHQ2E0
                    Ij8wjdRz11NDVkdwkW/MPMp1B1RSTLZujXx3
                    2LQXMs1RQcrc4Nk70juyl8UNe2nUOJuEO6SV
                    2Y8YtDqCdWa2bgmrncm7OE+SJ79UZOG6gsu/
                    688V39AaN/IMK57Ua59aeN6C7bZQ3D8YWKo5
                    IDS+Mza+jAeydQpjFEZSBC5Z9sGReIpPRyPg
                    3euahyjMhnx5DWkZUg== )
            3600    A   127.0.0.1
            3600    RRSIG   A 8 2 3600 (
                    20250804122221 20250705122221 44679 example.com.
                    mJ1Ma0CgANegpwh4Ox6wIxxMiO/W99PLE66w
                    mteJCTiJWdoNjiQsaK8CPpaehP+ttF4WazDs
                    0DNaZUzRBiaWtLa5PIJGRYlfHB/gWkWRy3Oq
                    3HeaVRU0i59GW0/cCt4oJsJF3KPziFLIdmUU
                    Ge9GA7x17m+Fyp/BDo6EfPsYgOZlMY+GBofC
                    DfxsZzgPhI6+MN6uLkDLrmwtuZ9KS3lIu4I5
                    tdIx9PLRteH1CEEAhUAHq0wFAs39TQs2uB27
                    TiHzqTjfergtPyZYHWc7Swry3JahKLcQw0kB
                    n+4q1tbb8ktOZqUszrFMt+xKzi948rkFJswU
                    DFID+NQzpSNRGtOzaw== )
            600 NSEC    ns1.example.com. A NS SOA RRSIG NSEC DNSKEY
            600 RRSIG   NSEC 8 2 600 (
                    20250804122221 20250705122221 44679 example.com.
                    kYFu3pdpBfI+7CITOXdKULrwCpbmVQlO+jC/
                    sNPcdDSNuInm8cq5UVy05/vV0FxPSJEhY1qr
                    38FQbYl9CAI0EuIDvlwhadlO6kli4A4QVlER
                    TB6diBOOHV00eyUYOwg/gNYDKaKGdh1msAhV
                    QnvIScf9Z5QgCglnA+vOuVngGM8u4jNQjUTf
                    vReOgqr4ZoWfFommJHVMzbtM8gHVabPw4ExB
                    hoAeqe4o4ZPPReBWh75ounOUXMhrIS48YJ5/
                    /X6K54m7tAKEHL7yQ21sM5OELNWe+CqXnYcK
                    Bq6NjYPRr+aNwqpIQ+SmsIGhE9CBbrwgka39
                    JpLv3QxzY+CUNaJJmA== )
            3600    DNSKEY  256 3 8 (
                    AwEAAacgSZiqG1VQeDSaRGKlCLGOOg2cB+O3
                    WAgwkF+KhidndsG1/IfcHcPKJ4UqYKReQYqn
                    ydLihAcfzsLD2uRZGEUaLk8V7T9gaFqavmUV
                    gSbLJ/h+2e2Z+wTDVcmaTImGguXjKlg0/Teh
                    5w/H2uoU8fJgvub4U0++gOxROK+W7pB+PEV1
                    HyCYeIdYqRtrBm8mv58EyNtkiXZ2acIQ6Wp6
                    p9S4uM4B/3Ist5LXZFcQ/t3IKdO5kjtj6MKw
                    7+0HsoGt7UcmBjt68B8T7GxfLMo+xTQqVsBW
                    0zlEuu6KMpD8Vd0YXrzjhU49UkR+JqW7rzWu
                    EWP3pD6VMHG7mbgYl9FAK/U=
                    ) ; ZSK; alg = RSASHA256 ; key id = 44679
            3600    RRSIG   DNSKEY 8 2 3600 (
                    20250804122221 20250705122221 44679 example.com.
                    GRds9ebVM8g6n6GqswPoiaEV5xK+2DcxSXZG
                    qgLwu8eSakGAoZQkjdZ983NhL1cGDfk5q7pL
                    dvxpnCNZ4tzg7AKKfXr2BEqIGt7Xo9KLtKt0
                    SdsF5RioWyL3iRGjeFbaqxK5G2Dy1CCQD7DJ
                    KHvmv+pfnp1ls3i6xKNRjXsVrNPF1iEyivt8
                    l5NF1AsaHOfk/PIMrlpihzFBxM2A9S8XXwn7
                    j6KYm15FWl9RmU2y5akzPTNtVJPVFbVJ0OcD
                    DNIuNd4kzF8IWY3zigrfhuH3xPzGAhop30PH
                    r9ANnTASD7gzcVPGjkyfSXaxOBVKTtK/cmpP
                    /IK+CLaM1iL3fOfHyA== )
ns1.example.com.    3600    IN A    127.0.0.1
            3600    RRSIG   A 8 3 3600 (
                    20250804122221 20250705122221 44679 example.com.
                    jTuSieMy/0Faveu9ODXYAZ8NTIZqo1zJ//IC
                    syNX3Fs908G+sUqyZNnH0JHEC5cJQvfj0OEk
                    Mx8aW7PkyO7gKSraUDHs5F8fws0WNNueY+Oe
                    Zi6H6NA1l99wUxKLcaakzFZj6XgKYCLwSO1J
                    yyQrPb9Zs6FNkx+GaaeRbKq7xHeK/bMTMggt
                    7P3hhsFfYIj4KI0hgP23Jomc+OePZe6eDHee
                    WUHpod5TnLDXOri7IkLLuHxUsLo9Xnjp9FF5
                    HJcCvx1/XRip6D1kJqZ0x6w1kTEaA0E5YfF0
                    6uVfxB5kjmiN40EoFdpvfylRDZVQPPey214e
                    MTkvp3IOwDgqb8yMrQ== )
            600 NSEC    example.com. A RRSIG NSEC
            600 RRSIG   NSEC 8 3 600 (
                    20250804122221 20250705122221 44679 example.com.
                    KmGYCG01vI2SFsbP6NhXTyDWEzr08MF7Qiy9
                    TmqK5gL4cTwwIMhsAUWJG3YXMKGiotpMBsW5
                    kvso3od/+fisEGrDA9ik4higHwTZY+aocX1O
                    DLUTqNaVQ/KJ/vHO96jtFb8lkvyfuFO+K/tY
                    GXj+sd6Ol3sdRyUkAU17GRpchLgAjFGWImX8
                    s5WXfWDpmCVMSy7ORQxX6qfUhuqSIGcKjGbi
                    o1Uw1n4D7LxRSqbKgLD5i+YVPyUjOipdTzZm
                    c+X6qfUF5lf1bXuJbto8MSORwUGyA9jbG64H
                    mV8xPAV3lI627RNCOretwtAl2sRMr2c15XAy
                    M8NLrOtLjl6xBCKe4A== )
[user@host ~/pkcs11]$

See the dnssec-signzone(1) manpage for more details on its usage.

Verify the signed zone's data

Though the signed zone's data is automatically verified as part of the signing process, we can explicitly verify the signed zone's data to check that it is signed properly using the dnssec-verify program:

[user@host ~/pkcs11]$ dnssec-verify -z -o example.com example.com.db.signed
Loading zone 'example.com' from file 'example.com.db.signed'
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 0 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
[user@host ~/pkcs11]$

See the dnssec-verify(1) manpage for more details on its usage.

This ends the example.

Loop version 1.99.3 has been released (tagged at 1.99.3.20250623003957.08c26b66c1). This is in a series of releases made from the 1.99 development branch.

The following are release notes for Loop 1.99.3:

• RT1488: Some textual changes to the arpaname manpage were reverted.
• RT1502: OpenSSL and Kerberos library detection was improved. While this may not appear to be a user-visible change, it improves the linker flags that are used.
• RT1500: Support for Red Hat Enterprise Linux 10 was added. Loop RPM packages for RHEL 10 are now available for x86_64 and aarch64 platforms.
• RT1503: Support for OpenSSL library versions older than OpenSSL 3 has been dropped. All of Loop's supported platforms have the OpenSSL 3 library.
• RT1503: Usage of the libcrypto library API has been updated to use current OpenSSL 3 APIs, and all deprecated API usage has been removed.
• RT1503: PKCS#11 support has been updated to use the pkcs11-provider OpenSSL3 provider. The older OpenSSL engine support has been dropped completely. (Examples of PKCS#11 usage for DNSSEC will be documented soon.)
• RT1503: DNSSEC private keys of all the supported DNSKEY algorithms including RSASHA256, RSASHA512, ECDSAP256SHA256, ECDSAP384SHA384, ED25519, and ED448 can now be used from PKCS#11 accessible HSMs. All of these algorithms are tested in our automated system tests suite using the pkcs11-provider OpenSSL3 provider, and the SoftHSMv2 PKCS#11 provider.
• RT1507: dnssec-keygen(1) can now be used to directly generate keys on PKCS#11 accessible HSMs for all the supported DNSKEY algorithms including RSASHA256, RSASHA512, ECDSAP256SHA256, ECDSAP384SHA384, ED25519, and ED448. The -l argument was added for it. The method of importing the public key of an existing keypair on the HSM using dnssec-keyfromlabel(1) can also be used.
• RT1504: Support for the RSASHA1 DNSKEY algorithm on the OS platform running Loop is checked before use. Some operating systems such as Fedora 41 (and above) and Red Hat Enterprise Linux 10 disable support for RSASHA1 in their default configuration. Support is checked by signing and verifying some data using the algorithm to see if it succeeds — the algorithm is disabled (similar to the disable-algorithms config option of named.conf(5)) if the check fails.
• RT1505: The named(8) nameserver now explicitly disables RSAMD5, DSA, NSEC3DSA, and ECCGOST in its builtin configuration's disable-algorithms option. It also explicitly disables GOST in its builtin configuration's disable-ds-digests option.
• RT1511: Porting to FreeBSD has been completed and our unit tests and system tests suite pass on it. We expect to publish packages for FreeBSD soon.

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

Loop version 1.99.1 has been released (tagged at 1.99.1.20250102162327.d6e6dd4b1f). This is the first release made from the 1.99 development branch. Currently, there are no release notes.

Some more development releases will be made from this branch until Loop 2.0 is ready to be branched. You can read about Loop branches and version numbering.

Banu Systems Private Limited has been incorporated today in Singapore. The company's primary activity is software development. We have incorporated to be an incubator for several software products. We will begin by publishing Loop and related software modules.