NetBSD Problem Report #60833

From root@dognsp16.localdomain  Thu Oct  1 12:01:48 2026
Return-Path: <root@dognsp16.localdomain>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 11AD31A923B
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  1 Oct 2026 12:01:48 +0000 (UTC)
Message-Id: <20261001115553.6A59E3092E@dognsp16.localdomain>
Date: Thu, 01 Oct 2026 13:55:53 +0200 (CEST)
From: root@dognsp16.localdomain
Reply-To: ihsan@dogan.ch
To: gnats-bugs@NetBSD.org
Subject: BIND 9.20.24 in NetBSD 11.0/i386 does not send DNS NOTIFY messages
X-Send-Pr-Version: 3.95
X-From4GNATS: "root@dognsp16.localdomain via gnats" <gnats-admin@NetBSD.org>

>Number:         60833
>Category:       bin
>Synopsis:       BIND 9.20.24 in NetBSD 11.0/i386 does not send DNS NOTIFY messages
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 01 12:05:00 +0000 2026
>Last-Modified:  Sun Nov 01 01:01:34 +0000 2026
>Originator:     Ihsan Dogan
>Release:        NetBSD 11.0
>Organization:

>Environment:
 System: NetBSD 11.0 i386
 Kernel: NetBSD 11.0 (GENERIC)
 Architecture: i386

 Base named:

 BIND 9.20.24 (Stable Release) id:e5d43f1
>Description:

 Contact:
 ihsan@dogan.ch

 Description:

 The named(8) included in NetBSD 11.0/i386 does not send DNS NOTIFY
 messages for primary zones.

 The zone configuration contains both "notify yes" and an explicit
 "also-notify" target.  rndc accepts "notify <zone>" and reports:

 zone notify queued

 but no DNS NOTIFY packet is emitted.

 The problem affects multiple primary zones and is not specific to a
 dynamic zone.

 AXFR/IXFR between the same two servers works normally.  Normal DNS
 queries work normally, and the secondary can transfer the zone when
 a transfer is manually requested.

 Replacing the NetBSD base named 9.20.24 with pkgsrc
 bind-9.18.50nb2 fixes the problem immediately with the same zone
 configuration and network setup.

 The problem also persists after completely stopping and restarting
 the base named process.

>How-To-Repeat:

 Example primary zone configuration:

 zone "test.example.com" {
 type master;
 file "dynamic/db.test.example.com";

     allow-update {
             key "dhcp-key";
             key "update-key";
     };

     allow-transfer {
             172.29.105.18;
             key "update-key";
     };

     also-notify {
             172.29.105.18;
     };

     notify yes;

 };

 The primary server is 172.29.105.17 and the secondary is
 172.29.105.18.

 The effective configuration was verified with:

 # named-checkconf -p

 and contains the expected:

     also-notify {
             172.29.105.18;
     };
     notify yes;

 Start a packet capture on the primary itself:

 # tcpdump -nvi vr0 'host 172.29.105.18 and port 53'

 Then, in another terminal:

 # rndc notify test.example.com
 zone notify queued

 No DNS NOTIFY packet is emitted on vr0.

 This was also tested with another ordinary, non-dynamic primary zone,
 with the same result.  Therefore the problem does not appear to be
 related to dynamic updates, journals, or this particular zone.

 The same primary can answer ordinary DNS requests from the secondary,
 and AXFR/IXFR works normally.

 For example, manually triggering a retransfer on the secondary causes
 a successful AXFR from 172.29.105.17.

 As an additional test, an explicit NOTIFY source was configured:

     also-notify source 172.29.105.17 {
             172.29.105.18;
     };

 This did not change the behavior.

 Debug logging was enabled for the "general" and "notify" categories,
 together with:

 # rndc trace 3
 # rndc notify test.example.com
 zone notify queued

 The relevant debug output is:

 general: info: received control channel command 'notify test.example.com'
 general: debug 1: zone__settimer: zone test.example.com/IN: enter

 No subsequent "sending notifies" message appears, and no NOTIFY packet
 is transmitted.

 Thus rndc appears to successfully queue the NOTIFY operation and enter
 zone__settimer(), but processing does not proceed to actually sending
 the NOTIFY message.

 The problem remains after a complete restart of named.

 The running daemon reports:

 version: BIND 9.20.24 (Stable Release) <id:e5d43f1>
 worker threads: 1
 server is up and running

 Installing pkgsrc bind-9.18.50nb2 and running that version of named
 instead of the NetBSD base named fixes the problem.  NOTIFY packets
 are sent normally with the same zone configuration and network setup.

>Fix:

 Unknown.

 Current workaround:

 Use pkgsrc bind-9.18.50nb2 instead of the BIND 9.20.24 included in
 NetBSD 11.0.

 The observed behavior suggests a problem in the BIND 9.20 zone
 timer/event/NOTIFY handling on NetBSD/i386: rndc schedules the zone
 timer, but the operation does not appear to proceed into the NOTIFY
 send path.

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: gnats-admin->bin-bug-people
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Sun, 01 Nov 2026 01:01:34 +0000
Responsible-Changed-Why:
Fix up mangled PR


>Unformatted:

Home	PR Database Search