Problems with (unsigned) forward zones, dnssec-validation auto and validate-except on BIND 9.16 and 9.17

[Gehrkens.IT GmbH | Heiko Wundram]

Dear list,

 

I'm currently setting up a resolver using bind (tested with both 9.16 and
9.17), which uses multiple views to expose forwarded zones (under .lan and
.local, old Windows-AD zones which I don't control and can't change.) under
some of their views. All of the views have dnssec-validation auto (set as a
global option), and the forwarding zones are configured as "type forward;
forward only;" in each specific view using an import from a single
configuration file which contains all forward zone specifications and also a
"validate-except" clause which lists all of the forwarded zones.

 

Generally, this works: in the views that should resolve the internal
forwarded zone names, I can resolve them, and BIND also skips DNSsec
validation for those zones. Now comes the but: if I resolve a zone name in
.lan or .local which is not forwarded I get an NXDOMAIN with "ad" as I would
expect (coming from the roots which authoritatively don't know e.g. .local),
but the cached entry for the authoritative NXDOMAIN seems to block future
resolution of all forwarded zones under this pseudo-TLD. When the resolved
records under the forwarded .lan or .local zone time out, I get an NXDOMAIN
for any record that I try to resolve in a zone that should be reachable
through forward, with "authority" for the result pointing to the roots. It
seems that this also kills the connectivity of the forward zone completely
(i.e., the zone is removed from BIND in some way or another): I need to
restart bind to make the forward-zones resolvable again, clearing the
resolver cache does not seem to help to get them to resolve again.

 

>From what I gather, this behaviour sounds almost like what RFC 8020 proposes
(NXDOMAIN cut), but at least according to the corresponding ticket, that
isn't implemented in BIND.

 

BIND 9.11 (which comes with Debian Buster) did not have this behaviour with
this configuration (for BIND 9.11, I did not use validate-except but
periodic rndc nta for the injected forward zones, but using that with BIND
9.16/.17 gives the same result as above), but after updating BIND to the
version in bullseye (which comes with 9.16), I see this behaviour, and it
seems that this only happens when DNSsec validation is on. Turning it off
makes the forward zones work correctly. I do not want to turn off DNSsec
validation completely, and neither do I want to "validate-except" lan and
local (which does not help anyway, as I currently don't have a .lan/.local
zone file set up and would rather not have to manage one, as the forwarders
aren't the NS records for the zones I'm looking up anyway, so it'd be rather
difficult to make a proper glue entry for the forwarded zones without
additional network magic).

 

Thanks for any hints on where I might look; I tried to follow the actual
resolver code, but that gave me no immediate cause for the change, and I
also found no entries in the bugtracker.

 

Heiko.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220126/da207c06/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6650 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220126/da207c06/attachment.bin>