BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2018-11-13T19:07:18Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/587statistics-channels /xml/v2 is removed but still documented2018-11-13T19:07:18ZPetr Menšíkstatistics-channels /xml/v2 is removed but still documented<!--
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
ARM contains documentation of statistics-channels format of /xml/v2. But code does not allow such format anymore. Only /xml/v3 and /json/v1 are supported in code.
### BIND version used
BIND 9.11.4-RedHat-9.11.4-2.fc27
It seems present also in devel version
### Steps to reproduce
grep '/v2' -r doc
doc/arm/Bv9ARM.ch05.html: <a class="link" href="http://127.0.0.1:8888/xml/v2" target="_top">http://127.0.0.1:8888/xml/v2</a> for version 2
doc/arm/Bv9ARM-book.xml: <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://127.0.0.1:8888/xml/v2">http://127.0.0.1:8888/xml/v2</link> for version 2
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
Documents statistics format that cannot be configured.
### What is the expected *correct* behavior?
Do not mention format that is not available.
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/583Regression: Forward queries with forward only is no longer working2018-10-29T19:31:03ZGhost UserRegression: Forward queries with forward only is no longer working### Summary
Running the latest bind version (9.13.3) forwarding queries with the `forward only` option is no longer working.
Basically I have a split horizon DNS, using multiple bind instances running on multiple hosts. But I was able ...### Summary
Running the latest bind version (9.13.3) forwarding queries with the `forward only` option is no longer working.
Basically I have a split horizon DNS, using multiple bind instances running on multiple hosts. But I was able to identify the culprit to be the resolver, which was configured to forward queries for specific zones to an internal authoritative server, while answering all other queries the usual way.
This used to work fine with `9.13.1`, but when upgrading to `9.13.2`, this no longer works. It is still broken in `9.13.3`.
### BIND version used
Broken version (`9.13.2`):
```
BIND 9.13.2 (Development Release) <id:4f6ef2f>
running on Linux x86_64 4.14.72-1-lts #1 SMP Wed Sep 26 12:31:03 CEST 2018
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-ipv6' '--enable-filter-aaaa' '--enable-fixed-rrset' '--enable-seccomp' '--enable-full-report' '--with-python=/usr/bin/python' '--with-geoip' '--with-idn' '--with-openssl' '--with-libjson' '--with-libxml2' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 8.2.1 20180831
compiled with OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
linked to OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
compiled with libxml2 version: 2.9.8
linked to libxml2 version: 20908
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
```
Last version that used to work (`9.13.1`):
```
BIND 9.13.1 (Development Release) <id:5b71025>
running on Linux x86_64 4.14.72-1-lts #1 SMP Wed Sep 26 12:31:03 CEST 2018
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-ipv6' '--enable-filter-aaaa' '--enable-fixed-rrset' '--enable-seccomp' '--enable-full-report' '--with-python=/usr/bin/python' '--with-geoip' '--with-idn' '--with-openssl' '--with-libjson' '--with-libxml2' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 8.2.1 20180831
compiled with OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
linked to OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
compiled with libxml2 version: 2.9.8
linked to libxml2 version: 20908
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
```
### Steps to reproduce
- Configure bind in a way where queries for a particular zone are forwarded to a dedicated authoritative nameserver. Use the `forward only` option for this. I'm attaching my `named.conf` further down below in this bug report.
- Issue an query to the forwarded zone
- Bind will return with a `SERVFAIL`
### What is the current *bug* behavior?
Any queries for the `babioch.de` zone are answered with `SERVFAIL`, for instance:
```
dig @10.24.0.1 mail.babioch.de
; <<>> DiG 9.13.2 <<>> @10.24.0.1 mail.babioch.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10792
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d4edf146ddd092808c7e71535bb8bbfc46eaa07e7d222dfe (good)
;; QUESTION SECTION:
;mail.babioch.de. IN A
;; Query time: 18 msec
;; SERVER: 10.24.0.1#53(10.24.0.1)
;; WHEN: Sa Okt 06 15:43:24 CEST 2018
;; MSG SIZE rcvd: 72
```
### What is the expected *correct* behavior?
Queries for the `babioch.de` zone are correctly answered:
```
dig @10.24.0.1 mail.babioch.de
; <<>> DiG 9.13.1 <<>> @10.24.0.1 mail.babioch.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59672
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ce6833cdc8a7f26af62c368d5bb8bc443c63c9ba62ea9a7d (good)
;; QUESTION SECTION:
;mail.babioch.de. IN A
;; ANSWER SECTION:
mail.babioch.de. 300 IN A 10.24.0.20
;; Query time: 1 msec
;; SERVER: 10.24.0.1#53(10.24.0.1)
;; WHEN: Sa Okt 06 15:44:36 CEST 2018
;; MSG SIZE rcvd: 88
```
### Relevant configuration files
The stripped down version of my configuration, which still will trigger this regression, looks like this:
```
options {
listen-on port 53 { 127.0.0.1; 10.24.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
pid-file "/run/named/named.pid";
recursion yes;
allow-query { localhost; 10.24.0.0/16; };
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.zone";
zone "babioch.de" IN {
type forward;
forward only;
forwarders { 10.24.0.10; };
};
```
### Relevant logs and/or screenshots
The query log contains this:
```
Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670 127.0.0.1#51022 (mail.babioch.de): query: mail.babioch.de IN A +E(0)K (127.0.0.1)
Sep 30 01:33:31 kvm1.babioch.de named[16298]: client @0x7ff0c40ad670 127.0.0.1#51022 (mail.babioch.de): query failed (SERVFAIL) for mail.babioch.de/IN/A at query.c:10672
```
### Possible fixes
The line in question is handling stale answers [1]. I'm not entirely sure how this applies to my use-case, since nothing should be stale here.
Interestingly enough I can get it working, when I'm removing the
"forward only" directive from my configuration. This looks like this:
I was able to work around this with commenting out the `forward only` option, effectively falling back to `forward first`. This works in my case, but there might be setups, where this is not an option.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/v9_13_3/lib/ns/query.c#L10672BIND-9.13.4Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/579EdDSA support does not work with the final version of OpenSSL 1.1.12018-10-04T10:54:04ZMichał KępieńEdDSA support does not work with the final version of OpenSSL 1.1.1The `eddsa` system test consistently fails on any platform with OpenSSL 1.1.1 installed:
```
S:eddsa:Thu Oct 4 11:24:57 CEST 2018
T:eddsa:1:A
A:eddsa:System test eddsa
I:eddsa:PORTRANGE:5300 - 5399
dnssec-signzone: warning: EVP_DigestS...The `eddsa` system test consistently fails on any platform with OpenSSL 1.1.1 installed:
```
S:eddsa:Thu Oct 4 11:24:57 CEST 2018
T:eddsa:1:A
A:eddsa:System test eddsa
I:eddsa:PORTRANGE:5300 - 5399
dnssec-signzone: warning: EVP_DigestSignInit failed (failure)
dnssec-signzone: fatal: dnskey './ED25519/30149' failed to sign data: failure
dnssec-signzone: warning: EVP_DigestSignInit failed (failure)
dnssec-signzone: fatal: dnskey 'example.com/ED25519/3613' failed to sign data: failure
I:checking that positive validation works (0)
I:failed
I:checking that test vectors match (1)
grep: ns2/example.com.db.signed: No such file or directory
grep: ns2/example.com.db.signed: No such file or directory
grep: ns2/example.com.db.signed: No such file or directory
grep: ns2/example.com.db.signed: No such file or directory
I:failed
I:exit status: 2
R:eddsa:FAIL
E:eddsa:Thu Oct 4 11:24:59 CEST 2018
```
Since this [includes current Debian sid][1], the `eddsa` system test should first be disabled so that CI pipelines can pass and then BIND's EdDSA code should be fixed to work with the final version of OpenSSL 1.1.1.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/63060BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/574BIND 9.13.4 Release Checklist2018-11-22T14:28:48ZVicky Riskvicky@isc.orgBIND 9.13.4 Release Checklist## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generatio...## Release Checklist
- [x] Check for the presence of a milestone for the release
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist)
- [x] Prepare the sources for tarball generation
- [x] Change software version and library versions in configure.in
- [x] Update CHANGES
- [x] Ensure the release notes are correct for this release
- [x] Ensure the metainformation is correct for this release
- [x] Make sure the tests are passing
- [x] Create a tag (name vX_Y_Z[-alphatag], content BIND X.Y.Z[-alphatag], signed with a developer's GPG key): git tag -u <DEVELOPER_KEYID> -a -s -m "BIND X.Y.Z" vX.Y.Z
- [x] Push the changes and tag
- [x] Create the tarball
- [x] Create the Windows zips
- [x] Ask QA to sanity check the tarball and zips
- [x] Request the signature on the tarballs
- [x] Make tarballs and signatures available to download
- [ ] Edit the release https://gitlab.isc.org/isc-projects/bind9/tags and the NEWS snippet + links to the tarballs
- [ ] Update DEB and RPM packages
## Support
- [x] Inform support to upload to the web site (nice to give them a heads-up in advance)
- Write release e-mail to bind9-announce, bind-users in case of a major release
- Update tickets in case of waiting support customers
## Marketing
- [ ] Inform marketing to announce the release
- Post short note to Twitter
- Update http://en.wikipedia.org/wiki/BIND (mktg)
- Blog post if a major releaseBIND-9.13.42018-10-10https://gitlab.isc.org/isc-projects/bind9/-/issues/572Improve accuracy of query error logging2018-10-08T11:01:44ZMichał KępieńImprove accuracy of query error loggingThere are two issues related to query error logging that bug me:
1. Until BIND 9.11 (inclusive), when something goes wrong while recursing for an answer to a query, [the `default:` branch of a `switch` statement in `query_gotanswer()`]...There are two issues related to query error logging that bug me:
1. Until BIND 9.11 (inclusive), when something goes wrong while recursing for an answer to a query, [the `default:` branch of a `switch` statement in `query_gotanswer()`][1] generates a SERVFAIL response. When serve-stale was implemented in BIND 9.12, it was done in a way which causes that `default:` branch to only [set a flag (`want_stale`) in the query context][2] for such queries, effectively moving the `QUERY_ERROR()` call for such queries [to `query_done()`][3] (and making `query_done()` call itself recursively, which hinders readability). This may be a source of confusion[^1] as the "query failed" log messages now point at a line in `query_done()` which appears to have something to do with serve-stale (`if (qctx->want_stale)`) even if the latter is not enabled.
2. Apparently we are setting `qctx->result` to `DNS_R_SERVFAIL` for a lot of different failure modes:
```sh
$ sed -n 's|.*\(QUERY_ERROR([^)]*);\)$|\1|p;' lib/ns/query.c | sort | uniq -c | sort
2 QUERY_ERROR(qctx, DNS_R_DROP);
2 QUERY_ERROR(qctx, DNS_R_REFUSED);
4 QUERY_ERROR(qctx, result);
19 QUERY_ERROR(qctx, DNS_R_SERVFAIL);
```
In some situations, this really is the only sensible thing to do (e.g. when the root key sentinel mechanism overrides the RCODE or when the SERVFAIL cache is hit) but in most others, doing this feels like replacing potentially useful diagnostic information with a rather less useful "oops, something went wrong" type of message:
```
client @0x7fa62c0403b0 ::1#52563 (servfail.nl): query failed (SERVFAIL) for servfail.nl/IN/A at query.c:10681
```
While in some cases the root cause of failed queries is indicated by the preceding log messages, troubleshooting others requires recompiling BIND with `--enable-querytrace`, which is not always a viable option for the user.
I think we can improve `named`'s behavior in this regard. Note that the response message's RCODE is derived from `qctx->result` using `dns_result_torcode()`, which handles a number of possible `isc_result_t` values and returns SERVFAIL for anything not explicitly listed. If we used `QUERY_ERROR(qctx, result);` instead of `QUERY_ERROR(qctx, DNS_R_SERVFAIL);` where possible, the specific error could be logged by `query_error()` and the response's RCODE would still be SERVFAIL. The win here would be that some light could be shed on the less obvious query errors just by bumping the debug level using `rndc trace` (or enabling query logging) rather than recompiling with `--enable-querytrace`.
[^1]: see e.g. https://lists.isc.org/pipermail/bind-users/2018-September/100868.html, though the issue caught me by surprise a couple of times as well while debugging
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/c635b3175620ea085a8d2402afd446dfd95422bd/bin/named/query.c#L8571-8580
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/7b49de3a79e6597d42f8c3a69e55c8b01e47324d/lib/ns/query.c#L6675-6679
[3]: https://gitlab.isc.org/isc-projects/bind9/blob/7b49de3a79e6597d42f8c3a69e55c8b01e47324d/lib/ns/query.c#L10644BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/564Mirror zone configuration tweaks and cleanups2018-10-24T18:51:39ZMichał KępieńMirror zone configuration tweaks and cleanupsVarious discussions around mirror zones which happened after they were initially implemented (see #342, #375/!475, [Twitter poll](https://twitter.com/ISCdotORG/status/1007711763121356800)) indicate that certain aspects of mirror zone con...Various discussions around mirror zones which happened after they were initially implemented (see #342, #375/!475, [Twitter poll](https://twitter.com/ISCdotORG/status/1007711763121356800)) indicate that certain aspects of mirror zone configuration could use some tweaks:
* `type secondary; mirror yes;` should be replaced with `type mirror;`
* it should be clearly documented that:
* mirror zones are supposed to *replace* the configuration example provided by [RFC 7706](https://tools.ietf.org/html/rfc7706#appendix-B.1) rather than *augment* it,
* mirror zones only work the intended way if recursion is available in the view they are configured in,
* by default, outgoing transfers of mirror zones are disabled.
Furthermore:
* the list of valid mirror zone options should be trimmed down,
* NOTIFY configuration for mirror zones is a bit too hacky and could use some love,
* we currently do not test whether mirror zones can be added and removed dynamically (using `rndc`).
The above concerns need to be addressed before we release BIND 9.14 and since configuration changes are involved, BIND 9.13.4 would be the more appropriate target.BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/556Race condition in timer creation2018-09-27T19:59:31ZOndřej SurýRace condition in timer creationOriginally reported here: https://github.com/isc-projects/bind9/pull/2
```
A crash happened with the following call trace:
(gdb) thread 4
[Switching to thread 4 (LWP 1827)]
#0 __lll_unlock_wake () at ../sysdeps/unix/sysv/linux/x86_64/lo...Originally reported here: https://github.com/isc-projects/bind9/pull/2
```
A crash happened with the following call trace:
(gdb) thread 4
[Switching to thread 4 (LWP 1827)]
#0 __lll_unlock_wake () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:371
371 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
(gdb) bt
#0 __lll_unlock_wake () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:371
#1 0x00007f792dfe61f4 in __pthread_mutex_unlock_usercnt (mutex=mutex@entry=0x7f792f045028, decr=decr@entry=1) at pthread_mutex_unlock.c:55
#2 0x00007f792dfe62aa in __GI___pthread_mutex_unlock (mutex=mutex@entry=0x7f792f045028) at pthread_mutex_unlock.c:324
#3 0x00007f792e234f3e in isc__timer_create (manager0=0x7f792f045010, type=, expires=, interval=, task=,
action=, arg=0x55a04c063a50, timerp=0x55a04c063a88) at ../../../bind-9.10.3-P3/lib/isc/timer.c:485
#4 0x000055a04ac16610 in add_timeout (when=0x7ffea6082f90, where=0x7ffea6082fa0, what=0x0, ref=0xffffffff, unref=0x7f792f045028) at ../../dhcp-4.3.4/common/dispatch.c:354
#5 0x000055a04ac01cf1 in send_discover (cpp=0x55a04c063db0) at ../../dhcp-4.3.4/client/dhclient.c:2315
#6 0x000055a04abf8ac8 in main (argc=, argv=) at ../../dhcp-4.3.4/client/dhclient.c:795
(gdb) thread 1
[Switching to thread 1 (LWP 1828)]
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
58 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1 0x00007f792dc713fa in __GI_abort () at abort.c:89
#2 0x00007f792e20c7af in isc_assertion_failed (file=file@entry=0x7f792e252b60 "../../../bind-9.10.3-P3/lib/isc/timer.c", line=line@entry=1163,
type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7f792e2531f0 "timerp != ((void *)0) && ((*timerp) != ((void *)0) && (*timerp)->magic == (('A') << 24 | ('t') << 16 | ('m') << 8 | ('r')))")
at ../../../bind-9.10.3-P3/lib/isc/assertions.c:59
#3 0x00007f792e2358c1 in isc_timer_detach (timerp=timerp@entry=0x55a04c063a88) at ../../../bind-9.10.3-P3/lib/isc/timer.c:1163
#4 0x000055a04ac1625b in isclib_timer_callback (taskp=, eventp=0x7f792f04e130) at ../../dhcp-4.3.4/common/dispatch.c:179
#5 0x00007f792e22f64c in dispatch (manager=0x7f792f042010) at ../../../bind-9.10.3-P3/lib/isc/task.c:1130
#6 run (uap=0x7f792f042010) at ../../../bind-9.10.3-P3/lib/isc/task.c:1302
#7 0x00007f792dfe2464 in start_thread (arg=0x7f792d1d3700) at pthread_create.c:456
#8 0x00007f792dd24cef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
(gdb) print *(struct isc_timer **) 0x55a04c063a88
$15 = (struct isc_timer *) 0x0
```
The race condition is the timer elapses before isc__timer_create() returns the pointer to the caller.
Assigning the return pointer before enabling the timer will fix it.BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/525Cleanup platform.h for stuff not exposed to the headers2019-07-01T15:12:44ZOndřej SurýCleanup platform.h for stuff not exposed to the headersThe `platform.h` header contains some defines that are actually not exposed to the outside, but used only internally. Those should be moved into `config.h`.The `platform.h` header contains some defines that are actually not exposed to the outside, but used only internally. Those should be moved into `config.h`.BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/427Zones are not listed in the web interface2018-10-25T08:39:27ZMichał KępieńZones are not listed in the web interfaceThe XSL stylesheet used by the web interface does not currently include any element which would cause a list of zones configured in each view to be displayed, making the *"Zones"* section of the web interface empty unless some zone has b...The XSL stylesheet used by the web interface does not currently include any element which would cause a list of zones configured in each view to be displayed, making the *"Zones"* section of the web interface empty unless some zone has been configured with `zone-statistics full;` and queried. This can be confusing.BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/388dnssec-enable and dnssec-validation ARM documentation2018-10-05T06:41:57ZRay Bellisdnssec-enable and dnssec-validation ARM documentationBased on the 9.13.2 version of the ARM, it says that `dnssec-enable` is required to be set to `yes` for DNSSEC validation to occur.
This does not appear to be the case (seen on my own resolver running `version: BIND 9.13.2 (Development ...Based on the 9.13.2 version of the ARM, it says that `dnssec-enable` is required to be set to `yes` for DNSSEC validation to occur.
This does not appear to be the case (seen on my own resolver running `version: BIND 9.13.2 (Development Release) <id:4f6ef2f3e5>`, verified by @michal).
It also says that the default value of `dnssec-validation` is `yes`, but I understand that it is now actually `auto`.BIND-9.13.4Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/375Root zone mirroring - confusing ACLs2018-10-24T18:51:40ZTony FinchRoot zone mirroring - confusing ACLsI have an RFC 7706-style configuration on my test server (config below) - I have separate `auth` and `rec` views, and the root zone is in the `auth` view and validated by the `rec` view.
I thought I should try out mirror mode, to valida...I have an RFC 7706-style configuration on my test server (config below) - I have separate `auth` and `rec` views, and the root zone is in the `auth` view and validated by the `rec` view.
I thought I should try out mirror mode, to validate earlier.
I added `mirror yes` to the root zone config and restarted the server.
I tried `dig soa .` and I got a SERVFAIL - the `auth` view REFUSED the query. I tried adding `::1` to the `allow-recursion` ACL (which I thought should also affect the `allow-query-cache` ACL) but queries were still REFUSED.
I removed `mirror yes` and ran `rndc reconfig`, but I still got SERVFAIL errors, so I had to restart the server.
It isn't clear to me why this didn't work or which ACL was the problem.
```
acl "cudn" {
128.232.0.0/16;
129.169.0.0/16;
131.111.0.0/16;
192.18.195.0/24;
192.84.5.0/24;
192.153.213.0/24;
193.60.80.0/20;
193.63.252.0/23;
2001:630:210::/44;
2a00:1098:5::/48;
2a05:b400::/32;
!172.31.0.0/16;
172.16.0.0/12;
10.128.0.0/9;
127.0.0.1/32;
::1/128;
};
logging {
channel "log" {
file "/log/named.log" versions 10 size 104857600;
severity dynamic;
print-time iso8601;
print-severity yes;
print-category yes;
};
category "default" {
"log";
};
};
masters "ucam" {
2001:630:212:8::d:a0;
131.111.8.37;
2001:630:212:12::d:a1;
131.111.12.37;
};
masters "ucam-rec" {
2001:630:212:8::d:0;
131.111.8.42;
2001:630:212:12::d:1;
131.111.12.20;
};
options {
blackhole {
131.111.12.49/32;
2001:630:212:12:250:56ff:fe90:7ed7/128;
};
directory "/var/opt/bind/run";
dnstap-output file"dnstap";
querylog yes;
server-id hostname;
deny-answer-addresses {
0.0.0.0/8;
10.0.0.0/8;
100.64.0.0/10;
127.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.0.0.0/24;
192.0.2.0/24;
192.88.99.0/24;
192.168.0.0/16;
198.18.0.0/15;
198.51.100.0/24;
203.0.113.0/24;
224.0.0.0/3;
::/3;
2001::/32;
2001:2::/48;
2001:10::/28;
2001:db8::/32;
2002::/16;
3000::/4;
4000::/2;
8000::/1;
} except-from {
"private.cam.ac.uk";
};
deny-answer-aliases {
"private.cam.ac.uk";
} except-from {
"private.cam.ac.uk";
};
dnssec-validation auto;
dnstap {
all;
};
empty-contact "root.localhost";
empty-server "localhost";
max-stale-ttl 3600;
no-case-compress {
"any";
};
rate-limit {
exempt-clients {
"cudn";
};
responses-per-second 2;
};
request-nsid yes;
rrset-order {
order random;
};
stale-answer-enable yes;
allow-query {
"cudn";
};
allow-transfer {
"cudn";
};
dnssec-dnskey-kskonly yes;
notify master-only;
zone-statistics full;
};
statistics-channels {
inet 0.0.0.0 port 8053 allow {
"cudn";
};
inet :: port 8053 allow {
"cudn";
};
};
view "rec" {
match-clients {
"cudn";
};
match-recursive-only yes;
zone "block.arpa.cam.ac.uk" {
type slave;
file "/zs/block.arpa.cam.ac.uk";
masters {
"ucam-rec";
};
};
zone "passthru.arpa.cam.ac.uk" {
type slave;
file "/zs/passthru.arpa.cam.ac.uk";
masters {
"ucam-rec";
};
};
zone "test.rpz.dotat.at" {
type master;
file "../zd/test.rpz.dotat.at/master";
journal "../zd/test.rpz.dotat.at/journal";
update-policy local;
allow-query {
"any";
};
allow-transfer {
"any";
};
masterfile-format raw;
};
zone "cb4.eu" {
type static-stub;
server-addresses {
::1;
};
};
zone "dotat.at" {
type static-stub;
server-addresses {
::1;
};
};
zone "ed25519.dotat.at" {
type static-stub;
server-addresses {
::1;
};
};
zone "no-dnssec.dotat.at" {
type static-stub;
server-addresses {
::1;
};
};
zone "fanf2.ucam.org" {
type static-stub;
server-addresses {
::1;
};
};
zone "dev.dns.cam.ac.uk" {
type static-stub;
server-addresses {
::1;
};
};
zone "catz.arpa.cam.ac.uk" {
type static-stub;
server-addresses {
::1;
};
};
zone "10.in-addr.arpa" {
type static-stub;
server-addresses {
::1;
};
};
zone "." {
type static-stub;
server-addresses {
::1;
};
};
zone "83.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "18.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "84.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "253.63.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "0.0.4.b.5.0.a.2.ip6.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "cst.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "93.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "24.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "195.18.192.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "statslab.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "eng.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "88.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "in-addr.arpa.private.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "2.0.2.1.2.0.0.3.6.0.1.0.0.2.ip6.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "16.111.131.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "private.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "maths.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "26.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "169.129.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "23.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "5.84.192.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "dpmms.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "87.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "90.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "5.0.0.0.8.9.0.1.0.0.a.2.ip6.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "29.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "24.111.131.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "85.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "19.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "232.128.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "145.111.131.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "18.111.131.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "25.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "80.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "damtp.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "94.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "21.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "92.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "16.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "cl.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "89.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "1.2.0.0.3.6.0.1.0.0.2.ip6.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "in-addr.arpa.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "111.131.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "86.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "252.63.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "91.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "27.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "95.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "81.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "20.111.131.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "newton.cam.ac.uk." {
type static-stub;
server-addresses {
::1;
};
};
zone "213.153.192.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "20.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "22.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "17.111.131.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "28.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "17.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "30.172.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
zone "82.60.193.in-addr.arpa." {
type static-stub;
server-addresses {
::1;
};
};
minimal-responses no-auth-recursive;
response-policy {
zone "test.rpz.dotat.at";
zone "passthru.arpa.cam.ac.uk" policy passthru;
zone "block.arpa.cam.ac.uk" policy cname "ipreg.rpz.dotat.at";
} break-dnssec yes max-policy-ttl 300 qname-wait-recurse no;
};
view "auth" {
key "_acme-challenge.dotat.at" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "dev.dns.cam.ac.uk" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "tsig-fanf" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
zone "cb4.eu" {
type master;
file "../zd/cb4.eu/master";
journal "../zd/cb4.eu/journal";
update-policy local;
allow-query {
"any";
};
allow-transfer {
"any";
};
also-notify {
91.221.196.11;
};
auto-dnssec maintain;
key-directory "../zd/cb4.eu";
masterfile-format raw;
sig-validity-interval 10 8;
};
zone "dotat.at" {
type master;
file "../zd/dotat.at/master";
journal "../zd/dotat.at/journal";
update-policy {
grant "local-ddns" zonesub "any";
grant "_acme-challenge.dotat.at" self "_acme-challenge.dotat.at" "TXT";
};
allow-query {
"any";
};
allow-transfer {
"any";
};
also-notify {
91.221.196.11;
};
auto-dnssec maintain;
key-directory "../zd/dotat.at";
masterfile-format raw;
sig-validity-interval 10 8;
};
zone "ed25519.dotat.at" {
type master;
file "../zd/ed25519.dotat.at/master";
journal "../zd/ed25519.dotat.at/journal";
update-policy local;
allow-query {
"any";
};
allow-transfer {
"any";
};
auto-dnssec maintain;
key-directory "../zd/ed25519.dotat.at";
masterfile-format raw;
sig-validity-interval 10 8;
};
zone "no-dnssec.dotat.at" {
type master;
file "../zd/no-dnssec.dotat.at/master";
journal "../zd/no-dnssec.dotat.at/journal";
update-policy local;
allow-query {
"any";
};
allow-transfer {
"any";
};
auto-dnssec maintain;
dnssec-secure-to-insecure yes;
key-directory "../zd/no-dnssec.dotat.at";
masterfile-format raw;
};
zone "fanf2.ucam.org" {
type master;
file "../zd/fanf2.ucam.org/master";
journal "../zd/fanf2.ucam.org/journal";
update-policy local;
allow-query {
"any";
};
allow-transfer {
"any";
};
auto-dnssec maintain;
dnssec-loadkeys-interval 10;
dnssec-secure-to-insecure yes;
key-directory "../zd/fanf2.ucam.org";
masterfile-format raw;
sig-signing-nodes 10;
sig-signing-signatures 2;
sig-validity-interval 1 23;
};
zone "dev.dns.cam.ac.uk" {
type master;
file "../zd/dev.dns.cam.ac.uk/master";
journal "../zd/dev.dns.cam.ac.uk/journal";
allow-query {
"any";
};
allow-transfer {
"localhost";
key "tsig-fanf";
};
allow-update {
key "local-ddns";
key "dev.dns.cam.ac.uk";
};
auto-dnssec maintain;
key-directory "../zd/dev.dns.cam.ac.uk";
masterfile-format raw;
sig-validity-interval 10 8;
};
zone "catz.arpa.cam.ac.uk" {
type slave;
file "../zs/catz.arpa.cam.ac.uk";
masters {
"ucam";
};
allow-query {
"cudn";
};
};
zone "10.in-addr.arpa" {
type slave;
file "../zs/10.in-addr.arpa";
masters {
"ucam";
};
allow-query {
"cudn";
};
};
zone "." {
type slave;
file "../zs/root";
masters {
2001:7fd::1;
193.0.14.129;
};
also-notify {
127.0.0.1 port 5300;
};
max-refresh-time 512;
max-retry-time 512;
notify explicit;
};
allow-recursion {
"none";
};
catalog-zones {
zone "catz.arpa.cam.ac.uk" zone-directory "../zs";
};
max-udp-size 1400;
minimal-any yes;
minimal-responses yes;
recursion no;
};
server 0.0.0.0/8 {
bogus yes;
};
server 10.0.0.0/8 {
bogus yes;
};
server 100.64.0.0/10 {
bogus yes;
};
server 127.0.0.0/8 {
bogus yes;
};
server 169.254.0.0/16 {
bogus yes;
};
server 172.16.0.0/12 {
bogus yes;
};
server 192.0.0.0/24 {
bogus yes;
};
server 192.0.2.0/24 {
bogus yes;
};
server 192.88.99.0/24 {
bogus yes;
};
server 192.168.0.0/16 {
bogus yes;
};
server 198.18.0.0/15 {
bogus yes;
};
server 198.51.100.0/24 {
bogus yes;
};
server 203.0.113.0/24 {
bogus yes;
};
server 224.0.0.0/3 {
bogus yes;
};
server ::/3 {
bogus yes;
};
server 2001::/32 {
bogus yes;
};
server 2001:2::/48 {
bogus yes;
};
server 2001:10::/28 {
bogus yes;
};
server 2001:db8::/32 {
bogus yes;
};
server 2002::/16 {
bogus yes;
};
server 3000::/4 {
bogus yes;
};
server 4000::/2 {
bogus yes;
};
server 8000::/1 {
bogus yes;
};
server ::1/128 {
bogus no;
};
server 172.16.3.0/24 {
bogus no;
};
server 113.209.232.218/32 {
send-cookie no;
};
server 157.83.102.245/32 {
send-cookie no;
};
server 157.83.102.246/32 {
send-cookie no;
};
server 157.83.126.245/32 {
send-cookie no;
};
server 157.83.126.246/32 {
send-cookie no;
};
server 2001:428::7/128 {
send-cookie no;
};
server 2001:428::8/128 {
send-cookie no;
};
server 208.44.130.121/32 {
send-cookie no;
};
server 43.242.49.158/32 {
send-cookie no;
};
server 63.150.72.5/32 {
send-cookie no;
};
```BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/342[Poll] How should root zone mirroring be configured?2018-10-24T18:51:40ZMichał Kępień[Poll] How should root zone mirroring be configured?This issue is a spin-off of #33/!329 that aims to facilitate discussion on whether `named` should mirror the root zone by default and if not, what the configuration syntax for enabling it should look like.
I will create a separate discu...This issue is a spin-off of #33/!329 that aims to facilitate discussion on whether `named` should mirror the root zone by default and if not, what the configuration syntax for enabling it should look like.
I will create a separate discussion below for each option that has been proposed so far. If you like one of them more than the others, please vote for it using the :thumbsup: reaction. I imagine we will be able to come to a decision without resorting to negative votes, but if you feel strongly about one of the options, knock yourself out!
Unless it turns out to be unanimous, I do not expect this poll to be binding in any way, I would just like to know people's thoughts on the subject.
Options below will be presented in no specific order. Feel free to add your own idea by starting a new discussion.BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/305Refactor message digest functions2023-03-16T11:03:02ZOndřej SurýRefactor message digest functionsThere's a lot of duplicate code in MD routines that needs to be simplified.
Related to #175There's a lot of duplicate code in MD routines that needs to be simplified.
Related to #175BIND-9.13.4Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/150Remove workarounds for servers that are not EDNS compliant.2019-09-04T23:48:20ZMark AndrewsRemove workarounds for servers that are not EDNS compliant.BIND-9.13.4Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/105[RT#44623] RNDC NTA option to add NTA to all views2018-09-10T19:15:35ZVicky Riskvicky@isc.org[RT#44623] RNDC NTA option to add NTA to all viewsDear ISC,
The rndc [1] command to add a negative trust anchor (nta) only adds the
domain name to the default or specified view:
nta [( -d | -f | -r | -l duration)] domain [view]
I would find it useful, if the default option is to add ...Dear ISC,
The rndc [1] command to add a negative trust anchor (nta) only adds the
domain name to the default or specified view:
nta [( -d | -f | -r | -l duration)] domain [view]
I would find it useful, if the default option is to add it to all views.
Our current work around for this missing feature is that we connect to
the statistics server and list the view names and execute the rndc nta
command multiple times. I don't think this is a good solution.
[1 ]https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/man.rndc.html
Thank you,
Daniel
"Daniel Stirnimann" <daniel.stirnimann@switch.ch>BIND-9.13.4https://gitlab.isc.org/isc-projects/bind9/-/issues/773BIND 9.13.5 Release2018-12-13T05:21:46ZOndřej SurýBIND 9.13.5 Release## Release Checklist
- [x] (Manager) Check for the presence of a milestone for the release:
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist).
- [x] (Manager) Inform Support/Mark...## Release Checklist
- [x] (Manager) Check for the presence of a milestone for the release:
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist).
- [x] (Manager) Inform Support/Marketing of impending release (and give estimated release dates).
- (SwEng) Prepare the sources for tarball generation:
- [x] Check perflab to ensure there has been no unexplained drop in performance for the version being released.
- [x] Ensure that there are no outstanding merge requests in the private repository (subscription version only).
- [x] Update API files for libraries with new version information.
- [x] Change software version and library versions in configure.in (new major release only).
- [x] Rebuild configure using autoconf on docs.isc.org.
- [x] Update CHANGES.
- [x] Update "version".
- [x] Update "readme.md".
- Check the release notes are correct:
- [ ] Compare content with merge requests for the release.
- [ ] Check formatting.
- [x] Build documentation on docs.isc.org.
- [x] Commit changes and make sure the gitlab-ci tests are passing.
- [x] Push the changes and tag ("alphatag" is an optional string such as "b1", "rc1" etc.). (```git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]```)
- [ ] If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` (this allows development to continue on the release branch whilst release engineering continues).
- [x] (SwEng) Run the "make release" Jenkins job to produce the tarballs and zips.
- [x] (SwEng) Ask QA to sanity check the tarball and zips (passing to them the number of the Jenkins job).
- [x] (QA) Sanity check the tarballs.
- [x] (QA) Request the signature on the tarballs.
- [ ] (QA) Check signatures on tarballs.
- [ ] (QA) Tell Support to handle notification of release.
- [x] (Manager) Inform Marketing of the release
- [x] (Manager) Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [ ] (SwEng) Update DEB and RPM packages
- [ ] (SwEng) Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`)
## Support
- [x] Make tarballs and signatures available to download.
- [x] Write release email to bind9-announce.
- [ ] Write email to bind9-users (if a major release).
- [x] Update tickets in case of waiting support customers.
## Marketing
- [x] Post short note to Twitter.
- [x] Update [Wikipedia entry for BIND](http://en.wikipedia.org/wiki/BIND).
- [x] Write blog article (if a major release). (I would love a blog from Witold on the networking refactoring, but I don't have it and can't make it up)BIND-9.13.5Curtis BlackburnCurtis Blackburnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/744Fix a race in socket code2018-12-05T12:19:33ZWitold KrecickiFix a race in socket codein socket.c we have:
```
if (SOCK_DEAD(sock)) { /* Sock is being closed, bail */
goto unlock_fd;
}
isc_refcount_increment(&sock->references);
```
However, if between SOCK_DEAD and isc_refcount_inc...in socket.c we have:
```
if (SOCK_DEAD(sock)) { /* Sock is being closed, bail */
goto unlock_fd;
}
isc_refcount_increment(&sock->references);
```
However, if between SOCK_DEAD and isc_refcount_increment something will close the socket (decreasing refcount to 0) we'll have an ugly race.
The proper way to fix it should be to hold a reference for socket in thread->fds[fd].BIND-9.13.5Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/732BIND 9.13.4 does not compile on CentOS 6 (i386)2018-11-26T10:22:36ZMichał KępieńBIND 9.13.4 does not compile on CentOS 6 (i386)Commit 22e5231f99ceac8371ac0e74a114df64aa3fc868 [causes the `_mm_pause()` intrinsic to be used on i386 machines][1]. Newer toolchains seem to be fine with this; the stock one available on CentOS 6 for i386 - [not so much][2].
[1]: http...Commit 22e5231f99ceac8371ac0e74a114df64aa3fc868 [causes the `_mm_pause()` intrinsic to be used on i386 machines][1]. Newer toolchains seem to be fine with this; the stock one available on CentOS 6 for i386 - [not so much][2].
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/ad0b4e9d416a7802904eef235a55fb07a36743bb/lib/isc/rwlock.c#L47-49
[2]: https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/epel-6-i386/00828410-isc-bind/builder-live.logBIND-9.13.5Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/730Python module installation is broken in BIND 9.13.42019-01-31T07:42:20ZMichał KępieńPython module installation is broken in BIND 9.13.4The fix for #601 introduced by !980 breaks Python module installation due to setting `PYTHON_INSTALL_DIR` and `PYTHON_INSTALL_LIB` to `unspec` and `--install-dir=unspec`, respectively, when `--with-python-install-dir` is not used.
This ...The fix for #601 introduced by !980 breaks Python module installation due to setting `PYTHON_INSTALL_DIR` and `PYTHON_INSTALL_LIB` to `unspec` and `--install-dir=unspec`, respectively, when `--with-python-install-dir` is not used.
This prevents BIND 9.13.4 packages with Python support from being built:
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/epel-7-ppc64le/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/epel-7-x86_64/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-27-i386/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-27-ppc64le/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-27-x86_64/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-28-i386/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-28-ppc64le/00827985-isc-bind/builder-live.log
* https://copr-be.cloud.fedoraproject.org/results/isc/bind-dev/fedora-28-x86_64/00827985-isc-bind/builder-live.log
I implemented a [workaround][1] in the `*.spec` file to fix RPM builds but this problem should be properly addressed in the BIND repository.
[1]: https://gitlab.isc.org/isc-packages/rpms/bind/commit/f1a57c873729d145f7ce72315120d6e37a7a8980BIND-9.13.5Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/716remove logically dead code try #22018-11-22T22:17:44ZMark Andrewsremove logically dead code try #214438
cond_const: Condition is_option, taking true branch. Now the value of is_option is equal to 1.
const: At condition is_option, the value of is_option must be equal to 1.
dead_error_condition: The condition !is_opti...14438
cond_const: Condition is_option, taking true branch. Now the value of is_option is equal to 1.
const: At condition is_option, the value of is_option must be equal to 1.
dead_error_condition: The condition !is_option cannot be true.
14439 if (!is_option) {
CID 1441449 (#1 of 1): Logically dead code (DEADCODE)
dead_error_line: Execution cannot reach this statement: nametext = ptr;.
14440 nametext = ptr;BIND-9.13.5Mark AndrewsMark Andrews