"resolver" test fails on openSUSE Tumbleweed

Summary

When running "make test", the "resolver" test fails. All other tests pass.

BIND version used

BIND 9.18.0 (Stable Release) <id:8db45af>
running on Linux x86_64 5.16.2-1-default #1 SMP PREEMPT Mon Jan 24 18:27:48 UTC 2022 (0d710a8)
built by make with default
compiled by GCC 11.2.1 20220103 [revision d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6]
compiled with OpenSSL version: OpenSSL 1.1.1m  14 Dec 2021
linked to OpenSSL version: OpenSSL 1.1.1m  14 Dec 2021
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.46.0
linked to libnghttp2 version: 1.46.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.6.0
threads support is enabled

default paths:
  named configuration:  /usr/local/etc/named.conf
  rndc configuration:   /usr/local/etc/rndc.conf
  DNSSEC root key:      /usr/local/etc/bind.keys
  nsupdate session key: /usr/local/var/run/named/session.key
  named PID file:       /usr/local/var/run/named/named.pid
  named lock file:      /usr/local/var/run/named/named.lock
  geoip-directory:      /usr/share/GeoIP

Steps to reproduce

This was found in the context of testing the new bind release prior to releasing it as an openSUSE package. On an openSUSE Tumbleweed installation: As "root": D=/usr/src/packages/BUILD; rm -rf $D/bind-9.18.0; chgrp users $D; chmod 775 $D D=/usr/src/packages/BUILDROOT; rm -rf $D/bind-9.18.0resolver.logresolver.log; chgrp users $D; chmod 775 $D As an unprivileged user: ln -s /usr/src/packages ~/rpmbuild

Then, as the unprivileged user: cd /usr/src/packages/BUILD; rm -rf bind-9.18.0 tar xvJf /usr/src/packages/SOURCES/bind-9.18.0.tar.xz cd bind-9.18.0/ ./configure make -j make test

What is the current bug behavior?

FAIL: resolver

What is the expected correct behavior?

PASS: resolver

Relevant configuration files

This is the unmodified source code.

Relevant logs and/or screenshots

Configuration summary:
-------------------------------------------------------------------------------
Optional features enabled:
    Memory allocator: jemalloc
    GeoIP2 access control (--enable-geoip)
    GSS-API (--with-gssapi)
    DNSSEC validation active by default (--enable-auto-validation)
-------------------------------------------------------------------------------
Features disabled or unavailable on this platform:
    Small-system tuning (--with-tuning)
    Allow 'dnstap' packet logging (--enable-dnstap)
    DNS Response Policy Service interface (--enable-dnsrps)
    Allow 'fixed' rrset-order (--enable-fixed-rrset)
    Very verbose query trace logging (--enable-querytrace)
    Single-query trace logging (--enable-singletrace)
    LMDB database to store configuration for 'addzone' zones (--with-lmdb)
    IDN support (--with-libidn2)
-------------------------------------------------------------------------------
Configured paths:
    prefix: /usr/local
    sysconfdir: ${prefix}/etc
    localstatedir: ${prefix}/var
-------------------------------------------------------------------------------
Compiler: gcc
    gcc (SUSE Linux) 11.2.1 20220103 [revision d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6]
    Copyright (C) 2021 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
CFLAGS: -Wall -Wextra -Wwrite-strings -Wpointer-arith -Wno-missing-field-initializers -Wformat -Wshadow -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=format-security -Werror=parentheses -Werror=implicit -Werror=strict-prototypes -fno-strict-aliasing -fno-delete-null-pointer-checks -fdiagnostics-show-option -g -O2 -pthread
CPPFLAGS: -D_FORTIFY_SOURCE=2 
LDFLAGS: 

Possible fixes

I thought this might be similar to issue #3069 (closed) so I tried

• adding "--enable-querytrace" to the configure flags which hung the "resolver" test completely
• extending the timeout value from 15 to 30 (this is a single-core VM with only 1GB of main memory) But nothing helped.