rpz_rewrite_name: mismatched summary data
Summary
If you run BIND with rpz configured and configured with --enable-querytrace
,
a message with the text rpz_reqrite_name: mismatched summary data
is logged
per query processed.
BIND version used
BIND 9.14.1 (Stable Release) <id:d4c1008>
running on NetBSD amd64 8.0_STABLE NetBSD 8.0_STABLE (GENERIC) #0: Sun Aug 5 00:07:14 CEST 2018 he@smistad.uninett.no:/usr/obj/sys/arch/amd64/compile/GENERIC
built by make with '--with-libxml2=yes' '--with-tuning=large' '--with-libtool'
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 BIND for RPZ processing.
Misconfigure BIND with --enable-querytrace
(it's not on in the above, I know...)
Watch the log fill with the above messages.
What is the current bug behavior?
It looks like BIND is doing a lookup in an RB-tree to find the queried-for name
while doing RPZ processing. I think this is an attempt at optimization. However,
dns_rpz_find_name()
always gets back a DNS_R_PARTIALMATCH
result from the RB-tree
lookup, causing lookups to fall back (?) to rpz_find_p()
, and most of the time getting
NXDOMAIN
.
What is the expected correct behavior?
If the RB-tree lookup is supposed to be an optimization, I would expect it not
to almost always return DNS_R_PARTIALMATCH
.
Relevant configuration files
Relevant logs and/or screenshots
(Suggestions welcome.)
Possible fixes
(Sorry, no suggestion.)