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.
--
bind-announce mailing list
bind-announce@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-announce
