ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-06-02T09:38:04Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1843kasp: Set correct keytimings2020-06-02T09:38:04ZMatthijs Mekkingmatthijs@isc.orgkasp: Set correct keytimingsWhile KASP (dnssec-policy) does not use the keytiming metadata to make decisions, this data is used by operators as an indication when certain key events will occur. Make sure the key times are set correctly and test them. Especially `S...While KASP (dnssec-policy) does not use the keytiming metadata to make decisions, this data is used by operators as an indication when certain key events will occur. Make sure the key times are set correctly and test them. Especially `SyncPublish` and `Removed` were neglected previously.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1842Correct the BIND ARM to say that the default session-key for use with 'update...2020-06-18T08:39:09ZCathy AlmondCorrect the BIND ARM to say that the default session-key for use with 'update-policy local;' is generated at startupThe BIND ARM says:
```
A pre-defined update-policy rule can be switched on with the command update-policy local;.
Switching on this rule in a zone causes named to generate a TSIG session key and place it in a file.
That key will then ...The BIND ARM says:
```
A pre-defined update-policy rule can be switched on with the command update-policy local;.
Switching on this rule in a zone causes named to generate a TSIG session key and place it in a file.
That key will then be allowed to update the zone, if the update request is sent from local- host.
By default, the session key is stored in the file /var/run/named/session.key; the key name
is "local-ddns" and the key algorithm is HMAC-SHA256. These values are configurable with the
session-keyfile, session-keyname and session-keyalg options, respectively).
```
This is not actually true - the session-key is generated when named starts up, irrespective of whether it's needed or not.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1841Test multiple SoftHSM versions in GitLab CI2020-06-04T12:16:14ZMichał KępieńTest multiple SoftHSM versions in GitLab CI@ondrej [suggested][1] that we should be testing multiple SoftHSM
versions in GitLab CI as algorithm support varies:
- SoftHSM < 2.6.0 lacks EdDSA support
- SoftHSM >= 2.6.0 has Ed25519 support
- SoftHSM >= 2.6.1 has Ed448 support...@ondrej [suggested][1] that we should be testing multiple SoftHSM
versions in GitLab CI as algorithm support varies:
- SoftHSM < 2.6.0 lacks EdDSA support
- SoftHSM >= 2.6.0 has Ed25519 support
- SoftHSM >= 2.6.1 has Ed448 support
[1]: https://mattermost.isc.org/isc/pl/xnbgms4n1tf3mnnm1a6tjwjseaJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1835Add the ability to parse and display Extended DNS Error code (EDE).2022-04-26T13:09:49ZMark AndrewsAdd the ability to parse and display Extended DNS Error code (EDE).Nnemonic EDE
Code point 15
15,Extended DNS Error,Standard,[RFC-ietf-dnsop-extended-error-16]Nnemonic EDE
Code point 15
15,Extended DNS Error,Standard,[RFC-ietf-dnsop-extended-error-16]June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1834IXFR of a new NSEC3 chain causes temporary performance drop2020-06-18T08:39:08ZEvan HuntIXFR of a new NSEC3 chain causes temporary performance dropWhen fully updating the NSEC3 chain for a large zone via IXFR, there is a temporary loss of performance on the secondary server when answering DO=1 queries for nonexistent data (in other words, queries that require returning NSEC3 data).When fully updating the NSEC3 chain for a large zone via IXFR, there is a temporary loss of performance on the secondary server when answering DO=1 queries for nonexistent data (in other words, queries that require returning NSEC3 data).June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1830Feature request: Adapt BIND cache management so that fetched RRsets with TTL=...2020-12-15T12:49:51ZCathy AlmondFeature request: Adapt BIND cache management so that fetched RRsets with TTL=0 use a different 'throw-away' cacheInspired by [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297)
The problem is the cache can get filled up with TTL=0 records, causing the resolver to 'grind to a halt.'
For BIND resolvers that routinely field...Inspired by [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297)
The problem is the cache can get filled up with TTL=0 records, causing the resolver to 'grind to a halt.'
For BIND resolvers that routinely field a large proportion of client queries that result in authoritative RRsets with TTL=0 (and we only have to look back at other reports where we've had problems making sure that TTL=0 content is handled properly and served solely to the clients making the query originally or which have been added to the fetch via clients-per-query before it has been complete, to know that these environments **do** exist...), can't we just avoid adding them to cache at all?
Suggestion:
A new TTL=0 cache
This would be used as a temporary storage place for *all* content that comes back with TTL=0 but which needs to persist for the lifetime of the client queries that are waiting for recursion to complete (so might include some intermediate fetch results as well as the answers needed for the client query responses. When serving responses to clients, use both main cache and TTL=0 cache. (OR perhaps there could be a way to flag to the tasks responding to clients that they should also look in TTL=0 cache when assembling the query response)
I would hope, given that the content is due to be thrown away as soon as all the clients have been responded to, that it might be easier to manage this in terms of access control than in main cache.
The big advantage to main cache, is that this content is kept out of it, thus reducing cache flux and cache maintenance overhead involved in adding and then cleaning up these non-persisting RRsets.
(Implementing this would also obviate the need to action #1829 )January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/1829Don't include RRsets with TTL=0 in when preserving cache content for use by t...2020-08-05T10:24:31ZCathy AlmondDon't include RRsets with TTL=0 in when preserving cache content for use by the serve-stale featurePer [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297), even if serve-stale functionality is disabled, versions of BIND that have this feature will still observe max-stale-ttl and maintain a cache of expired co...Per [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297), even if serve-stale functionality is disabled, versions of BIND that have this feature will still observe max-stale-ttl and maintain a cache of expired content in case of emergency. In an emergency, serve-stale can be toggled 'on' via rndc - in which case access to relatively recently expired cache content would be very desirable ('you don't know you want it until it's gone!').
However, it doesn't seem at all reasonable to apply this same logic to RRsets that have been received with TTL=0.
In BIND, they are added to cache because this is the way the BIND architecture works - with server side that corresponds with clients and a resolver-side that does back-end fetching and puts the answers in cache for retrieval, even if they're for single-use only (TTL=0).
I assert that authoritative providers of TTL=0 RRsets are doing so because these are dynamic answers and they do not want resolvers to cache them. So therefore it makes no sense at all to preserve them and serve them stale if the authoritative servers become unreachable. Depending on specific scenarios, retaining TTL=0 RRsets could also cause unexpected cache bloat.
Please can we address this in all versions of BIND that have serve-stale functionality in their cache management.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/268Detect incompatible Postgresql version2021-09-07T15:31:04ZThomas MarkwalderDetect incompatible Postgresql versionDuring initial environment setup I inadvertently pointed Stork to Postgresql 9.5. This apparently caused a SQL syntax error in the migrations code. IIRC it had something to with "AS", syntax error at or near "AS". I did not save the ...During initial environment setup I inadvertently pointed Stork to Postgresql 9.5. This apparently caused a SQL syntax error in the migrations code. IIRC it had something to with "AS", syntax error at or near "AS". I did not save the exact message. Upon pointing Stork to Postgresql 11 everything was fine.
It should be possible to detect the Postgresql version in the init db or migration logic and bail if it is too old. Barring that we might consider a more helpful failure message if possible.https://gitlab.isc.org/isc-projects/bind9/-/issues/1817named-checkzone: [-s (full|relative)] missing from usage.2020-05-15T12:29:10ZMark Andrewsnamed-checkzone: [-s (full|relative)] missing from usage.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1816include transport used in dig response (udp/tcp)2020-12-16T21:06:24ZAnand Buddhdevinclude transport used in dig response (udp/tcp)### Summary
BIND does not return a minimal response to an ANY query with the `minimal-any` option enabled.
### BIND version used
```
BIND 9.16.2 (Stable Release) <id:b310dc7>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP T...### Summary
BIND does not return a minimal response to an ANY query with the `minimal-any` option enabled.
### BIND version used
```
BIND 9.16.2 (Stable Release) <id:b310dc7>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/named' '--disable-static' '--with-pic' '--without-python' '--with-libtool' '--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named/named.conf
rndc configuration: /etc/named/rndc.conf
DNSSEC root key: /etc/named/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
1. Set up a BIND server with at least one zone (master, slave, doesn't matter)
2. Set `minimal-any` to `yes` in named.conf
3. Start the name server
4. Query this name server for zone/ANY over UDP
### What is the current *bug* behavior?
BIND returns all the records at the queried name
### What is the expected *correct* behavior?
I expect BIND to return only one RRset
### Relevant configuration files
n/a
### Relevant logs and/or screenshots
n/a
### Possible fixes
n/aNovember 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/1812Unexpected output from named-checkconf2020-06-18T08:39:09ZPeter DaviesUnexpected output from named-checkconfUnexpected output from named-checkconf:
When run "named-checkconf -p " appends extra test to server lines in static-stub zones
input:
zone "10.in-addr.arpa" { type static-stub; server-addresses { 199.81.216.126; 204.135.12.254; }; };
e...Unexpected output from named-checkconf:
When run "named-checkconf -p " appends extra test to server lines in static-stub zones
input:
zone "10.in-addr.arpa" { type static-stub; server-addresses { 199.81.216.126; 204.135.12.254; }; };
expected output:
zone "10.in-addr.arpa" {
type static-stub;
server-addresses {
199.81.216.126;
204.135.12.254;
};
};
received output:
zone "10.in-addr.arpa" {
type static-stub;
server-addresses {
199.81.216.126 dscp 4294950590;
204.135.12.254 dscp 4294950590;
};
This behaviour appears to start at release 9.11.6
see RT [#16328](https://support.isc.org/Ticket/Display.html?id=16328)June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/bind9/-/issues/1811Follow-up from "Don't set recv/send buffer sizes for udp sockets in netmgr."2020-05-05T12:59:18ZOndřej SurýFollow-up from "Don't set recv/send buffer sizes for udp sockets in netmgr."The following discussion from !3476 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3476#note_128851): (+1 comment)
> I would suggest killing the same code in th...The following discussion from !3476 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3476#note_128851): (+1 comment)
> I would suggest killing the same code in the old networking code.May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1810Refactor ecdsa and eddsa tests after testcrypto.sh changes2021-03-02T13:53:54ZOndřej SurýRefactor ecdsa and eddsa tests after testcrypto.sh changesBoth `ecdsa` and `eddsa` tests treat all algorithms in set as either all supported or all unsupported.
This makes it hard to incrementally add more algorithms and it also doesn't match reality (ED448 was added to OpenSSL much later than...Both `ecdsa` and `eddsa` tests treat all algorithms in set as either all supported or all unsupported.
This makes it hard to incrementally add more algorithms and it also doesn't match reality (ED448 was added to OpenSSL much later than ED25519).March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1808assertion failure in bind 9.16.22020-06-08T12:52:05ZOndřej Surýassertion failure in bind 9.16.2As reported to SO:
```
> Hello there,
>
> I'm running some dnsperf test against from in your testlab, and quite often i bind to crash with assertion failure.
>
> I'm running bind dnsperf with: dnsperf -f inet -t 10 -s <SANITIZED> -d...As reported to SO:
```
> Hello there,
>
> I'm running some dnsperf test against from in your testlab, and quite often i bind to crash with assertion failure.
>
> I'm running bind dnsperf with: dnsperf -f inet -t 10 -s <SANITIZED> -d dns_clear.txt -c 200 -T 4 -l 36000000 -q 5000 -S 1 (Attached dns_clear.txt, which is are reallife traffic dump from our prod bind servers). We're running CentOS Linux release 7.7.1908 (Core) in both test/prod.
>
> 29-Apr-2020 15:45:27.651 general: critical: netaddr.c:365: INSIST(0) failed, back trace
> 29-Apr-2020 15:45:27.651 general: critical: #0 0x42b890 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #1 0x7f033062cada in ??
> 29-Apr-2020 15:45:27.651 general: critical: #2 0x7f033064a3d3 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #3 0x7f033064fcc0 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #4 0x7f033064ff56 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #5 0x7f033195feaa in ??
> 29-Apr-2020 15:45:27.651 general: critical: #6 0x7f033187c448 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #7 0x7f0331972a40 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #8 0x7f0330652ada in ??
> 29-Apr-2020 15:45:27.651 general: critical: #9 0x7f032edc2e65 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #10 0x7f032e6cd88d in ??
> 29-Apr-2020 15:45:27.651 general: critical: exiting (due to assertion failure)
>
> I've several coredumps.. Do you guys have a place where i can upload them?
>
> [root@srv07 data]# ls -lh
> total 5.7G
> -rw-------. 1 named named 1.7G Apr 22 08:48 core.11065
> -rw-------. 1 named named 1.6G Apr 22 12:58 core.11877
> -rw-------. 1 named named 2.6G Apr 21 21:17 core.126377
> -rw-------. 1 named named 1.4G Apr 29 15:45 core.15168
> -rw-------. 1 named named 166M Apr 27 17:03 core.21234
> -rw-------. 1 named named 175M Apr 27 17:07 core.21301
> -rw-------. 1 named named 2.2G Apr 21 15:33 core.72474
>
> [root@srv07 log]# named -V
> BIND 9.16.2 (Stable Release) <id:b310dc7>
> running on Linux x86_64 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020
> built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS= -L/opt/isc/isc-bind/root/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
> compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
> compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
> linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
> compiled with libxml2 version: 2.9.1
> linked to libxml2 version: 20901
> compiled with json-c version: 0.11
> linked to json-c version: 0.11
> compiled with zlib version: 1.2.7
> linked to zlib version: 1.2.7
> compiled with protobuf-c version: 1.3.2
> linked to protobuf-c version: 1.3.2
> threads support is enabled
>
> default paths:
> named configuration: /etc/opt/isc/isc-bind/named.conf
> rndc configuration: /etc/opt/isc/isc-bind/rndc.conf
> DNSSEC root key: /etc/opt/isc/isc-bind/bind.keys
> nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
> named PID file: /var/opt/isc/isc-bind/run/named/named.pid
> named lock file: /var/opt/isc/isc-bind/run/named/named.lock
>
>
>
> [root@srv07 log]# ldd /opt/isc/isc-bind/root/usr/sbin/named
> linux-vdso.so.1 => (0x00007ffcc594a000)
> libns.so.1602 => /opt/isc/isc-bind/root/usr/lib64/libns.so.1602 (0x00007f8aa0acf000)
> libdns.so.1602 => /opt/isc/isc-bind/root/usr/lib64/libdns.so.1602 (0x00007f8aa06a6000)
> libbind9.so.1600 => /opt/isc/isc-bind/root/usr/lib64/libbind9.so.1600 (0x00007f8aa0493000)
> libisccfg.so.1600 => /opt/isc/isc-bind/root/usr/lib64/libisccfg.so.1600 (0x00007f8aa0261000)
> libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f8aa0014000)
> libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f8a9fd2b000)
> libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f8a9faf8000)
> libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f8a9f8f4000)
> libisccc.so.1600 => /opt/isc/isc-bind/root/usr/lib64/libisccc.so.1600 (0x00007f8a9f6ea000)
> libisc.so.1602 => /opt/isc/isc-bind/root/usr/lib64/libisc.so.1602 (0x00007f8a9f475000)
> libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f8a9f012000)
> libjson-c.so.2 => /lib64/libjson-c.so.2 (0x00007f8a9ee07000)
> libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f8a9ea9d000)
> libz.so.1 => /lib64/libz.so.1 (0x00007f8a9e887000)
> libcap.so.2 => /lib64/libcap.so.2 (0x00007f8a9e682000)
> libprotobuf-c.so.1 => /opt/isc/isc-bind/root/usr/lib64/libprotobuf-c.so.1 (0x00007f8a9e479000)
> libfstrm.so.0 => /opt/isc/isc-bind/root/usr/lib64/libfstrm.so.0 (0x00007f8a9e26e000)
> libuv.so.1 => /opt/isc/isc-bind/root/usr/lib64/libuv.so.1 (0x00007f8a9e03f000)
> librt.so.1 => /lib64/librt.so.1 (0x00007f8a9de37000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8a9dc1b000)
> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f8a9da01000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f8a9d7fd000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f8a9d42f000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f8aa0d16000)
> libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f8a9d21f000)
> libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f8a9d01b000)
> libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8a9ce02000)
> liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f8a9cbdc000)
> libm.so.6 => /lib64/libm.so.6 (0x00007f8a9c8da000)
> libattr.so.1 => /lib64/libattr.so.1 (0x00007f8a9c6d5000)
> libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f8a9c4ae000)
> libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f8a9c24c000)
```
The reporter is using our packages:
> We've installed bind directly from your CentOS repo; Do you still want us to send your debug symbols?
and the coredumps have been uploaded to my <SANITIZED>.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1807"named-checkconf -z" exit status reflects only the last view loaded2022-01-24T16:35:07ZGraham Clinch"named-checkconf -z" exit status reflects only the last view loaded<!--
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
When processing a named.conf with views, the exit status of 'named-checkconf -z' only reflects whether there were errors whilst loading the final view, even though all zones in all views are processed and errors printed as appropriate.
### BIND version used
```
BIND 9.16.2 (Stable Release) <id:b310dc7>
running on Darwin x86_64 19.4.0 Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64
built by make with '--prefix=/usr/local/Cellar/bind/9.16.2' '--with-json-c' '--with-openssl=/usr/local/opt/openssl@1.1' '--with-libjson=/usr/local/opt/json-c' '--with-python-install-dir=/usr/local/Cellar/bind/9.16.2/libexec/vendor/lib/python3.8/site-packages' '--with-python=/usr/local/opt/python@3.8/bin/python3' '--without-lmdb' 'CC=clang' 'PKG_CONFIG_PATH=/usr/local/opt/json-c/lib/pkgconfig:/usr/local/opt/libuv/lib/pkgconfig:/usr/local/opt/openssl@1.1/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig:/usr/local/opt/sqlite/lib/pkgconfig:/usr/local/opt/xz/lib/pkgconfig:/usr/local/opt/python@3.8/lib/pkgconfig' 'PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig/10.15'
compiled by CLANG 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.59)
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1g 21 Apr 2020
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /usr/local/Cellar/bind/9.16.2/etc/named.conf
rndc configuration: /usr/local/Cellar/bind/9.16.2/etc/rndc.conf
DNSSEC root key: /usr/local/Cellar/bind/9.16.2/etc/bind.keys
nsupdate session key: /usr/local/Cellar/bind/9.16.2/var/run/named/session.key
named PID file: /usr/local/Cellar/bind/9.16.2/var/run/named/named.pid
named lock file: /usr/local/Cellar/bind/9.16.2/var/run/named/named.lock
```
### Steps to reproduce
Given the configuration files listed later on, and intentionally creating an error by not creating a missing.net zone file:
Running named-checkconf -z against named-missing-last.conf gives an exit status of 1 as expected:
```
$ named-checkconf -d -z named-missing-last.conf
loading "example.net" from "example.net" class "IN"
zone example.net/IN: loaded serial 1
loading "missing.net" from "missing.net" class "IN"
zone missing.net/IN: loading from master file missing.net failed: file not found
zone missing.net/IN: not loaded due to errors.
missing/missing.net/IN: file not found
$ echo $?
1
```
Running named-checkconf -z against named-missing-first.conf should also give an exit status of 1, but does not:
```
$ named-checkconf -d -z named-missing-first.conf
loading "missing.net" from "missing.net" class "IN"
zone missing.net/IN: loading from master file missing.net failed: file not found
zone missing.net/IN: not loaded due to errors.
missing/missing.net/IN: file not found
loading "example.net" from "example.net" class "IN"
zone example.net/IN: loaded serial 1
$ echo $?
0
```
### What is the current *bug* behavior?
The exit status of named-checkconf -z reflects whether there was an error loading the zones in the *final* view.
### What is the expected *correct* behavior?
The exit status of named-checkconf -z should reflect whether there was an error loading the zones in *any* view.
### Relevant configuration files
named-missing-first.conf:
```
view "missing" {
zone "missing.net" {
type master;
file "missing.net";
};
};
view "example" {
zone "example.net" {
type master;
file "example.net";
};
};
```
named-missing-last.conf:
```
view "example" {
zone "example.net" {
type master;
file "example.net";
};
};
view "missing" {
zone "missing.net" {
type master;
file "missing.net";
};
};
```
example.net zone file:
```
$TTL 5
@ SOA ns1.example.net. hostmaster.example.net. 1 300 300 300 300
@ NS ns1.example.net.
ns1 A 127.0.0.1
```
*and no missing.net zone file*
### Possible fixes
bin/check/named-checkconf.c: load_zones_fromconfig() - 'result' (taken from 'tresult') variable appears to be reset by each call to configure_view.May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1805Save failed build artifacts.2021-08-26T04:24:18ZMark AndrewsSave failed build artifacts.If a build fails having the artifacts retrievable is useful.If a build fails having the artifacts retrievable is useful.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/1802Investigate and update the documentation on mirror zone update and validation...2021-06-22T21:03:27ZCathy AlmondInvestigate and update the documentation on mirror zone update and validation process when using IXFRFrom [Support Ticket #16268](https://support.isc.org/Ticket/Display.html?id=16268)
The documentation on the operation of mirror zones says:
```
A mirror zone acts like a zone of type secondary whose data is
subject to DNSSEC validatio...From [Support Ticket #16268](https://support.isc.org/Ticket/Display.html?id=16268)
The documentation on the operation of mirror zones says:
```
A mirror zone acts like a zone of type secondary whose data is
subject to DNSSEC validation before being used in answers.
Validation is performed during the zone transfer process (for both
AXFR and IXFR), and again when the zone file is loaded from
disk when named is restarted. If validation of a new version of a
mirror zone fails, a retransfer is scheduled and the most recent
correctly validated version of that zone is used until it expires; if a
newer version of that zone is later correctly validated, it replaces
the previously used version. If no usable zone data is available
for a mirror zone (either because it was never loaded from disk
and has not yet been transferred from a primary server or because
its most recent correctly validated version expired), traditional
DNS recursion will be used to look up the answers instead.
```
Also
```
Mirror zone validation always happens for the entire zone
contents, i.e. no "incremental validation" takes place, even for
IXFRs. This is required to ensure that each version of the zone
used by the resolver is fully self-consistent with respect to
DNSSEC. Other, more efficient zone verification methods may be
added in the future.
```
Note also that we're aware that the task that is handling the validation will never yield - this was intentional (validating the root zone should not take too long) as mentioned in issue #774
However, our suspicion is that an inbound update to a mirrored root zone that is performed as IXFR could be particularly poor on performance due to way each increment is applied.
Please could the behaviour of named when processing an inbound IXFR to a mirrored root zone be investigated, and, if necessary, optimised so as not to impede the functionality of a resolver's ability to simultaneously handle client queries with DNSSEC validation enabled.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/1798Reject master zones with DS records at the apex.2020-06-08T12:30:22ZMark AndrewsReject master zones with DS records at the apex.DS records belong to the parent zone and should never appear at the zone apex. Reject zones which have a DS record at the apex when loading if they are a master zone.
ISC's operations managed to do this.DS records belong to the parent zone and should never appear at the zone apex. Reject zones which have a DS record at the apex when loading if they are a master zone.
ISC's operations managed to do this.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/stork/-/issues/253paging bar elements are misaligned2022-02-04T09:12:02ZMichal Nowikowskipaging bar elements are misalignedThis happens on subnets page, but can appear on other pages too.
![image](/uploads/0868b4faf7b7acc94e4e19cf49173247/image.png)This happens on subnets page, but can appear on other pages too.
![image](/uploads/0868b4faf7b7acc94e4e19cf49173247/image.png)backlogMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/17829.16.x: listen-on-v6 { any; }; no longer works as documented on FreeBSD2020-06-08T12:28:11Zmsinatra9.16.x: listen-on-v6 { any; }; no longer works as documented on FreeBSD<!--
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
In 9.14.x running on FreeBSD, 'listen-on-v6 { any; )' functions as documented in the ARM:
When { any; } is specified as the address_match_list for the listen-on-v6 option, the server does not bind a separate socket to each IPv6 interface address as it does for IPv4 if the operating system has enough API support for IPv6 (specifically if it conforms to RFC 3493 and RFC 3542). Instead, it listens on the IPv6 wildcard address. If the system only has incomplete API support for IPv6,however, the behavior is the same as that for IPv4.
In 9.16.x, it does not function as documented.
9.14.x:
```
root@devns1:~ # fgrep listen-on-v6 /etc/namedb/named.conf
listen-on-v6 { any; };
root@devns1:~ # sockstat | grep named
bind named 44277 3 dgram -> /var/run/logpriv
bind named 44277 21 tcp6 *:53 *:*
bind named 44277 23 tcp4 127.0.0.1:53 *:*
bind named 44277 24 tcp4 127.0.0.1:953 *:*
bind named 44277 25 tcp6 ::1:953 *:*
bind named 44277 512 udp6 *:53 *:*
bind named 44277 514 udp4 127.0.0.1:53 *:*
```
9.16.1 (also verified on 9.16.2):
```
root@devns1:~ # fgrep listen-on-v6 /etc/namedb/named.conf
listen-on-v6 { any; };
root@devns1:~ # sockstat | grep named
bind named 617 27 udp6 ::1:53 *:*
bind named 617 28 tcp6 ::1:53 *:*
bind named 617 29 tcp6 ::1:53 *:*
bind named 617 30 udp6 fe80::1%lo0:53 *:*
bind named 617 31 tcp6 fe80::1%lo0:53 *:*
bind named 617 32 tcp6 fe80::1%lo0:53 *:*
bind named 617 33 udp4 127.0.0.1:53 *:*
bind named 617 34 tcp4 127.0.0.1:53 *:*
bind named 617 35 tcp4 127.0.0.1:53 *:*
bind named 617 36 tcp4 127.0.0.1:953 *:*
bind named 617 37 tcp6 ::1:953 *:*
```
### BIND version used
9.16.2 exhibits the bug:
```
BIND 9.16.2 (Stable Release) <id:b310dc7>
running on FreeBSD amd64 11.3-RELEASE-p7 FreeBSD 11.3-RELEASE-p7 #0: Tue Mar 17 08:32:23 UTC 2020 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd11.3' 'build_alias=amd64-portbld-freebsd11.3' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -Wl,-rpath,/usr/local/lib -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.0 (tags/RELEASE_800/final 356365)
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
1. System running FreeBSD 11.3-RELEASE or 12.1-RELEASE.
2. Install BIND916 either from ports (with default options).
3. Create an lo1 interface with (an) IPv6 address(es). We use lo1 for the service addresses of our anycast instances.
4. `ifconfig lo1 down`
5. Start named with a basic recursive or authoritative config, with `listen-on-v6 { any; };` configured.
6. `sockstat | grep named`. named will not be listening on the wildcard -nor- on the IPv6 addresses configured on lo1. This is because FreeBSD supports Enhanced DAD on all interfaces and marks all v6 addresses as 'tentative' until the interface comes up.
7. `ifconfig lo1 up`
8. `sockstat | grep named`. named is still not listening on lo1's IPv6 addresses.
9. Attempt to query the server on the IPv6 address on lo1. It will time out.
10. `rndc scan`
11. repeat steps 8 and 9. Still not listening on the lo1 addresses and not responding.
12. RESTART named. It is now listening on the new lo1 addresses.
With 9.14.x, queries to the new address do not time out because named is properly listening on the wildcard.
WORKAROUND:
`ifconfig lo1 no_dad`. This disables DAD processing on the loopback (not clear why you need it there anyway) and clears the `tentative` flag even if lo1 is down. named will listen explicitly on the IPv6 addresses whether lo1 is marked "UP" or "DOWN." Note that this does not work reliably on FreeBSD 11.3-RELEASE, but does work on 12.1-RELEASE.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecicki