ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2018-03-08T10:16:40Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/133Update util/check-changes to work on release branches.2018-03-08T10:16:40ZMark AndrewsUpdate util/check-changes to work on release branches.https://gitlab.isc.org/isc-projects/bind9/-/issues/76Setup a GitLab CI check for up-to-date copyright year2018-03-08T10:16:40ZOndřej SurýSetup a GitLab CI check for up-to-date copyright yearA GitLab CI check should fire before running the build to check whether all files are properly copyrighted. This would involve running `util/merge_copyrights` and bailing out when `util/copyrights` and `util/newcopyrights` differ.
This...A GitLab CI check should fire before running the build to check whether all files are properly copyrighted. This would involve running `util/merge_copyrights` and bailing out when `util/copyrights` and `util/newcopyrights` differ.
This will need to be merged to `9.11+` branches.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/128mkeys system test fails intermittently2018-03-08T13:09:18ZMichał Kępieńmkeys system test fails intermittentlyThe failure mode below has been observed once so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
```
S:mkeys:Tue Mar 6 07:42:47 UTC 2018
T:mkeys:1:A
A:mkeys:System test mkeys
I:mkeys:PORTRANGE:9600 - 9699
I:mkeys:check fo...The failure mode below has been observed once so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
```
S:mkeys:Tue Mar 6 07:42:47 UTC 2018
T:mkeys:1:A
A:mkeys:System test mkeys
I:mkeys:PORTRANGE:9600 - 9699
I:mkeys:check for signed record (1)
I:mkeys:check positive validation with valid trust anchor (2)
I:mkeys:check positive validation using delv (3)
I:mkeys:check for failed validation due to wrong key in managed-keys (4)
I:mkeys:check new trust anchor can be added (5)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check new trust anchor can't be added with bad initial key (6)
I:mkeys:ns3 refreshing managed keys for '_default'
I:mkeys:remove untrusted standby key, check timer restarts (7)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:restore untrusted standby key, revoke original key (8)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:refresh managed-keys, ensure same result (9)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:restore revoked key, ensure same result (10)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:reinitialize trust anchors, add second key to bind.keys
I:mkeys:check that no key from bind.keys is marked as an initializing key (11)
I:mkeys:reinitialize trust anchors, revert to one key in bind.keys
I:mkeys:check that standby key is now trusted (12)
I:mkeys:revoke original key, add new standby (13)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:revoke standby before it is trusted (14)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:wait 20 seconds for key add/remove holddowns to expire (15)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:revoke all keys, confirm roll to insecure (16)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check for insecure response (17)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:reset the root server
I:mkeys:reinitialize trust anchors
I:mkeys:check positive validation (18)
I:mkeys:revoke key with bad signature, check revocation is ignored (19)
I:mkeys:ns1 zone reload queued
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check validation fails with bad DNSKEY rrset (20)
I:mkeys:restore DNSKEY rrset, check validation succeeds again (21)
I:mkeys:ns1 zone reload queued
I:mkeys:reset the root server with no keys, check for minimal update (22)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:reset the root server with no signatures, check for minimal update (23)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:restore root server, check validation succeeds again (24)
I:mkeys:ns1 zone reload queued
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check that trust-anchor-telemetry queries are logged (25)
I:mkeys:check that trust-anchor-telemetry queries are received (26)
I:mkeys:check 'rndc-managed-keys destroy' (27)
I:mkeys:ns2 destroying managed-keys database for '_default'
I:mkeys:check that trust-anchor-telemetry queries contain the correct key (28)
I:mkeys:check initialization fails if managed-keys can't be created (29)
I:mkeys:check failure to contact root servers does not prevent key refreshes after restart (30)
I:mkeys:check key refreshes are resumed after root servers become available (31)
I:mkeys:exceeded time limit waiting for 'Returned from key fetch in keyfetch_done()' in ns5/named.run
I:mkeys:failed
I:mkeys:exit status: 1
R:mkeys:FAIL
E:mkeys:Tue Mar 6 07:44:44 UTC 2018
```
Contents of `bin/tests/system/mkeys/` [attached](/uploads/1d49120036975b1478ae848ad3bc0689/mkeys.tar.gz).BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/130Use ccache to speed-up Gitlab CI builds2018-03-08T14:22:12ZOndřej SurýUse ccache to speed-up Gitlab CI buildsOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/27Remove the extra RFC and I-D copies from BIND source distribution2018-03-08T16:08:15ZOndřej SurýRemove the extra RFC and I-D copies from BIND source distributionCopied from here: https://bugs.isc.org/Ticket/Display.html?id=46211
@marka Argues that it's handy to have a copies, but:
* We can have an extra repository and not distribute them in the BIND 9 source code
* We are missing erratas anywa...Copied from here: https://bugs.isc.org/Ticket/Display.html?id=46211
@marka Argues that it's handy to have a copies, but:
* We can have an extra repository and not distribute them in the BIND 9 source code
* We are missing erratas anyway
We should just make a list with the RFCs and I-D and explicitly declare which standards (and at what levels) we support.BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/111GitLab CI does not run unit tests2018-03-09T16:29:53ZMichał KępieńGitLab CI does not run unit testsGitLab CI currently `./configure`s BIND [without ATF support](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a6631f2db967d1a6331b5a177b78e08b89/.gitlab-ci.yml#L88), which prevents unit tests from being executed upon each CI run.
S...GitLab CI currently `./configure`s BIND [without ATF support](https://gitlab.isc.org/isc-projects/bind9/blob/e1d6c9a6631f2db967d1a6331b5a177b78e08b89/.gitlab-ci.yml#L88), which prevents unit tests from being executed upon each CI run.
Sadly, ATF is not widely packaged: in the case of Debian, which is of particular interest given that it is the only OS our CI setup uses right now, there have been [several](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766576) [attempts](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773277) to package ATF, but it looks like they did not end with ATF packages getting accepted into official Debian repositories.
Thus, we have two options:
* put a precompiled ATF release into in all of our Docker images (more work to prepare, but saves time upon each CI run),
* compile the ATF version shipped with BIND upon each CI run (easier, but a lot of CPU power goes to waste due to recompiling ATF code over and over).
I ruled out packaging ATF ourselves as I hardly doubt the benefits will outweigh the work we would need to put into it.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/138Tweak CI settings2018-03-09T17:13:27ZMichał KępieńTweak CI settingsOur current CI configuration has two issues described below.
# ccache is used ineffectively
`gitlab-runner` cache is effectively a ZIP file passed between jobs. Creating a ZIP archive containing a ccache directory, potentially contain...Our current CI configuration has two issues described below.
# ccache is used ineffectively
`gitlab-runner` cache is effectively a ZIP file passed between jobs. Creating a ZIP archive containing a ccache directory, potentially containing hundreds of thousands of files taking up several gigabytes of storage space is a bad idea.
Our current CI configuration also causes the ccache directory to be treated as a build artifact, which only makes things worse.
What we should do instead is to stop using the `cache` directive altogether, create a ccache directory on each runner and mount it inside containers. This will allow ccache data to persist between jobs without requiring it to be packed into a ZIP file at the end of each job.
As a side note for posterity, it is critical for `/etc/gitlab-runner/config.toml` to contain `volumes = ["/cache"]` for the `cache` directive to actually work, at least with Docker. Otherwise, `gitlab-runner` will just create a ZIP file when a job is finished, store it in `/cache/<namespace>/<project>` and then tear the container down, obliterating the cache it just created. Adding the `volume` line mentioned above causes `/cache` to be persisted.
# `make` uses fixed concurrency settings
Our CI jobs currently always use `make -j6` for building and `make -j8` for running system tests. Meanwhile, concurrency settings need to be tweaked separately for each runner to ensure stability. We should modify our `.gitlab-ci.yml` to fetch the number of parallel `make` jobs to use from environment variables which will subsequently be set by each runner through its configuration file.
There are three rules I can think of for tweaking concurrency-related settings:
1. With ccache being used, building becomes more (though not fully, of course) I/O-bound than CPU-bound.
1. As a rule of thumb, it should be assumed that each parallel system test being executed uses about 0.5 GB of RAM.
1. Currently, total system test execution time plateaus around `make -j8` because some tests just take a *long* time to run.
Apart from the above, the number of concurrent jobs `make` is allowed to use while building and testing has to be considered together with the `concurrent` setting in `/etc/gitlab-runner/config.toml` which limits the number of CI jobs allowed to be run concurrently at any time on a given runner.
Considering the above, an optimal CI machine would have:
* **8+ CPU cores**: 8 cores allow concurrent compilation for two OS images using `make -j4` without putting to much strain on the host (ccache storage is not infinite, so we cannot rely on everything being cached beforehand), which sounds like a bare minimum; more cores would enable quicker pipeline completion in case multiple branches and/or more OS images are to be processed concurrently,
* **fast storage** (or lots of RAM, so that ramdisks can be used for ccache data and/or compilation), to let ccache shine,
* **more than 8 GB of RAM**: with tests for two OS images running concurrently, each image using `make -j8`, top RAM utilization around 8 GB may occur (2 * 8 * 0.5), which would lead to swapping; the more RAM the machine has, the more concurrent test phase jobs (e.g. for different branches and/or different OS images) it will be able to handle (though more RAM itself will not cause system tests to complete faster because increasing the number of parallel jobs used while testing beyond 8 has virtually no effect).
In any case, there are a few trade-offs to consider here, so allowing runner-specific concurrency settings in our `.gitlab-ci.yml` sounds like a good idea no matter what machine(s) we will be using for CI in the end.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/143rndc command crashes bind-9.10.6-P1 - ev_ratelink.prev on Debian 92018-03-10T16:03:47ZGhost Userrndc command crashes bind-9.10.6-P1 - ev_ratelink.prev on Debian 9Good evening,
Running fresh install of Debian 9 (x64), named is running in background, but when issuing rndc status (any command really) it crashes with:
task.c:551: REQUIRE(!((void *)((event)->ev_ratelink.prev) != (void *)(-1))) faile...Good evening,
Running fresh install of Debian 9 (x64), named is running in background, but when issuing rndc status (any command really) it crashes with:
task.c:551: REQUIRE(!((void *)((event)->ev_ratelink.prev) != (void *)(-1))) failed, back trace
#0 0x7f2a69b070e4 in ??
#1 0x7f2a69b0704a in ??
#2 0x7f2a69b2c4aa in ??
#3 0x7f2a6a378cd8 in ??
#4 0x7f2a69b2a570 in ??
#5 0x7f2a69247494 in ??
#6 0x7f2a68f89aff in ??
Aborted
Here's the named -V dump:
BIND 9.10.6-P1 <id:f941e36>
running on Linux x86_64 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)
built by make with '--without-gost' '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--with-libtool' '--mandir=/usr/man' '--enable-shared' '--disable-static' '--with-libxml2=no' '--enable-threads' '--with-openssl' '--enable-developer'
compiled by GCC 6.3.0 20170516
compiled with OpenSSL version: OpenSSL 1.1.0f 25 May 2017
linked to OpenSSL version: OpenSSL 1.1.0f 25 May 2017
Obtained the core and dropped it through gdb and issued
thread apply all bt full
[gdb_dump.txt](/uploads/b3a791b04155edd8eacff57bccaf46f7/gdb_dump.txt)
I am able to install bind-9.10.6-P1 on a fresh install of Debian 8 (x64) with no problems.
Thank you for reviewing this.
Erichttps://gitlab.isc.org/isc-projects/bind9/-/issues/144CVE-2016-2776 and CVE-2015-46202018-03-13T14:39:26ZGhost UserCVE-2016-2776 and CVE-2015-4620Dear
The bind version we used is 9.10.0-P1.We want to fix the loophole(CVE-2016-2776 and CVE-2015-4620).and I have compared the changes between the problem version and fixed version.I can't ensure the specific modification points of the...Dear
The bind version we used is 9.10.0-P1.We want to fix the loophole(CVE-2016-2776 and CVE-2015-4620).and I have compared the changes between the problem version and fixed version.I can't ensure the specific modification points of the loopholes.Can you apply the the specific modification points of the loopholes(CVE-2016-2776 and CVE-2015-4620)?Please.
best regards!https://gitlab.isc.org/isc-projects/bind9/-/issues/65Request: rndc function to print zone content over rndc channel2018-03-13T14:48:48ZCarsten StrotmannRequest: rndc function to print zone content over rndc channelSometimes for scripting and debugging purposes it would be helpful to be able to obtain the content of a zone via "rndc" (in cases where zone transfer is restricted or turned off)
example:
```
$ rndc printzone example.com
example.com. ...Sometimes for scripting and debugging purposes it would be helpful to be able to obtain the content of a zone via "rndc" (in cases where zone transfer is restricted or turned off)
example:
```
$ rndc printzone example.com
example.com. 3600 IN SOA ns1.example.com. ...
example.com. 3600 IN NS ns1.example.com.
[...]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/63Request: BIND 9 control statement should allow address match list2018-03-13T14:49:02ZCarsten StrotmannRequest: BIND 9 control statement should allow address match listcurrently the BIND 9 control statement to configure the rndc channel takes a single IP-address, or "*" for "all addresses", to configure the interface the BIND 9 process should listen on rndc control messages.
it would be helpful in som...currently the BIND 9 control statement to configure the rndc channel takes a single IP-address, or "*" for "all addresses", to configure the interface the BIND 9 process should listen on rndc control messages.
it would be helpful in some situations to be able to control the interfaces for rndc more finegrained with an address match list (ACL)https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing/-/issues/4Open repository to the world2018-03-13T20:21:35ZMark AndrewsOpen repository to the worldhttps://gitlab.isc.org/isc-projects/bind9/-/issues/151arpaname segfault on OpenBSD 6.2 i3862018-03-15T18:55:12ZCarsten Strotmannarpaname segfault on OpenBSD 6.2 i386### Summary
the command "arpaname" segfaults and writes a core file when used
OpenBSD 6.2 i386 BIND 9.12.0
### Steps to reproduce
call arpaname with an ipv4 or ipv6 address
### What is the current *bug* behavior?
arpaname segfauls ...### Summary
the command "arpaname" segfaults and writes a core file when used
OpenBSD 6.2 i386 BIND 9.12.0
### Steps to reproduce
call arpaname with an ipv4 or ipv6 address
### What is the current *bug* behavior?
arpaname segfauls and writes a core dump file
```
# arpaname 2001:db8::1
Segmentation fault (core dumped)
```
### What is the expected *correct* behavior?
arpaname prints the arpaname of the ip address
### Relevant logs and/or screenshots
````
(gdb) bt
#0 malloc (size=65536) at /usr/src/lib/libc/stdlib/malloc.c:1165
#1 0x024efde9 in __smakebuf (fp=0x22453798) at /usr/src/lib/libc/stdio/makebuf.c:62
#2 0x024ef113 in __swsetup (fp=0x22453798) at /usr/src/lib/libc/stdio/wsetup.c:73
#3 0x024dccea in __vfprintf (fp=0x22453798, fmt0=0x358d8000 "%X.%X.", ap=0xcf7c2468 "\001") at /usr/src/lib/libc/stdio/vfprintf.c:461
#4 0x024dfabf in vfprintf (fp=0x22453798, fmt0=0x358d8000 "%X.%X.", ap=0xcf7c2468 "\001") at /usr/src/lib/libc/stdio/vfprintf.c:267
#5 0x024c08e9 in fprintf (fp=0x22453798, fmt=0x358d8000 "%X.%X.") at /usr/src/lib/libc/stdio/fprintf.c:45
#6 0x158d8d1d in main (argc=Cannot access memory at address 0x0
) at arpaname.c:38
````https://gitlab.isc.org/isc-projects/bind9/-/issues/162Remove idnkit-1.0 from BIND sources2018-03-17T13:15:03ZOndřej SurýRemove idnkit-1.0 from BIND sourcesThere's a local copy of outdated idnkit-1.0 library in BIND source. Let's just get rid of it (and cleanup relevant documentation).There's a local copy of outdated idnkit-1.0 library in BIND source. Let's just get rid of it (and cleanup relevant documentation).BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/123Support 64 RPZ zones by default from 9.13 onwards2018-03-18T10:25:34ZGhost UserSupport 64 RPZ zones by default from 9.13 onwardsSupport 64 RPZ zones by default from 9.13 onwards. Right now it's 32 or 64, and there doesn't seem to be any pressing need to have this choice going forward.Support 64 RPZ zones by default from 9.13 onwards. Right now it's 32 or 64, and there doesn't seem to be any pressing need to have this choice going forward.BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/44scan-build: Dead increment in multiple tests2018-03-18T11:14:07ZOndřej Surýscan-build: Dead increment in multiple testsllvm 5.0.0 scan-build reports Dead increment (Dead store) in bin/tests/system/pipelined/pipequeries.c, bin/tests/system/tkey/keydelete.c and bin/tests/system/pipelined/pipequeries.
Install full llvm (on Mac OS X: `brew install llvm --wi...llvm 5.0.0 scan-build reports Dead increment (Dead store) in bin/tests/system/pipelined/pipequeries.c, bin/tests/system/tkey/keydelete.c and bin/tests/system/pipelined/pipequeries.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/uploads/4d79cc3e65e3e30453dff492a830a443/scan-build-2017-12-18-110416-46298-1.zip) and run:
`scan-view scan-build-2017-12-18-110416-46298-1` (on Mac OS X `/usr/local/opt/llvm/scan-view scan-build-2017-12-18-110416-46298-1`)BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/43scan-build: Dead assignment in lib/ns/query.c2018-03-18T11:14:13ZOndřej Surýscan-build: Dead assignment in lib/ns/query.cllvm 5.0.0 scan-build reports Dead assignment in lib/ns/query.c in query_synthcnamewildcard function.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/uplo...llvm 5.0.0 scan-build reports Dead assignment in lib/ns/query.c in query_synthcnamewildcard function.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/uploads/4d79cc3e65e3e30453dff492a830a443/scan-build-2017-12-18-110416-46298-1.zip) and run:
`scan-view scan-build-2017-12-18-110416-46298-1` (on Mac OS X `/usr/local/opt/llvm/scan-view scan-build-2017-12-18-110416-46298-1`)BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/154Build failure on OSX with --disable-atomic --enable-developer2018-03-19T22:14:14ZCurtis BlackburnBuild failure on OSX with --disable-atomic --enable-developer<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
BIND9 fails to build on OSX with --disable-atomic and --enable developer
see output at: https://jenkins.isc.org/view/BIND/job/bind9-master-macmini--disable-atomic/513/console
### Steps to reproduce
$ ./configure --disable-atomic --without-zlib --with-atf=/Users/jenkins/opt/atf --with-openssl=/usr/local/opt/openssl/ --with-libxml2=/usr/local/opt/libxml2 --enable-full-report --enable-developer
$ make
### What is the current *bug* behavior?
atomic_test.c:319:16: error: unused parameter 'tp' [-Werror,-Wunused-parameter]
ATF_TP_ADD_TCS(tp) {
^
1 error generated.
make[3]: *** [atomic_test.o] Error 1
### What is the expected *correct* behavior?
a successful build
### Relevant configuration files
none
### Relevant logs and/or screenshots
see https://jenkins.isc.org/view/BIND/job/bind9-master-macmini--disable-atomic/513/console
### Possible fixes
we probably need an UNUSED(tp) on line 320 of atomic_test.cBIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/94Replace idnkit-1 support with idnkit-2 support (or drop it)2018-03-19T22:14:18ZOndřej SurýReplace idnkit-1 support with idnkit-2 support (or drop it)Currently, BIND doesn't compile with idnkit-2:
```
host.c:20:10: fatal error: 'idn/result.h' file not found
#include <idn/result.h>
^~~~~~~~~~~~~~
dighost.c:30:10: fatal error: 'idn/result.h' file not found
#include <idn/result...Currently, BIND doesn't compile with idnkit-2:
```
host.c:20:10: fatal error: 'idn/result.h' file not found
#include <idn/result.h>
^~~~~~~~~~~~~~
dighost.c:30:10: fatal error: 'idn/result.h' file not found
#include <idn/result.h>
^~~~~~~~~~~~~~
1 error generated.
```
and for IDNA2008 support, we need to either add support for [idnkit-2](https://jprs.co.jp/idn/index-e.html) or drop idnkit-1 support and leave only libidn2 support (!56). The only reason why to keep idnkit-2 would be the licensing. idnkit-2 is licensed under custom JPRS BSD-like (with additional restrictions) license, and libidn2 is LGPL3+ (for our purposes) licensed.BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/164Remove useless OpenSSL warning from configure script2018-03-19T22:14:23ZOndřej SurýRemove useless OpenSSL warning from configure scriptThere's a OpenSSL warning in `configure` script that's obsolete:
> The latest stable version is the 1.1.0 series. The 1.0.2 series is our Long Term Support (LTS) release, supported until 31st December 2019. The 0.9.8, 1.0.0 and 1.0.1 ve...There's a OpenSSL warning in `configure` script that's obsolete:
> The latest stable version is the 1.1.0 series. The 1.0.2 series is our Long Term Support (LTS) release, supported until 31st December 2019. The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support and should not be used.
and it should be removed as it is not BIND's place to teach users to update their system anyway.BIND-9.13.0Ondřej SurýOndřej Surý