BIND 9.18 and 9.20 information for administrators of Authoritative DNSSEC-signed zones

[Cathy Almond]

We have two important updates specifically for administrators of 
DNSSEC-signed zones.

The first update concerns a known issue with authoritative NSEC3 
introduced accidentally in September to both our 9.18 and 9.20 branches. 
This will be fixed in our December BIND releases. It is not a problem 
for the majority of DNSSEC-signed zones, but if you are signing your 
zones with NSEC3 we recommend that you check the details below to 
determine whether you could be affected.

The second update is for those administrators who are using 
dnssec-policy and who have chosen to use dynamic updates to manage their 
signed zone content (instead of using inline-signing).  There is a 
change in the default for inline-signing in the 9.20 release: it is now 
necessary to explicitly disable inline-signing in named.conf if you do 
not wish your zones using dnssec-policy become inline-signed.  We 
apologise for failing to highlight this change to the default 
configuration in the BIND 9.20 release notes.

More details follow below.

===

There is a problem affecting zones DNSSEC-signed with NSEC3, 
accidentally introduced in our September releases starting with BIND 
9.18.30 and BIND 9.20.2.  We plan to address it in December 2024 in 
releases 9.18.32 and 9.20.4.  Full details are in BIND issue #4950 
(https://gitlab.isc.org/isc-projects/bind9/-/issues/4950).

This defect only affects zones that create two or more empty 
non-terminals (ENTs) in the DNS namespace as a result of one or more 
RRsets defined within that zone that are multi-label names.

For example, if the zone is example.com and it contains RRsets with 
names formatted similarly to a.b.c.example.com, then the intermediate 
labels "b" and "c" create the ENTs b.c.example.com and c.example.com. 
It's in a zone with this type of content that the NSEC3 defect may be 
encountered.  The problem will otherwise not occur.

Affected BIND 9 authoritative servers (primaries or secondaries) may 
provide incorrect responses when they are queried. The zone content is 
generated correctly during DNSSEC-signing however the responses from 
BIND for these zones may select the wrong NSEC3 RRsets as “proof” of a 
name's non-existence thus causing DNSSEC-validating resolvers to return 
SERVFAIL instead of NXDOMAIN to their clients.  DNSSEC-signed proof of 
existence is unaffected by this issue.

DNSSEC-signed reverse zones (especially in IPv6 space) are most likely 
to experience this defect but other zones with the same type of 
multi-label content do exist and would be similarly affected.

===

BIND 9.20 now defaults inline-signing to 'yes' unless explicitly set to 
'no'. Also in 9.20, it's now possible to configure inline-signing within 
a dnssec-policy, although the per-zone configuration of this option will 
take precedence (therefore can be used to override a dnssec-policy 
option where the same policy is used by multiple DNSSEC-signed zones).

Use of dnssec-policy requires that a zone either be configured for 
dynamic updates, or that inline-signing be enabled.  The option was 
newly added to dnssec-policy to make it easier for administrators to 
manage the choice more globally instead of in each zone explicitly.  At 
the same time we changed the default so that the transition of a zone 
from unsigned to signed via dnssec-policy was more *"automagic"* and 
named would not fail to start if the administrator applied dnssec-policy 
to a non-dynamic zone.

The effect of the change to the default is that when migrating from BIND 
9.18 to BIND 9.20, dynamic zones using dnssec-policy will additionally 
become inline-signed unless inline-signing is explicitly disabled for them.

Additionally, DNS administrators running BIND 9.20 who are newly 
DNSSEC-signing their zones and who intend to manage their zone content 
dynamically should be aware that they need to disable inline-signing if 
this is not a feature they need or want to have enabled.