The use of stale-cache in version 9.18.9 does not meet expectations
Summary
I use stale cache mechanism. When the cache is generated and deleted after max-stale-ttl expires, when the request is made again, serverfail is responded after stale-answer-client-timeout (50 milliseconds). This is inconsistent with the behavior of named just after it starts. The expected result is to wait for the resolver-query-timeout to respond to serverfail at this time.
BIND version used
BIND 9.18.9 (Stable Release) id: running on Linux x86_64 4.19.0-9.el7.ucloud.x86_64 #1 SMP Mon Sep 28 10:29:09 UTC 2020 built by make with '--enable-dnstap' '--enable-epoll' '--with-json-c' '--with-libnghttp2' '--enable-doh' '--with-lmdb' '--with-openssl=/usr/local/ssl/' '--prefix=/data/named' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/ssl/lib/pkgconfig/' compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44) compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021 linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021 compiled with libuv version: 1.44.2 linked to libuv version: 1.44.2 compiled with libnghttp2 version: 1.33.0 linked to libnghttp2 version: 1.33.0 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.0.2 linked to protobuf-c version: 1.0.2 threads support is enabled DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448 DS algorithms: SHA-1 SHA-256 SHA-384 HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512 TKEY mode 2 support (Diffie-Hellman): yes TKEY mode 3 support (GSS-API): yes
default paths: named configuration: /data/named/etc/named.conf rndc configuration: /data/named/etc/rndc.conf DNSSEC root key: /data/named/etc/bind.keys nsupdate session key: /data/named/var/run/named/session.key named PID file: /data/named/var/run/named/named.pid named lock file: /data/named/var/run/named/named.lock
Steps to reproduce
- dig @named www.google.com
- wait for max-stale-ttl
- dig @named www.google.com
What is the current bug behavior?
as in Summary.
What is the expected correct behavior?
as in Summary.
Relevant configuration files
forwarders { 8.8.8.8;} ;
stale-cache-enable yes;
stale-answer-client-timeout 50;
stale-answer-enable yes;
stale-answer-ttl 1;
max-stale-ttl 36000;
stale-refresh-time 10;
Relevant logs and/or screenshots
Supplement later。