11. Release notes¶

This documentation corresponds to Loop version 1.99.6.20250811025749.965cadab44.

11.1. Loop 1.99.6¶

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:

$ sudo dnf remove loop-release

Then, install the border-release package as described in the installation instructions (see the chapter titled Installation). This will install the new DNF package repositories.

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

$ sudo dnf upgrade loop

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

$ sudo dnf install clean-rpm-gpg-pubkey
$ sudo clean-rpm-gpg-pubkey

11.2. Loop 1.99.5¶

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 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.

11.3. Loop 1.99.4¶

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. Other changes were made to the tree that are not ready for public release.

11.4. Loop 1.99.3¶

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.

11.5. Loop version numbering scheme¶

Loop version numbers have the grammar <MAJOR>.<MINOR>.<PATCH>.<COMMIT-TIMESTAMP>.<COMMIT-HASH>. The MAJOR and MINOR version numbers together represent a source code branch of Loop (see Loop branches).

The MAJOR version number is incremented when configuration options, API, and behavior of features change compared to the existing version. Switching to a new MAJOR version may require modifying existing config files to make them compatible with the new version.
The MINOR version number is incremented when new configuration options, API, and features are introduced that are compatible with existing configuration options. Switching to a new MINOR version will not require modifying existing config files to make them compatible with the new version.
The PATCH version number is incremented when only bugs have been fixed in a new version. Switching to a new PATCH version will not require modifying existing config files to make them compatible with the new version.
The COMMIT-TIMESTAMP field is auto-generated and contains the UTC timestamp of the source code commit from which the Loop release was made. The timestamp value is formatted as YYYYMMDDHHMMSS, as the output of:
```
date +%Y%m%d%H%M%S
```
The COMMIT-HASH field is auto-generated and contains the abbreviated commit hash of the source code commit from which the Loop release was made. The hash value is formatted as the output of:
```
git log -n1 --reverse --pretty=%h
```

For example,

If you're upgrading from version 1.2.1 to version 1.4.0, Loop's config files should not require any changes. You may also check for new features that have become available in the 1.4 branch.
If you're upgrading from version 1.2.1 to version 2.0.0, it is possible that some of the contents of your existing config files may need changes. You may also check for new features that have become available in the 2.0 branch.
If you're upgrading from version 1.2.1 to version 1.2.4, Loop's config files should not require any changes. The newer version only contains bugfixes.

Note

During a major version's release series, features and/or programs scheduled for removal in the next major release may be marked as deprecated. They will however still be supported until the end-of-life of that major release.

11.5.1. Stable and development versions¶

Even-numbered minor versions indicate stable branch releases, whereas odd-numbered minor versions indicate development banch releases. For example,

1.2.0 is a stable branch release,
1.3.0 is a development branch release,
1.99.0 is a development branch release,
2.0.3 is a stable branch release, and
2.1.1 is a development branch release.

Warning

Development branch releases should not be used in production as their features and interfaces may change. Development branch releases may not work properly, may have unexpected behaviors, may crash, etc.

11.6. Loop branches¶

The following is information on current Loop branches.

Branch	Type	First release date	End-of-life date
1.99	Development	2024-12-10	To be announced
2.0	Stable	To be announced	To be announced

Development branches have no planned end-of-life. Typically, development on such branches is stopped when a new MINOR+1 or MAJOR+1 stable branch is created off it.

11.7. History of Loop¶

Although the official beginning of the Domain Name System occurred in 1984 with the publication of RFC 920, the core of the new system was described in 1983 in RFCs 882 and 883. From 1984 to 1987, the ARPAnet (the precursor to today's Internet) became a testbed of experimentation for developing the new naming/addressing scheme in a rapidly expanding, operational network environment. New RFCs were written and published in 1987 that modified the original documents to incorporate improvements based on the working model: RFC 1034 (Domain Names-Concepts and Facilities), and RFC 1035 (Domain Names-Implementation and Specification) were published and became the standards upon which all DNS implementations are built.

The first working domain name server, called Jeeves, was written in 1983--84 by Paul Mockapetris for operation on DEC Tops-20 machines located at the University of Southern California's Information Sciences Institute (USC-ISI) and SRI International's Network Information Center (SRI-NIC). A DNS server for Unix machines, the Berkeley Internet Name Domain (BIND) package, was written soon after by a group of graduate students at the University of California at Berkeley under a grant from the US Defense Advanced Research Projects Administration (DARPA).

Versions of BIND through 4.8.3 were maintained by the Computer Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark Painter, David Riggle and Songnian Zhou made up the initial BIND project team. After that, additional work on the software package was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment Corporation employee on loan to the CSRG, worked on BIND for 2 years, from 1985 to 1987. Many other people also contributed to BIND development during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently handled by Mike Karels and Øivind Kure.

BIND versions 4.9 and 4.9.1 were released by Digital Equipment Corporation (now Compaq Computer Corporation). Paul Vixie, then a DEC employee, became BIND's primary caretaker. He was assisted by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe Wolfhugel, and others.

In 1994, BIND version 4.9.2 was sponsored by Vixie Enterprises. Paul Vixie became BIND's principal architect/programmer.

BIND versions from 4.9.3 onward have been developed and maintained by the Internet Systems Consortium (ISC) and its predecessor, the Internet Software Consortium, with support being provided by ISC's sponsors. As co-architects/programmers, Bob Halley and Paul Vixie released the first production-ready version of BIND version 8 in May 1997. BIND version 9 was released in September 2000 and is a major rewrite of nearly all aspects of the underlying BIND architecture. A BIND 10 project was started by ISC in 2009 to build next-generation DNS and DHCP implementations, but it failed to reach its goals and was abandoned in 2014 after 5 years of development. ISC returned to focusing on BIND 9 from which additional releases continue to be made. A subscription branch of BIND 9 with some proprietary features was also started by ISC during this time that is available only to paying customers. With the release of BIND 9.11.0, BIND 9 underwent a license change from the ISC license to the Mozilla Public License version 2. The BIND 9 codebase continues to be developed by ISC.

Being what may be considered as a reference implementation of DNS, BIND 9 implemented many DNS related features. The BIND 9 codebase was developed starting in August 1998 and was well-designed with suitable use of encapsulation and abstraction. But due to decades of several different sets of internal and external developers extending and patching the code, its codebase became highly complex and unwieldly. BIND 9's competitors have caught up to it in the features that matter, and its performance compares very poorly to what is routinely achieved by its competitors. A major recent complaint of DNS operators is the high number of security vulnerabilities that are regularly found and fixed in BIND 9. This may be attributed to the breath of features and complexity which makes it difficult for BIND 9 to avoid vulnerabilities. The development team at ISC are efficient at fixing reported vulnerabilities quickly, and its releases are generally well-supported by ISC's staff.

Loop was started by a former BIND 9 developer with the goal of reducing the number of features in this codebase so that it still serves a large percentage of typical DNS operational use-cases, but with greatly reduced code complexity, improved quality of code and maintainability. Loop aims to serve some additional use-cases where BIND 9 is not applied currently. Loop forked from the BIND 9.10.8 release and incorporates some code from the BIND 9.11.0a2 release and some bits from BIND 10. While externally it still resembles BIND 9 with its similar configuration language and programs, its code has undergone considerable changes and continues to evolve at a high rate.