BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-07-18T19:24:42Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1870[Support#12071] [RT#46548] Output stale/expired data with 'rndc dumpdb'2022-07-18T19:24:42ZCathy Almond[Support#12071] [RT#46548] Output stale/expired data with 'rndc dumpdb'We want an option to dump, not just the stale/expired data, but the really really expired data.
The use case for this is that currently there is **still** no way to find out how much of cache is expired and awaiting clean-up without get...We want an option to dump, not just the stale/expired data, but the really really expired data.
The use case for this is that currently there is **still** no way to find out how much of cache is expired and awaiting clean-up without getting a core dump and analysing it. Feature request #101 tackles the stale case (for use by the serve-stale feature), but doesn't touch the fully-expired case.
Support (and customers) do, several times a year, encounter edge cases resolver query patterns instances where it appears that there are problems with caches holding on to expired RRsets for much longer than anticipated.
I do not think that this should be the default behaviour for rndc dumpdb -all - but an addition option -expired would make this content accessible to mere mortals as opposed to core dump analysts.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1274Cache DB RRsets statistics seem way off2021-03-25T17:55:21ZHÃ¥vard EidnesCache DB RRsets statistics seem way off### Summary
Some Cache DB RRsets statistics appears to have "gone haywire",
i.e. show "impossible" values.
### BIND version used
```
BIND 9.14.6 (Stable Release) <id:efd3496>
running on NetBSD amd64 8.0_STABLE NetBSD 8.0_STABLE (GENER...### Summary
Some Cache DB RRsets statistics appears to have "gone haywire",
i.e. show "impossible" values.
### BIND version used
```
BIND 9.14.6 (Stable Release) <id:efd3496>
running on NetBSD amd64 8.0_STABLE NetBSD 8.0_STABLE (GENERIC) #0: Thu Dec 13 19:08:40 CET 2018 he@osl-res.uninett.no:/usr/obj/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--with-tuning=large' '--with-libtool' '--enable-dnstap' '--with-protobuf-c=/usr/pkg' '--with-libfstrm=/usr/pkg'
compiled by GCC 5.5.0
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with zlib version: 1.2.10
linked to zlib version: 1.2.10
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Configure statistics channel via
```
statistics-channels {
inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
inet 128.39.2.24 port 8053 allow { <prefix-1>/23; <prefix-2>/24; };
};
```
and connect to the stats channel with a web browser.
### What is the current *bug* behavior?
Quite a few of the "number of cached records of this type" counters appear
to be within a few 64k's worth of 2^32.
### What is the expected *correct* behavior?
More realistic values of "cached RRs" are expected.
### Relevant configuration files
See above.
### Relevant logs and/or screenshots
Parts of the table returned looks like this (copy/pasted from the web page):
```
Cache DB RRsets for View _default
A 4294643433
NS 248764
CNAME 4294866283
SOA 1769
PTR 95936
HINFO 3
MX 1924
TXT 6987
KEY 1
AAAA 4294947603
SRV 2208
NAPTR 4
DNAME 6
DS 10451
RRSIG 31497
NSEC 24501
DNSKEY 7438
TLSA 7
SPF 28
!A 4294966986
!NS 4294967040
!CNAME 4294967295
!SOA 186
!PTR 9
!MX 29
!TXT 123
!AAAA 4294896630
!SRV 106
!NAPTR 4294967290
!A6 3
!DS 25166
!DNSKEY 4
!SPF 284
NXDOMAIN 36984
#A 461980
#NS 10174
#CNAME 161409
#SOA 1150
```
Passing some of the values through to a hex converter reveals a pattern:
```
% dc
16o
4294966986p
FFFFFECA
4294947603p
FFFFB313
4294866283p
FFFE756B
4294643433p
FFFB0EE9
4294967040p
FFFFFF00
```
Also, monitoring via collectd and grafana, showing these stats for the last 90 days
gives the picture as attached.
![rrs](/uploads/8e4c3ded204682f51faec40ec7932b92/rrs.png)
### Possible fixes
Sorry, have not yet looked at the code for this problem.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Diego dos Santos FronzaDiego dos Santos Fronza