Ubuntu has issued an advisory on July 23: https://ubuntu.com/security/notices/USN-6909-1 Those CVEs were announced here: https://www.openwall.com/lists/oss-security/2024/07/23/1. The problems are fixed in version 9.18.28. See: https://downloads.isc.org/isc/bind9/9.18.28/patches/
Status comment: (none) => Fixed upstream in 9.18.28 and patches available from upstream and UbuntuWhiteboard: (none) => MGA9TOOSource RPM: (none) => bind-9.18.24-1.mga10.src.rpmCVE: (none) => CVE-2024-0760, CVE-2024-1737, CVE-2024-1975, CVE-2024-4076
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 => 9Assignee: nicolas.salguero => qa-bugsSource RPM: bind-9.18.24-1.mga10.src.rpm => bind-9.18.15-2.3.mga9.src.rpmStatus comment: Fixed upstream in 9.18.28 and patches available from upstream and Ubuntu => (none)Whiteboard: MGA9TOO => (none)Status: NEW => ASSIGNED
Keywords: (none) => advisory
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
CC: (none) => andrewsfarmWhiteboard: (none) => MGA9-64-OK
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.
Whiteboard: MGA9-64-OK => (none)Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
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.
Keywords: validated_update => (none)
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......
Keywords: (none) => feedback
(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.
Well, beat me, I don't get it. In drakfirewall Domain name server is set on. /etc/shorewall/rules.drakx reads: ACCEPT net fw udp 53,111,2049,4002,4001,4003,4004,631,3306,5353,427,8612 - ACCEPT net fw tcp 80,443,53,109,110,143,993,995,111,2049,4002,4001,4003,4004,631,3306,10000 - ACCEPT net fw icmp 8 - But # nmap 127.0.0.1 Starting Nmap 7.94 ( https://nmap.org ) at 2024-10-09 17:19 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.000033s latency). Not shown: 996 closed tcp ports (reset) PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 443/tcp open https 631/tcp open ipp Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds And I can confirm that access to my NFS-shares works OK.
It looks like BIND isn't actually running.
The other way to check the status of named is with "rndc". Example: [user@nameserver ~]$ /bin/sudo rndc status [sudo] password for user: version: BIND 9.18.15 (Extended Support Version) <id:> running on localhost: Linux x86_64 6.6.52-desktop-1.mga9 #1 SMP PREEMPT_DYNAMIC Thu Sep 19 20:27:15 UTC 2024 boot time: Sun, 06 Oct 2024 15:14:47 GMT last configured: Sun, 06 Oct 2024 15:14:48 GMT configuration file: /etc/named.conf CPUs found: 2 worker threads: 2 UDP listeners per interface: 2 number of zones: 106 (97 automatic) debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON recursive clients: 0/900/1000 tcp clients: 0/150 TCP high-water: 2 server is up and running
# 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-10-10 10:35:06 CEST; 6s ago Process: 5229 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/bin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zon> Process: 5231 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 5232 (named) Tasks: 10 (limit: 4473) Memory: 7.7M CPU: 183ms CGroup: /system.slice/named.service └─5232 /usr/sbin/named -u named -c /etc/named.conf Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: network unreachable resolving './DNSKEY/IN': 2001:7fe::53#53 Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: network unreachable resolving './NS/IN': 2001:7fe::53#53 Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: network unreachable resolving './DNSKEY/IN': 2001:500:1::53#53 Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: network unreachable resolving './NS/IN': 2001:500:1::53#53 Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete) Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: resolver priming query complete: success Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: checkhints: b.root-servers.net/A (170.247.170.2) missing from hints Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: checkhints: b.root-servers.net/A (199.9.14.201) extra record in hints Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: checkhints: b.root-servers.net/AAAA (2801:1b8:10::b) missing from hints Oct 10 10:35:06 mach4.hviaene.thuis named[5232]: checkhints: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints # nmap 127.0.0.1 Starting Nmap 7.94 ( https://nmap.org ) at 2024-10-10 10:35 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.000033s latency). Not shown: 996 closed tcp ports (reset) PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 443/tcp open https 631/tcp open ipp Nmap done: 1 IP address (1 host up) scanned in 0.42 seconds # rndc status version: BIND 9.18.28 (Extended Support Version) <id:> running on localhost: Linux x86_64 6.6.52-server-1.mga9 #1 SMP PREEMPT_DYNAMIC Thu Sep 19 21:37:46 UTC 2024 boot time: Thu, 10 Oct 2024 08:35:06 GMT last configured: Thu, 10 Oct 2024 08:35:06 GMT configuration file: /etc/named.conf CPUs found: 4 worker threads: 4 UDP listeners per interface: 4 number of zones: 106 (98 automatic) debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/900/1000 tcp clients: 0/150 TCP high-water: 0 server is up and running
And I made the update to this bug in this status via wifi. So networking basically works.
@herman, Please put a copy of your /etc/named.conf in a pastebin post and shere the link here.
https://app.box.com/s/bd54mpdgnxcb40rf33sqfhif7jrgg0oe
@herman, That link does not work for me. Displays error message: "This preview didn't load because the file type is unsupported. Please try to open or download the file to view." I will try again. For reference, here is my /etc/named.conf for comparison. In this I have marked all my modifications with "//LOCAL" to help understand how it was configured. Key thing to note is the logging section. I have my named logs saved in /var/log/named/. This and the log files in there need to be chown named;named: [user@nameserver ~]$ ls -l /var/log/named total 32 -rw-rw-r-- 1 root named 19642 Oct 9 22:07 default.log -rw-rw-r-- 1 root named 0 Oct 1 16:35 notify.log -rw-rw-r-- 1 root named 4561 Oct 10 01:36 query.log -rw-rw-r-- 1 root named 0 Oct 1 16:35 security.log -rw-rw-r-- 1 root named 0 Oct 1 16:35 update.log -rw-rw-r-- 1 root named 0 Oct 1 16:35 xfer-in.log -rw-rw-r-- 1 root named 0 Oct 1 16:35 xfer-out.log The logs will help you figure out what is not working or misconfigured whan you run: systemctl start named.service && systemctl statys named.service working example /etc/named.conf: https://pastebin.com/BjhvbvdQ HTH
correction: ownership root:named will work as well (as shown)
@herman, In your /etc/named.conf, you have "allow query" commented out on line 19: 19 /* allow-query { localhost; }; */
@herman, in my /etc/named.conf, defined which hosts are allowed to query using: 33 // #LOCAL allow-query { localhost; }; 34 allow-query { trusted_networks; }; 35 allow-recursion { trusted_networks; }; "trusted_networks" is defined in the include file: /etc/named/named_trusted_networks_acl.conf Included on line: 16 include "/etc/named/named_trusted_networks_acl.conf"; // #LOCAL Contents of /etc/named/named_trusted_networks_acl.conf: 1 // NOTE: You have to maintain this list yourself. In Mandriva Linux we allow 2 // the 192.168.0.0/16 network to do recursive lookups per default. If you 3 // don't like this you need to change this now. 4 // 5 // You may need to add specific ip addresses here as well. 6 // 7 // $Id: trusted_networks_acl.conf 80849 2007-09-06 11:56:48Z oden $ 8 // $HeadURL: svn+ssh://svn.mandriva.com/svn/packages/cooker/bind/current/SOURCES/trusted_networks_acl.conf $ 9 10 acl "trusted_networks" { 11 // If you are using RFC1918 netblocks please remember to 12 // comment these in the bogon_acl.conf file. 13 127.0.0.1; 14 192.168.0.0/16; 15 }; Also, I don't need to use DNSSEC because my nameserver is just local to my rfc1918 subnet so I found I needed to comment out: 51 // #LOCAL 2023_10_09 - comment out "dnssec-enable yes;" because named fails to start when set to "yes" 52 // dnssec-enable yes; HTH
I checked your remarks against my desktop PC which runs bind OK. My laptops all refer to that one as first DNS-server and no problems there. "allow query" is commented out there is no line dnssec-enable, but there is: dnssec-validation yes; thus not commented out Never bothered about trusted_networks.
Just noticed that your nmap scan does not show 53/TCP open.
Recommend you configure logging perhaps as per example. The log files will probably provide more clues about what is happening. I also find it useful to enable query logging: /bin/sudo rndc querylog #enable Then: tail -f /var/log/named/querylog Make a resolution request and confirm it appears in the query log. Example: host mageia.org ${namserver_IP_address} HTH
HMMMMM tail -f /var/log/named/querylog tail: cannot open '/var/log/named/querylog' for reading: No such file or directory tail: no files remaining
@herman, The logfiles do not automatically appear. You configure them in /etc/named.conf ## start of extract from /etc/named.conf ------------------------ // Define logging channels // #LOCAL include "/etc/named/logging.conf"; // #LOCAL ## end of extract from /etc/named.conf -------------------------- The details of names of logfiles are in /etc/named/logging.conf I use the following makefile for my bind logfiles: ## start of /usr/local/src/var/log/named/Makefile --------------- # create log files used by BIND nameserver install: echo "install: do nothing" new: echo "new: configure named log files" mkdir /var/log/named/ chgrp named /var/log/named/ chmod g+w /var/log/named/ touch /var/log/named/security.log touch /var/log/named/default.log touch /var/log/named/xfer-in.log touch /var/log/named/xfer-out.log touch /var/log/named/update.log touch /var/log/named/notify.log touch /var/log/named/query.log chgrp named /var/log/named/security.log chgrp named /var/log/named/default.log chgrp named /var/log/named/xfer-in.log chgrp named /var/log/named/xfer-out.log chgrp named /var/log/named/update.log chgrp named /var/log/named/notify.log chgrp named /var/log/named/query.log chmod g+w /var/log/named/security.log chmod g+w /var/log/named/default.log chmod g+w /var/log/named/xfer-in.log chmod g+w /var/log/named/xfer-out.log chmod g+w /var/log/named/update.log chmod g+w /var/log/named/notify.log chmod g+w /var/log/named/query.log ## end of /usr/local/src/var/log/named/Makefile ----------------- HTH.
/usr/local/src/ is empty.
@Herman, Yes, I would guess that /usr/local/src/ would be empty on your and most others. That was mentioned in a comment in my comment#28 (above) which was giving you an example of how the named logfiles can be created. I prefer to manage configuration and other "local" stuff from a separate source not to directly edit the live files. It helps me keep track of changes and makes it much simpler when maintaining or rebuilding. YMMV. I could, if you wish, explain in a private channel how I use /usr/local/src/ but I think this is out of scope for this bug report 33437. Regarding /var/log/named/querylog being missing: the key things are: + installing bind does not automatically create the logfiles + logfiles names and details are defined via /etc/named.conf + you can create them any way you choose. (I showed my example.) HTH.
I see what you do in creating the /var/log files, and you refer to a logging.conf file. But that one doesn't exist either. I'm googling around to find info on configuring logging and found some intereesting example, but I will have to adapt channel names to what you propose. Working on it .......
Starting named now fails with /etc/named/logging.conf:1: 'logging' redefined near 'logging' Attaching my /etc/named/logging.conf
Created attachment 14731 [details] defintion of logging files
@Herman, I checked my /etc/named/logging.conf. It has the header: // $Id: logging.conf 80849 2007-09-06 11:56:48Z oden $ // $HeadURL: svn+ssh://svn.mandriva.com/svn/packages/cooker/bind/current/SOURCES/logging.conf $ I also checked the current Mageia 9 bind package which does not seem to contain a logging.conf file. So, I think I must have used the logging.conf from a release of Mandriva and kept using that. I do have experience managing and configuring production BIND servers but I recognize that it could seem a bit complex at first look. I also checked for some official BIND documentation which could help you. This looks potentially useful: https://kb.isc.org/docs/aa-01526 HTH.
Tx,, I found that site, that's where I found the example to setup my logging.conf file. I give up here. It is the umpteenth time I test a bind update and always got it working. But it is the first time on this particular machine. And to make things even worse: I removed the logging from the conf, downgraded bin and bin-utils and now named runs and I can at least address my own name and IP-address with ping or nslookup, not the rest of the zone.
Sorry, mistake: nslookup does give communication error as before.
I have just simply let rpmdrake install updates, and used as normal desktop user... System now have two versions of the lib! Is that OK? lib64bind9.18.28-9.18.28-1.mga9.x86_64 lib64bind9.18.15-9.18.15-2.3.mga9.x86_64 [morgan@svarten ~]$ rpm -qa --last | grep bind lib64bind9.18.28-9.18.28-1.mga9.x86_64 mån 23 sep 2024 22:41:19 bind-utils-9.18.28-1.mga9.x86_64 mån 23 sep 2024 22:41:19 lib64bind9.18.15-9.18.15-2.3.mga9.x86_64 fre 16 feb 2024 13:57:46 samba-winbind-4.17.12-1.mga9.x86_64 ons 6 dec 2023 12:08:22 samba-winbind-modules-4.17.12-1.mga9.x86_64 ons 6 dec 2023 12:08:21 python3-xapian-bindings-1.4.20-1.mga9.x86_64 ons 18 okt 2023 09:02:26 rpcbind-1.2.6-2.mga9.x86_64 ons 14 jun 2023 10:41:45 lib64keybinder3.0_0-0.3.0-11.mga9.x86_64 fre 28 apr 2023 16:49:02 [morgan@svarten ~]$ rpm -qa | grep 9.18.15 lib64bind9.18.15-9.18.15-2.3.mga9
CC: (none) => fri
Saw Marja's request for testing. I installed and set up a simple bind nameserver on a spare box with a local zone and then with recursion enabled. Tested with the old version and then updated to lib64bind9.18.28-9.18.28-1.mga9 bind-dnssec-utils-9.18.28-1.mga9 bind-9.18.28-1.mga9 The update worked well for me - exactly like the original. I tested name resolution both on the box bind was installed on and from another machine on my network. The local zone and recursion both worked as expected. My setup uses flat files so operation with mysql and company were not tested. Looks ok to me. (In reply to Morgan Leijström from comment #37) > > System now have two versions of the lib! Is that OK? > > lib64bind9.18.28-9.18.28-1.mga9.x86_64 > lib64bind9.18.15-9.18.15-2.3.mga9.x86_64 > Unknown if this is normal, but mine is the same and it doesn't appear to break anything.
CC: (none) => mhrambo3501
I installed bind-9.18.28-1.mga9 in an x86_64 virt-manager VM. After enabling "Domain Name Server" in drakfirewall and editing the default /etc/named.conf file to replace the two listen-on* lines with "listen-on port 53 { any; };" and commenting out the allow-query line, bind served DNS to me from the host computer over the virtual Ethernet port and over localhost just fine. The default config files define a few hosts that should work out-of-the-box: $ host a.root-servers.net localhost Using domain server: Name: localhost Address: ::1#53 Aliases: a.root-servers.net has address 198.41.0.4 a.root-servers.net has IPv6 address 2001:503:ba3e::2:30 $ host localhost.localdomain 192.168.112.49 Using domain server: Name: 192.168.112.49 Address: 192.168.112.49#53 Aliases: localhost.localdomain has address 127.0.0.1 localhost.localdomain has IPv6 address ::1
CC: (none) => dan
Herman did you copy the configuration from other system I wonder if that system is in the same network and if you change the domain name in the test system (i.e if the testing system is serving the same domain and is in the same network that the system where the conf files come, could produce some conflict?)
It's in the same network, same domain name. You could be right, I've done this type of test multiple times in the past, so this could be something new to consider. So this is not a regression, but an unexpected result from a in se inconsistent setup that went unnoticed in the past. In view of other people's testing, I let go.
Whiteboard: (none) => MGA9-64-OK
Thank you for testing. Validating then. I still find it odd that the old version of lib is kept installed too, and should be looked into for next round for potential problems.
Keywords: feedback => validated_update
urpme --auto-orphans That will uninstall the old lib. It does look like a packaging mistake though. I'm not sure how the whole bind version ended up in the lib name.
(In reply to David Walser from comment #43) > urpme --auto-orphans > > That will uninstall the old lib. It does look like a packaging mistake > though. I'm not sure how the whole bind version ended up in the lib name. Not necessarily. I recently tried that after testing another update that left a lot of stuff behind. urpme refused to remove anything, because a kernel-devel was listed and needed by dkms. There's a bug about that, isn't there?
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2024-0342.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED