Stork 2.0: Open Source DHCP Management Tool
ISC launched the Stork management application almost exactly five years ago, in November 2019, as an experimental tool.
Read postAs of BIND 9.13 and 9.14, BIND has adopted the “odd-unstable/even-stable” release numbering convention. BIND 9.14 contains new features added during the BIND 9.13 development process. Maintenance on the 9.14 branch will be limited to bug fixes and new feature development will proceed in the unstable 9.15 branch. [BIND-Announcement]
named.conf
.As a result of these changes, you may need to update your configuration to remove options no longer supported.
There are two known configuration issues with this release: this release will not build with “–with-dlopen=no” and named
will not load a configuration with “allow-update” and “allow-update-forwarding” at the global level. Both of these issues will be addressed in 9.14.1.
named
to serve a transferred copy of a zone’s contents without acting as an authority for the zone. This is designed for (and only for) serving a local copy of the DNS root zone. Development of this feature was sponsored by ICANN.We tested using the current head of each major stable branch currently supported, which includes 9.11, our Extended Support version; 9.12, the stable branch for 2018; and 9.14, the new stable branch for 2019.
The following performance profile was generated using ISC’s PerfLab software (available on GitHub). The zone files and scripts used are also in the PerfLab repository on GitHub. The figures are not a guide for the absolute performance you should expect to see in any specific deployment, but they show significant relative performance improvements in the more recent versions, compared to the BIND 9.11 version.
Comparison of Performance, measured as Queries Per Second, across 3 stable branches of BIND
Branch | BIND 9.11 | BIND 9.12 | BIND 9.14 |
---|---|---|---|
1k zones | 657 | 704 | 874 |
1M delegations | 526 | 642 | 712 |
1M RRs | 538 | 656 | 748 |
1M zones | 591 | 632 | 745 |
Recursive | 534 | 657 | 796 |
Root Zone | 64 | 363 | 404 |
Performance has improved across the board, for each of the scenarios modeled. The huge jump in performance for the Root Zone is due primarily to the addition of a glue cache. The improvement in the other scenarios is mainly due to refactoring of the network socket code that enabled named
to avoid context-switching (moving processing for a single query/response from one processor to another). Note that you will not observe this improvement if you test with dnsperf, because of some interaction between dnsperf and multi-threading support in BIND.
What's New from ISC