Assigning to you Nicolas, you committed 9.18.24 similarly for a lot of CVEs.

Assignee: bugsquad => nicolas.salguero

Suggested advisory:
========================

The updated packages fix security vulnerabilities:

A malicious client can send many DNS messages over TCP, potentially causing the server to become unstable while the attack is in progress. The server may recover after the attack ceases. Use of ACLs will not mitigate the attack. (CVE-2024-0760)

Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name. (CVE-2024-1737)

If a server hosts a zone containing a "KEY" Resource Record, or a resolver DNSSEC-validates a "KEY" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests. (CVE-2024-1975)

Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure. (CVE-2024-4076)

References:
https://ubuntu.com/security/notices/USN-6909-1
https://www.openwall.com/lists/oss-security/2024/07/23/1
========================

Updated packages in core/updates_testing:
========================
bind-9.18.28-1.mga9
bind-chroot-9.18.28-1.mga9
bind-devel-9.18.28-1.mga9
bind-dlz-filesystem-9.18.28-1.mga9
bind-dlz-ldap-9.18.28-1.mga9
bind-dlz-mysql-9.18.28-1.mga9
bind-dlz-sqlite3-9.18.28-1.mga9
bind-dnssec-utils-9.18.28-1.mga9
bind-utils-9.18.28-1.mga9
lib(64)bind9.18.28-9.18.28-1.mga9

from SRPM:
bind-9.18.28-1.mga9.src.rpm

Version: Cauldron => 9
Assignee: nicolas.salguero => qa-bugs
Status: NEW => ASSIGNED
Whiteboard: MGA9TOO => (none)
Status comment: Fixed upstream in 9.18.28 and patches available from upstream and Ubuntu => (none)
Source RPM: bind-9.18.24-1.mga10.src.rpm => bind-9.18.15-2.3.mga9.src.rpm

MGA9-64 server Plasma Wayland on HP-Pavillion.
No installation issues.
As a client to my own LAN server on my desktop PC, all works well (always using fixed IP-addresses defined in the DNS-zone).
Tried to setup this laptop as its own DNS-server. I run into problems: as soon I point the own address as first  DNS-server in the network settings (wifi), the whole LAN becomes unreachable, even its own IP-address , error "Connection refused".
I used webmin to setup the DNS-server, on another attempt I used  MCC, but to no avail.
At the CLI:
# systemctl  restart named
# systemctl -l status named
● named.service - Berkeley Internet Name Domain (DNS)
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: disabled)
     Active: active (running) since Thu 2024-09-12 13:40:42 CEST; 3s ago
    Process: 2901 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/bin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zon>
    Process: 2903 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 2904 (named)
      Tasks: 10 (limit: 4473)
     Memory: 7.6M
        CPU: 192ms
     CGroup: /system.slice/named.service
             └─2904 /usr/sbin/named -u named -c /etc/named.conf

Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: network unreachable resolving './NS/IN': 2001:500:a8::e#53
Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: network unreachable resolving './DNSKEY/IN': 2001:7fd::1#53
Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: network unreachable resolving './NS/IN': 2001:7fd::1#53
Sep 12 13:40:42 mach4.hviaene.thuis systemd[1]: Started named.service.
Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: resolver priming query complete: success
Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: checkhints: b.root-servers.net/A (170.247.170.2) missing from hints
Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: checkhints: b.root-servers.net/A (199.9.14.201) extra record in hints
Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: checkhints: b.root-servers.net/AAAA (2801:1b8:10::b) missing from hints
Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: checkhints: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints

The WAN connection is OK, as I'm writing this now in this configuration.

CC: (none) => herman.viaene

After reading comment 3, I'm not so sure that Herman agrees with the OK, katnatek. Removing it until he can confirm. 

Not in my wheelhouse, so I can't say one way or the other.

CC: (none) => sysadmin-bugs
Whiteboard: MGA9-64-OK => (none)
Keywords: (none) => validated_update

For the next few days, I cann't spend much time on the updates, so if someone else can address the server working and finds it OK, I will not object. Otherwise it will be next week monday when I can have a look again.

Basically copied my named config from my desktop where it works OK. Made  sure  the config files point to my own laptop address.
Started named, gives no error.
But still stuck with:
# nslookup mach1
;; communications error to 192.168.2.4#53: connection refused
mach1  being my desktop
mach4 being my own laptop address.

$ nc -zv 127.0.0.1 53
Connection to 127.0.0.1 53 port [tcp/domain] succeeded!
$ nc -zv 192.168.2.4 53
nc: connect to 192.168.2.4 port 53 (tcp) failed: Connection refused
192.168.2.4  being the fixed IP address of this wifi connection, which I use to write and save this comment.
Beats me......

(In reply to Herman Viaene from comment #3)
> MGA9-64 server Plasma Wayland on HP-Pavillion.
> No installation issues.
> As a client to my own LAN server on my desktop PC, all works well (always
> using fixed IP-addresses defined in the DNS-zone).
> Tried to setup this laptop as its own DNS-server. I run into problems: as
> soon I point the own address as first  DNS-server in the network settings
> (wifi), the whole LAN becomes unreachable, even its own IP-address , error
> "Connection refused".
> I used webmin to setup the DNS-server, on another attempt I used  MCC, but
> to no avail.
> At the CLI:
> # systemctl  restart named
> # systemctl -l status named
> ● named.service - Berkeley Internet Name Domain (DNS)
>      Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset:
> disabled)
>      Active: active (running) since Thu 2024-09-12 13:40:42 CEST; 3s ago
>     Process: 2901 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING"
> == "yes" ]; then /usr/bin/named-checkconf -z "$NAMEDCONF"; else echo
> "Checking of zon>
>     Process: 2903 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF}
> $OPTIONS (code=exited, status=0/SUCCESS)
>    Main PID: 2904 (named)
>       Tasks: 10 (limit: 4473)
>      Memory: 7.6M
>         CPU: 192ms
>      CGroup: /system.slice/named.service
>              └─2904 /usr/sbin/named -u named -c /etc/named.conf
> 
> Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: network unreachable
> resolving './NS/IN': 2001:500:a8::e#53
> Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: network unreachable
> resolving './DNSKEY/IN': 2001:7fd::1#53
> Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: network unreachable
> resolving './NS/IN': 2001:7fd::1#53
> Sep 12 13:40:42 mach4.hviaene.thuis systemd[1]: Started named.service.
> Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: managed-keys-zone: Key
> 20326 for zone . is now trusted (acceptance timer complete)
> Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: resolver priming query
> complete: success
> Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: checkhints:
> b.root-servers.net/A (170.247.170.2) missing from hints
> Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: checkhints:
> b.root-servers.net/A (199.9.14.201) extra record in hints
> Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: checkhints:
> b.root-servers.net/AAAA (2801:1b8:10::b) missing from hints
> Sep 12 13:40:42 mach4.hviaene.thuis named[2904]: checkhints:
> b.root-servers.net/AAAA (2001:500:200::b) extra record in hints
> 
> The WAN connection is OK, as I'm writing this now in this configuration.

Have you configured the firewall to allow inbound DNS connections on your test DNS nameserver?

I run BIND in my LAN and if I do not open 53/udp inbound to my nameserver I will see the same errors as you do. If you are also testing DNS zone transfers you will also need to open inbound 53/tcp

HTH

CC: (none) => paul.blackburn

No regressions on the three systems I have running bind. Two are x86_64, and one
is aarch64.

[dave@rp4 ~]$ rpm -q bind
bind-9.18.28-1.mga9
[dave@rp4 ~]$ systemctl status named.service
● named.service - Berkeley Internet Name Domain (DNS)
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: disabled)
     Active: active (running) since Thu 2024-09-26 00:14:32 EDT; 1 week 0 days ago
<snip>

CC: (none) => davidwhodgins

@ Paul
I always rely on MCC to open the necessary ports, so checked again: in MCC-Security Name server is checked on.
checked /etc/shorewall/rules.drakx: both 53/udp and 53/tcp are allowed.
But, no Sir ......

(In reply to Herman Viaene from comment #9)
> @ Paul
> I always rely on MCC to open the necessary ports, so checked again: in
> MCC-Security Name server is checked on.
> checked /etc/shorewall/rules.drakx: both 53/udp and 53/tcp are allowed.
> But, no Sir ......

@ Herman

You might wish to run drakfirewall on your bind server and verify that it is allowing inbound 53/udp and 53/tcp.

IMHO, it is always better to explicitly configure what you will need to be done with bind rather than rely on an assumed auto configuration.

Also, no harm to run an nmap scan on your bind server from another computer in your lan. Again to verify your bind is accessible from your lan.

Something like: https://pastebin.com/NjbmP9D6

HTH, YMMV

That's what MCC does: drakfirewall. And I always have to set the ports in that way, there is no auto configuration.
And in fact the LAN does not really come into play: The failure I report is occuring trying the access to bind on the same bind server itself. And in that situation I get access to the internet via wifi to my router, so there is nothing wrong there.

you can run the nmap accessibility tests on the nameserver itself. including on 127.0.0.1.

All you are doing is confirming the connection on 53/udp and 53/tcp are working.