notes-9.20.29.rst revision 1.1 1 .. Copyright (C) Internet Systems Consortium, Inc. ("ISC")
2 ..
3 .. SPDX-License-Identifier: MPL-2.0
4 ..
5 .. This Source Code Form is subject to the terms of the Mozilla Public
6 .. License, v. 2.0. If a copy of the MPL was not distributed with this
7 .. file, you can obtain one at https://mozilla.org/MPL/2.0/.
8 ..
9 .. See the COPYRIGHT file distributed with this work for additional
10 .. information regarding copyright ownership.
11
12 Notes for BIND 9.20.29
13 ----------------------
14
15 Security Fixes
16 ~~~~~~~~~~~~~~
17
18 - Prevent excessive CPU use validating crafted DNSSEC responses.
19 :cve:`2026-19668`
20
21 A malicious authoritative server could serve a securely delegated zone
22 whose DS and DNSKEY records carried many distinct key tags but no valid
23 match, forcing a validating resolver into excessive key-tag matching
24 and high CPU use for every query. This work is now bounded by the
25 per-query validation limit (:any:`max-validations-per-fetch`).
26
27 ISC would like to thank Zuyao Xu and Xiang Li of the All-in-One
28 Security and Privacy Laboratory, Nankai University, for bringing this
29 vulnerability to our attention. :gl:`#5349`
30
31 - Require a TSIG on every message of incoming zone transfers.
32 :cve:`2026-19033`
33
34 Previously, :iscman:`named` accepted TSIG-signed zone transfers in
35 which some messages were unsigned, and processed those messages
36 before the next signature could vouch for them. It now requires a
37 TSIG on every message of an incoming AXFR or IXFR; all modern
38 nameservers already sign every message, so no change is expected in
39 practice. :gl:`#6062`
40
41 - Prevent a DNSSEC downgrade of secure delegations via unrelated NSEC3
42 records. :cve:`2026-77119`
43
44 A validating resolver could be tricked into treating a secure
45 delegation as unsigned and accepting forged answers for names beneath
46 it, if an attacker could inject responses to its queries. Such forged
47 proofs are now rejected. :gl:`#6234`
48
49 - Prevent forged DNSSEC-validated NXDOMAIN responses. :cve:`2026-19941`
50
51 A validating resolver could accept a signed NSEC record from an
52 unrelated zone as proof that a wildcard did not exist. An on-path
53 attacker or malicious forwarder controlling a signed zone could
54 therefore forge an authenticated NXDOMAIN response for a name that
55 should resolve through a wildcard. The wildcard-denial and
56 name-nonexistence proofs are now required to be signed by the same
57 zone. :gl:`#6253`
58
59 - DNS64 with :any:`break-dnssec` could cause an assertion failure.
60 :cve:`2026-19666`
61
62 When a :any:`dns64` statement is configured with ``break-dnssec yes;``
63 and its ``exclude`` list matches some but not all of the addresses in
64 an AAAA RRset, :iscman:`named` removes the excluded addresses from the
65 answer instead of synthesizing new ones. If the answer being filtered
66 had been cached together with a proof that the queried name did not
67 exist which is what a wildcard match produces :iscman:`named`
68 terminated with an assertion failure.
69
70 Only recursive resolvers are affected, and only when
71 ``break-dnssec yes;`` is in use; the answer has to come from the
72 cache, so a server that is only authoritative cannot reach this.
73
74 ISC would like to thank Rintaro Kawasugi for bringing this
75 vulnerability to our attention. :gl:`#6301`
76
77 - Reject oversized negative cache records. :cve:`2026-19667`
78
79 A single crafted response from a server could make a resolver cache a
80 malformed negative entry and then terminate with an assertion failure
81 when reading it back. Only recursive resolvers are affected, on a
82 default configuration.
83
84 ISC would like to thank Rintaro Kawasugi for bringing this
85 vulnerability to our attention. :gl:`#6302`
86
87 - Prevent resolver crash with cached DNSSEC proofs. :cve:`2026-19662`
88
89 Under certain timing conditions, concurrent recursive queries could
90 cause :iscman:`named` to crash when cached DNSSEC NOQNAME proof data
91 was replaced while still in use. Cached proof data is now retained
92 until all queries using it have completed.
93
94 ISC would like to thank Samy Medjahed/Ap4sh for bringing this
95 vulnerability to our attention. :gl:`#6333`
96
97 - Discard repeated SOA, CNAME, and DNAME records when parsing DNS
98 messages. :cve:`2026-75029`
99
100 A DNS message could carry the same SOA, CNAME, or DNAME record many
101 times, and :iscman:`named` kept every copy while parsing it. With name
102 compression those copies took up far more memory internally than in
103 the message itself, and every later processing step had to handle all
104 of them. Only the first copy of such a record is now kept; identical
105 repeats are discarded. :gl:`#6335`
106
107 - Fix an unauthenticated crash on HTTPS using SIG(0). :cve:`2026-77692`
108
109 A specifically crafted HTTPS query using SIG(0) as authentication
110 could crash :iscman:`named` if the client closed the connection before
111 :iscman:`named` actually verified the signature. This is now fixed.
112
113 ISC would like to thank Vitaly Simonovich for bringing this
114 vulnerability to our attention. :gl:`#6343`
115
116 - Cached HTTPS/SVCB aliases could exhaust resolver CPU.
117 :cve:`2026-81736`
118
119 A recursive resolver that had cached a large set of interlinked HTTPS
120 or SVCB records in alias form could be driven to do an excessive
121 amount of work assembling a single response, because it followed every
122 cached alias target when building the additional section. A client
123 permitted to use recursion, together with an attacker-controlled zone
124 used to plant the records, could repeat small queries to consume
125 enough CPU to delay or deny service to other clients. The amount of
126 additional processing done for one query is now bounded.
127
128 ISC would like to thank Henrique Pereira for bringing this
129 vulnerability to our attention. :gl:`#6347`
130
131 - Prevent TKEY queries from terminating :iscman:`named` without global
132 options. :cve:`2026-76163`
133
134 The :iscman:`named` process could terminate unexpectedly when a remote
135 client sent a TKEY query and the configuration did not include a
136 global :namedconf:ref:`options` statement. This has been fixed.
137
138 ISC would like to thank Owais Lone (thesecguy) for bringing this
139 vulnerability to our attention. :gl:`#6357`
140
141 - Out-of-zone records in a zone database could be served as
142 authoritative. :cve:`2026-78301`
143
144 When a zone database contained records for names outside the zone
145 such as a delegation above the zone apex, left behind by a secondary
146 that had accepted out-of-zone data from its primary the server could
147 treat them as authoritative and answer queries for names inside the
148 zone with that out-of-zone data instead of the zone's own. A server
149 that was also a resolver could follow such a delegation and cache the
150 answers of the server it named, affecting names outside the configured
151 zone. Zone database lookups are now confined to names at or below the
152 zone's origin.
153
154 ISC would like to thank Henrique Pereira for bringing this
155 vulnerability to our attention. :gl:`#6361`
156
157 - Fix crash on wildcard answers carrying both NSEC and NSEC3 proofs.
158 :cve:`2026-80274`
159
160 When a wildcard answer arrived with both NSEC and NSEC3 records at the
161 name proving that the queried name did not exist, the resolver could
162 pick different records when caching the answer and when retrieving the
163 proof, depending on the order in which the authoritative server sent
164 them. This could terminate :iscman:`named` with an assertion failure,
165 fail the query with SERVFAIL, or serve a denial record other than the
166 one that had been verified. The resolver now caches and serves the
167 same denial record it accepted when the answer was received.
168
169 ISC would like to thank hythyt for bringing this vulnerability to our
170 attention. :gl:`#6369`
171
172 - Following HTTPS/SVCB aliases could leak resolver cache memory.
173 :cve:`2026-81563`
174
175 When a recursive server answered a query for an HTTPS or SVCB record
176 in alias form and the alias target had more than 13 records, the
177 target records were pinned in the cache permanently instead of being
178 released once the answer was sent. A remote party who could make the
179 server follow such aliases to a steady stream of fresh names could
180 grow the cache beyond the configured :any:`max-cache-size` until the
181 server was unable to resolve unrelated names. The records are now
182 released correctly.
183
184 ISC would like to thank Samy Medjahed/Ap4sh for bringing this
185 vulnerability to our attention. :gl:`#6374`
186
187 Feature Changes
188 ~~~~~~~~~~~~~~~
189
190 - Reject oversized and malformed DNSKEY records up front.
191
192 Oversized RSA key material in a DNSKEY record was only rejected after
193 it had been converted, allocating memory proportional to the record
194 size. Such records are now rejected before conversion, as are Ed25519
195 and Ed448 keys with trailing bytes that were previously silently
196 ignored. :gl:`#4537`
197
198 Bug Fixes
199 ~~~~~~~~~
200
201 - Prevent a crash when using both :any:`dns64` and ``filter-a``.
202
203 An assertion failure was possible when using both :any:`dns64` and the
204 ``filter-a`` plugin simultaneously; this has been fixed.
205 :gl:`#5979`
206
207 - Stop passing UDP client addresses to :any:`update-policy` ``external``
208 helpers.
209
210 Dynamic update rules of type ``external`` delegate the authorization
211 decision to an external helper daemon. The client address field in
212 the helper request is only meant to carry TCP client addresses, which
213 cannot easily be spoofed, but UDP client addresses were passed as
214 well, so the helper could base its decision on an untrustworthy
215 address. For updates arriving over UDP, the helper request no longer
216 includes a client address. :gl:`#6061`
217
218 - Missing required NSEC3 for delegation not detected.
219
220 A missing required NSEC3 record for an insecure delegation in a
221 non-opt-out range was not being detected. This has been fixed.
222 :gl:`#6063`
223
224 - Tighten EUI48 and EUI64 text parsing.
225
226 Malformed EUI48 and EUI64 records could be accepted. This has been
227 fixed. :gl:`#6082`
228
229 - GeoIP ACL state could be stale or wrong after reload.
230
231 Previously, :iscman:`named` cached GeoIP information after looking it
232 up, but the cached information was not invalidated when the GeoIP
233 database was reloaded, so it could continue to be used. Existing
234 cached GeoIP information is now invalidated as part of the reloading
235 process. :gl:`#6083`
236
237 - Honor DNSSEC policy key tag ranges.
238
239 When a :any:`dnssec-policy` configured a non-default ``tag-range``,
240 :iscman:`dnssec-keygen` and :iscman:`dnssec-ksr` could accept
241 generated keys outside that range. Both tools now honor the configured
242 minimum and maximum key tags. :gl:`#6091`
243
244 - Fix a double free in :iscman:`mdig` when EDNS options are specified.
245
246 The :iscman:`mdig` utility could terminate with a double free when
247 EDNS options were specified on the command line. This has been fixed.
248 :gl:`#6095`
249
250 - Fix a crash when an IXFR falls back to AXFR with updates still
251 pending.
252
253 When a secondary zone received an incremental transfer (IXFR) and the
254 primary then caused :iscman:`named` to fall back to a full transfer
255 (AXFR) while some of the already-received incremental changes were
256 still waiting to be applied, :iscman:`named` could later crash when
257 that transfer finished. The pending changes are now discarded
258 correctly before the AXFR retry. :gl:`#6114`
259
260 - Fix DS requests to parental agents over TLS.
261
262 TLS configuration for parental agents was being ignored when sending
263 DS requests. This has been fixed. :gl:`#6135`
264
265 - Fix the :option:`rndc-confgen -q` (quiet) option.
266
267 The command-line parsing in :iscman:`rndc-confgen` was broken, so
268 :option:`rndc-confgen -q` did not work. This has been fixed.
269 :gl:`#6187`
270
271 - Enforce query ACLs for redirect zones and searched DLZs.
272
273 Queries answered from redirect zones or searched DLZ databases did not
274 consistently honor :any:`allow-query` and :any:`allow-query-on`,
275 potentially exposing restricted DNS data to excluded clients or
276 through excluded listening addresses. These ACLs are now enforced
277 before redirect or DLZ data is returned. :gl:`#6251` :gl:`#6252`
278
279 - Check ``asnum`` validity in GeoIP ACLs.
280
281 The validity of autonomous system (AS) numbers is now checked at
282 configuration time when parsing GeoIP ACLs that use ``asnum``
283 elements.
284
285 ``asnum`` values start with an optional case-insensitive ``AS``
286 prefix, followed only by decimal digits, with no spaces or other
287 extraneous characters. The value represented cannot exceed 2^32.
288 :gl:`#6255`
289
290 - Fix a crash on :any:`remote-servers` lists that reference themselves.
291
292 Since 9.21.16 and 9.20.17, a :any:`remote-servers`, :any:`primaries`,
293 ``masters``, or :any:`parental-agents` list that referenced itself,
294 directly or through another list, made :iscman:`named` crash on
295 startup or reconfiguration. Such references are again skipped and the
296 remaining entries in the list are used, as in earlier versions.
297 :gl:`#6287`
298
299 - A record from outside a response policy zone could crash
300 :iscman:`named`.
301
302 A response policy zone transferred from a primary can contain a record
303 whose name lies outside the zone. Such a record could terminate
304 :iscman:`named` with an assertion failure, both when it arrived and
305 again at every startup afterwards, because a secondary keeps it in its
306 own copy of the zone. Records like this are now rejected and logged;
307 previously one could also silently create a policy entry for an
308 unrelated name. :gl:`#6304`
309
310 - Invalid :any:`key-store` configuration could abort the DNSSEC tools.
311
312 An invalid :any:`key-store` block named ``key-directory`` in a
313 configuration file could abort the DNSSEC tools. This has been fixed.
314 :gl:`#6313`
315
316 - NSEC signature set could bypass the secure-delegation check.
317
318 When proving that a delegation was insecure, the validator bounded an
319 NSEC record's authority by the signer of whichever RRSIG happened to
320 come first in the record's signature set, rather than the signature
321 that actually verified. A grandparent NSEC padded with an extra,
322 unverifiable signature could therefore pass the check that kept such
323 proofs from reaching below a signed child zone. The validator now
324 requires every signature on the NSEC to name the same signer and
325 refuses proofs whose signature set is malformed or larger than
326 :any:`max-validations-per-fetch` allows. :gl:`#6321`
327
328 - Fix a possible :iscman:`nsupdate` issue when using GSS-TSIG.
329
330 The :iscman:`nsupdate` process could terminate unexpectedly when using
331 the GSS-TSIG mode executed with the :option:`nsupdate -g` option. This
332 has been fixed. :gl:`#6325`
333
334 - Fix a crash with a single-element ``geoip`` sortlist.
335
336 If :iscman:`named` was configured with a single-element
337 :any:`sortlist` containing a ``geoip`` ACL element, any matching query
338 triggered an assertion failure. This has been fixed. :gl:`#6342`
339
340 - Prevent out-of-bailiwick CNAMEs from evicting cached records.
341
342 A recursive resolver could remove valid cached records when a DNS
343 response contained an out-of-bailiwick CNAME with the same owner name.
344 Out-of-bailiwick data is now discarded before it can modify the cache.
345 :gl:`#6345`
346
347 - Restore periodic cleanup of stale resolver address data.
348
349 Stale resolver address data could remain cached until memory pressure
350 or an explicit flush. The cleanup interval has been corrected, so
351 stale entries are removed periodically again. :gl:`#6346`
352
353 - Fix :iscman:`named-checkconf`/:iscman:`named` crash with malformed
354 key name.
355
356 When a primary/remote-server key name was malformed,
357 :iscman:`named-checkconf` and :iscman:`named` were both crashing
358 (after warning about the invalid key name). This is now fixed.
359 :gl:`#6362`
360
361 - Prevent resolver crashes while processing DNS over TCP.
362
363 Recursive resolvers could terminate with an assertion failure while
364 processing DNS responses over TCP under sustained traffic. The failure
365 was observed on resolvers configured globally with ``forward only;``,
366 but the same transport path is also used by iterative resolution.
367 This has been fixed. :gl:`!12537`
368