Cache 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 (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.

Possible fixes

Sorry, have not yet looked at the code for this problem.