public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Adolf Belka <adolf.belka@ipfire.org>
To: Matthias Fischer <matthias.fischer@ipfire.org>
Cc: "IPFire: Development-List" <development@lists.ipfire.org>
Subject: Re: [PATCH] bind: Update to 9.20.12
Date: Tue, 26 Aug 2025 19:48:05 +0200	[thread overview]
Message-ID: <cea578ff-7434-4443-9758-f7841798d596@ipfire.org> (raw)
In-Reply-To: <20250826155538.884-1-matthias.fischer@ipfire.org>

Reviewed-by: Adolf Belka <adolf.belka@ipfire.org>

Hi Matthias,

You got in before me. I have built it but not had the time to submit the patch for it yet. :-)

I will delete it from my build.


On 26/08/2025 17:55, Matthias Fischer wrote:
> For details see:
> 
> https://downloads.isc.org/isc/bind9/9.20.12/doc/arm/html/notes.html#notes-for-bind-9-20-12
> 
> "Notes for BIND 9.20.12
> New Features
> 
>      Support for parsing DSYNC records has been added.
> 
>      These records are used for discovering the receiver endpoint for DNS
>      notification messages. For more information, see
>      draft-ietf-dnsop-generalized-notify-09. [GL #5440]
> 
> Feature Changes
> 
>      Add deprecation warnings for RSASHA1, RSASHA1-NSEC3SHA1, and DS digest
>      type 1.
> 
>      RSASHA1 and RSASHA1-NSEC-SHA1 DNSKEY algorithms have been deprecated by
>      the IETF and should no longer be used for DNSSEC. DS digest type 1
>      (SHA1) has also been deprecated in BIND 9. Validators are now expected
>      to treat these algorithms and digest as unknown, resulting in some
>      zones being treated as insecure when they were previously treated as
>      secure. Warnings have been added to named and tools when these
>      algorithms and this digest are being used for signing.
> 
>      Zones signed with RSASHA1 or RSASHA1-NSEC-SHA1 should be migrated to a
>      different DNSKEY algorithm.
> 
>      Zones with DS or CDS records with digest type 1 (SHA1) should be
>      updated to use a different digest type (e.g. SHA256) and the digest
>      type 1 records should be removed. [GL #5358]
> 
> Bug Fixes
> 
>      Stale RRsets in a CNAME chain were not always refreshed.
> 
>      Previously, with serve-stale enabled and a CNAME chain that contained a
>      stale RRset, the refresh query didn’t always properly refresh the stale
>      RRsets. This has been fixed. [GL #5243]
> 
>      Add RPZ extended DNS error for zones with a CNAME override policy
>      configured.
> 
>      Previously, when the zone was configured with a CNAME override policy,
>      or the response policy zone contained a wildcard CNAME, the extended
>      DNS error code was not added. This has been fixed. [GL #5342]
> 
>      Fix dig issues.
> 
>      When used with the +keepopen option, dig could terminate unexpectedly
>      in rare situations. Additionally, dig could hang and fail to shutdown
>      properly when interrupted during a query. These have been fixed. [GL
>      #5381]
> 
>      Log dropped or slipped responses in the query-errors category.
> 
>      Responses which were dropped or slipped because of Response Rate
>      Limiting (RRL) were logged in the rate-limit category instead of the
>      query-errors category, as documented in the ARM. This has been fixed.
>      [GL #5388]
> 
>      synth-from-dnssec was not working in some scenarios.
> 
>      Aggressive use of DNSSEC-Validated cache with NSEC was not working in
>      scenarios when no parent NSEC was in cache. This has been fixed. [GL
>      #5422]
> 
>      Clean enough memory when adding new ADB names/entries under memory
>      pressure.
> 
>      The ADB memory cleaning is opportunistic even when BIND is under memory
>      pressure (in the overmem condition). named now ensures that the
>      assigned memory limit is not exceeded by releasing twice the amount of
>      memory allocated for each new ADB name/entry when under memory
>      pressure. [GL !10637]
> 
>      Prevent spurious validation failures.
> 
>      Under rare circumstances, validation could fail if multiple clients
>      simultaneously iterated the same set of DNSSEC signatures. This has
>      been fixed. [GL #3014]"
> 
> Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
> ---
>   config/rootfiles/common/bind | 11 ++++++-----
>   lfs/bind                     |  4 ++--
>   2 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/config/rootfiles/common/bind b/config/rootfiles/common/bind
> index fb6220c47..538f4a6dd 100644
> --- a/config/rootfiles/common/bind
> +++ b/config/rootfiles/common/bind
> @@ -28,6 +28,7 @@ usr/bin/nsupdate
>   #usr/include/dns/dnstap.h
>   #usr/include/dns/ds.h
>   #usr/include/dns/dsdigest.h
> +#usr/include/dns/dsync.h
>   #usr/include/dns/dyndb.h
>   #usr/include/dns/ecs.h
>   #usr/include/dns/ede.h
> @@ -240,18 +241,18 @@ usr/bin/nsupdate
>   #usr/include/ns/types.h
>   #usr/include/ns/update.h
>   #usr/include/ns/xfrout.h
> -usr/lib/libdns-9.20.11.so
> +usr/lib/libdns-9.20.12.so
>   #usr/lib/libdns.la
>   #usr/lib/libdns.so
> -usr/lib/libisc-9.20.11.so
> +usr/lib/libisc-9.20.12.so
>   #usr/lib/libisc.la
>   #usr/lib/libisc.so
> -usr/lib/libisccc-9.20.11.so
> +usr/lib/libisccc-9.20.12.so
>   #usr/lib/libisccc.la
>   #usr/lib/libisccc.so
> -usr/lib/libisccfg-9.20.11.so
> +usr/lib/libisccfg-9.20.12.so
>   #usr/lib/libisccfg.la
>   #usr/lib/libisccfg.so
> -usr/lib/libns-9.20.11.so
> +usr/lib/libns-9.20.12.so
>   #usr/lib/libns.la
>   #usr/lib/libns.so
> diff --git a/lfs/bind b/lfs/bind
> index fa4d73d04..d62846f58 100644
> --- a/lfs/bind
> +++ b/lfs/bind
> @@ -25,7 +25,7 @@
>   
>   include Config
>   
> -VER        = 9.20.11
> +VER        = 9.20.12
>   
>   THISAPP    = bind-$(VER)
>   DL_FILE    = $(THISAPP).tar.xz
> @@ -43,7 +43,7 @@ objects = $(DL_FILE)
>   
>   $(DL_FILE) = $(DL_FROM)/$(DL_FILE)
>   
> -$(DL_FILE)_BLAKE2 = 582e6de2699713e870dfc853f461c78b2d2b505bed0b571f853c94a731be9006783f45a4f897692289c1a9411725eac0b4de3818f1641221e62754316f410081
> +$(DL_FILE)_BLAKE2 = f2135301ab04121c1ae82fc9283f0f03b0d11b634aaee49c072bb9a2a0f7e643a8f6c1f3890648e5d008a7d2c84953617b330241e3f856e33b56e64fb0312f0a
>   
>   install : $(TARGET)
>   



      reply	other threads:[~2025-08-26 17:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26 15:55 Matthias Fischer
2025-08-26 17:48 ` Adolf Belka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cea578ff-7434-4443-9758-f7841798d596@ipfire.org \
    --to=adolf.belka@ipfire.org \
    --cc=development@lists.ipfire.org \
    --cc=matthias.fischer@ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox