11. Release notes

This documentation corresponds to Loop version 1.99.1.20250102162327.d6e6dd4b1f.

Error

TODO: Write release notes here.

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

11.1.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.2. Loop branches

The following is information on current Loop branches.

Branch

Type

First release date

End-of-life date

1.99

Development

To be announced

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