bind 9.14.8 and 9.14.9 aborts when queried for non-existing domain in chaos class

Summary

Bind 9.14.8 and 9.14.9 get killed by signal 6 (SIGABRT on FreeBSD) due to an assertion in name.c:2174 when queried for any non-existing RR in the CH class if you manually configured a view CHAOS in named.conf

BIND version used

BIND 9.14.9 (Stable Release) <id:623e23e>
running on FreeBSD amd64 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC
built by make with '--localstatedir=/var' '--disable-linux-caps' '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlopen=yes' '--with-openssl=/usr' '--sysconfdir=/usr/local/etc/namedb' '--disable-dnstap' '--disable-fixed-rrset' '--without-geoip2' '--without-gssapi' '--with-libidn2=/usr/local' '--without-libjson' '--disable-largefile' '--without-lmdb' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=large' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.1' 'build_alias=amd64-portbld-freebsd12.1' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -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.1 (tags/RELEASE_801/final 366581)
compiled with OpenSSL version: OpenSSL 1.1.1d-freebsd  10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d-freebsd  10 Sep 2019
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
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

dig @<IP-ADDRESS-OF-NAMESERVER> id.server txt ch dig @<IP-ADDRESS-OF-NAMESERVER> foo.bar soa ch

What is the current bug behavior?

named process gets killed due to the assertion

What is the expected correct behavior?

named should not crash and reply with NXDOMAIN

Relevant configuration files

named.conf:

options {
        // All file and path names are relative to the chroot directory,
        // if any, and should be fully qualified.
        directory       "/etc/namedb/working";
        pid-file        "/var/run/named/pid";
        dump-file       "/var/dump/named_dump.db";
        statistics-file "/var/stats/named.stats";
        memstatistics-file "/var/stats/named.memstats";

        zone-statistics yes;
        listen-on { any; };
        listen-on-v6 { any; };

        disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
        disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
        disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

        allow-query { any; };
        allow-query-cache { any; };
        allow-recursion { any; };
        allow-transfer { none; };

        max-cache-size 1024M;
};

view "in" IN {
zone "." { type hint; file "/etc/namedb/named.root"; };
}

view "chaos" CHAOS {
zone "bind" CHAOS {
        type master;
        file "/etc/namedb/bind.chaos";
};
};

/etc/namedb/bind.chaos:

$TTL            3600
@                       CHAOS SOA       @ @ 1970010100 86400 600 86400 300
@                       CHAOS NS        @
version         CHAOS TXT       "Felix' DNS Server V0.1"
hostname        CHAOS TXT       "there.is.no.hostname"

Relevant logs and/or screenshots

04-Jan-2020 07:32:34.140 general: critical: name.c:2174: REQUIRE(source->length > 0) failed, back trace
04-Jan-2020 07:32:34.140 general: critical: #0 0x2c0ff0 in ??
04-Jan-2020 07:32:34.140 general: critical: #1 0x49686a in ??
04-Jan-2020 07:32:34.140 general: critical: #2 0x37f28b in ??
04-Jan-2020 07:32:34.140 general: critical: #3 0x3e5fb1 in ??
04-Jan-2020 07:32:34.140 general: critical: #4 0x3043e2 in ??
04-Jan-2020 07:32:34.140 general: critical: #5 0x307c07 in ??
04-Jan-2020 07:32:34.140 general: critical: #6 0x303ed0 in ??
04-Jan-2020 07:32:34.140 general: critical: #7 0x3025b0 in ??
04-Jan-2020 07:32:34.140 general: critical: #8 0x306393 in ??
04-Jan-2020 07:32:34.140 general: critical: #9 0x2f9058 in ??
04-Jan-2020 07:32:34.140 general: critical: #10 0x4b2662 in ??
04-Jan-2020 07:32:34.140 general: critical: #11 0x800a38736 in ??
04-Jan-2020 07:32:34.140 general: critical: exiting (due to assertion failure)

Possible fixes

Use server-id, version, and hostname in the global option section of named.conf.