Repeated priming queries when doing forwarding
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