Summary

With reference to Message-Id: 20181123.132139.2223861396231168104.he@uninett.no on bind-users@lists.isc.org:

BIND logs repeated priming queries when configured as

options {
        forwarders {
                <ip-address-1>;
                <ip-address-2>;
        };
        // But if both are dead (unlikely), do resolution ourselves
        forward first;
};

ref.

10:00:01 named[5116]: resolver priming query complete
10:00:02 named[5116]: resolver priming query complete
10:00:02 named[5116]: resolver priming query complete
10:00:08 named[5116]: resolver priming query complete
10:00:10 named[5116]: resolver priming query complete
10:00:11 named[5116]: resolver priming query complete
10:00:11 named[5116]: resolver priming query complete
10:00:13 named[5116]: resolver priming query complete
10:00:13 named[5116]: resolver priming query complete
10:00:15 named[5116]: resolver priming query complete
10:00:21 named[5116]: resolver priming query complete
10:00:21 named[5116]: resolver priming query complete
10:00:23 named[5116]: resolver priming query complete
10:00:23 named[5116]: resolver priming query complete

This is verified with a pcap capture.

BIND version used

brg-res: {1} /usr/local/sbin/named -V
BIND 9.12.3 <id:6c8e92c>
running on NetBSD amd64 7.1_STABLE NetBSD 7.1_STABLE (GENERIC) #2: Mon Feb  5 09:45:22 UTC 2018  he@brg-res.uninett.no:/usr/obj/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--enable-querytrace' '--with-tuning=large' '--with-libtool'
compiled by GCC 4.8.5
compiled with OpenSSL version: OpenSSL 1.0.1u  22 Sep 2016
linked to OpenSSL version: OpenSSL 1.0.1u  22 Sep 2016
compiled with libxml2 version: 2.9.8
linked to libxml2 version: 20908
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.3
threads support is enabled
brg-res: {2} 

Steps to reproduce

See above.

What is the current bug behavior?

BIND makes repeated "priming queries" asking for the name servers for the root. Admittedly, the answer from the forwarder is non-AA, but should validate using the supplied RRSIG.

What is the expected correct behavior?

Priming query should only be done once after startup, and then wait for cache TTL to expire. However, the non-AA-ness from the forwarder probably "interferes".

Relevant configuration files

See above.

Relevant logs and/or screenshots

See above

Possible fixes

Sorry, the message I posted shows the current logic surrounding priming queries, this probably needs to be re-visited.

~bug