Fedora has issued an advisory today (August 12): https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/5L3ZFWZZFPBIL654BG75RWXUMPFQJ5EC/ The issues are fixed upstream in 1.16.2. Mageia 8 is also affected.
Status comment: (none) => Fixed upstream in 1.16.2Whiteboard: (none) => MGA8TOO
Ubuntu has issued an advisory for this on August 16: https://ubuntu.com/security/notices/USN-5569-1
Hi. Do you need any support? The MGA8 version is now quite old.
CC: (none) => chb0
Hi. I just succeeded to build it locally. Cauldron is up-to-date. If you allow me, I can take it an update MGA8.
Hi again. After discussing with Luigi on IRC, I take it on, while eatdirt is out.
Version: Cauldron => 8Whiteboard: MGA8TOO => (none)Source RPM: unbound-1.15.0-1.mga9.src.rpm => unbound-1.13.0-2.mga8.src.rpmAssignee: eatdirt => chb0
Hi. Ready for QA. ADVISORY NOTICE PROPOSAL ======================== Updated unbound packages fix security vulnerabilities and bugs Description Update to version 1.16.2 fixes many bugs (along with versions 1.13.1, 1.13.2, 1.14.0, 1.15.0, 1.16.0 and 1.16.1), and protects against CVE-2022-3069[89] References https://bugs.mageia.org/show_bug.cgi?id=30743 https://github.com/NLnetLabs/unbound/releases/tag/release-1.13.1 https://github.com/NLnetLabs/unbound/releases/tag/release-1.13.2 https://github.com/NLnetLabs/unbound/releases/tag/release-1.14.0 https://github.com/NLnetLabs/unbound/releases/tag/release-1.15.0 https://github.com/NLnetLabs/unbound/releases/tag/release-1.16.0 https://github.com/NLnetLabs/unbound/releases/tag/release-1.16.1 https://github.com/NLnetLabs/unbound/releases/tag/release-1.16.2 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30698 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30699 SRPMS 8/core unbound-1.16.2-1.mga8.src.rpm PROVIDED PACKAGES: lib64unbound8-1.16.2-1.mga8 lib64unbound-devel-1.16.2-1.mga8 unbound-1.16.2-1.mga8 python3-unbound-1.16.2-1.mga8 PACKAGES FOR QA TESTING ======================= x86_64: lib64unbound8-1.16.2-1.mga8.x86_64.rpm lib64unbound-devel-1.16.2-1.mga8.x86_64.rpm unbound-1.16.2-1.mga8.x86_64.rpm python3-unbound-1.16.2-1.mga8.x86_64.rpm i586: lib64unbound8-1.16.2-1.mga8.i586.rpm lib64unbound-devel-1.16.2-1.mga8.i586.rpm unbound-1.16.2-1.mga8.i586.rpm python3-unbound-1.16.2-1.mga8.i586.rpm
Assignee: chb0 => qa-bugsCC: (none) => eatdirt, sysadmin-bugs
Test done on Plasma x86_64 Update from 1.13.0 using QArepo. Service restart on 1.16.2 2 subsequent "dig mageia.org" confirm local server is used and inquiry is cached: $ dig mageia.org #first command ; <<>> DiG 9.11.37Mageia-1.mga8 <<>> mageia.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27700 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mageia.org. IN A ;; ANSWER SECTION: mageia.org. 1800 IN A 163.172.148.228 ;; Query time: 358 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: dim. août 21 23:21:28 CEST 2022 ;; MSG SIZE rcvd: 55 $ dig mageia.org #second command ; <<>> DiG 9.11.37Mageia-1.mga8 <<>> mageia.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9708 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mageia.org. IN A ;; ANSWER SECTION: mageia.org. 1785 IN A 163.172.148.228 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: dim. août 21 23:21:43 CEST 2022 ;; MSG SIZE rcvd: 55
Status comment: Fixed upstream in 1.16.2 => (none)CC: sysadmin-bugs => (none)
MGA8-64 Plasma on Acer Aspire 5253 No installation issues Ref bug 28447 Comment 4 for testing # systemctl start unbound # systemctl -l status unbound ● unbound.service - Unbound DNS Resolver Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled; vendor preset: disabled) Active: active (running) since Mon 2022-08-22 15:33:41 CEST; 2s ago Main PID: 23434 (unbound) Tasks: 1 (limit: 4364) Memory: 5.9M CPU: 95ms CGroup: /system.slice/unbound.service └─23434 /usr/sbin/unbound -c /etc/unbound/unbound.conf Aug 22 15:33:41 mach7.hviaene.thuis systemd[1]: Started Unbound DNS Resolver. Aug 22 15:33:41 mach7.hviaene.thuis unbound[23434]: [23434:0] notice: init module 0: validator Aug 22 15:33:41 mach7.hviaene.thuis unbound[23434]: [23434:0] notice: init module 1: iterator Aug 22 15:33:41 mach7.hviaene.thuis unbound[23434]: [23434:0] info: start of service (unbound 1.16.2). But repeating Christian's test above $ dig mageia.org ; <<>> DiG 9.11.37Mageia-1.mga8 <<>> mageia.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47331 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 13 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 784ec1d68f074cda601f2bfd630385c65e11f4d2f2485811 (good) ;; QUESTION SECTION: ;mageia.org. IN A ;; ANSWER SECTION: mageia.org. 1290 IN A 163.172.148.228 ;; AUTHORITY SECTION: org. 147882 IN NS a0.org.afilias-nst.info. org. 147882 IN NS b0.org.afilias-nst.org. org. 147882 IN NS d0.org.afilias-nst.org. org. 147882 IN NS b2.org.afilias-nst.org. org. 147882 IN NS a2.org.afilias-nst.info. org. 147882 IN NS c0.org.afilias-nst.info. ;; ADDITIONAL SECTION: d0.org.afilias-nst.org. 147882 IN A 199.19.57.1 c0.org.afilias-nst.info. 147882 IN A 199.19.53.1 a0.org.afilias-nst.info. 147882 IN A 199.19.56.1 b0.org.afilias-nst.org. 147882 IN A 199.19.54.1 b2.org.afilias-nst.org. 147882 IN A 199.249.120.1 a2.org.afilias-nst.info. 147882 IN A 199.249.112.1 d0.org.afilias-nst.org. 147882 IN AAAA 2001:500:f::1 c0.org.afilias-nst.info. 147882 IN AAAA 2001:500:b::1 a0.org.afilias-nst.info. 147882 IN AAAA 2001:500:e::1 b0.org.afilias-nst.org. 147882 IN AAAA 2001:500:c::1 b2.org.afilias-nst.org. 147882 IN AAAA 2001:500:48::1 a2.org.afilias-nst.info. 147882 IN AAAA 2001:500:40::1 ;; Query time: 3 msec ;; SERVER: 192.168.2.1#53(192.168.2.1) ;; WHEN: Mon Aug 22 15:33:58 CEST 2022 ;; MSG SIZE rcvd: 485 This laptop via wifi is in a LAN with a local DNS server, and I see that the server line points to this server, not to the unbound on local host. I have no idea how to change this network behavior.
CC: (none) => herman.viaene
Hi Herman Was it behaving like that before? In /etc/resolv.conf do you have # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1
Note /etc/resolv.conf is a generated using the files in /etc/resolvconf/resolv.conf.d/ I have ... # cat /etc/resolvconf/resolv.conf.d/head # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver ::1 nameserver 127.0.0.1 With bind being used on localhost for dns. Putting the entries in the head file prepends them before anything added by drakx-net or networkmanager.
CC: (none) => davidwhodgins
I never touch resolv.conf, I give each machine in my LAN a fixed IP-address which is registered in the DNS-server I run on my main dekstop PC. And that's the one you see in the "Server" line at the end of the feedback of the dig command.
Unbound is a DNS server. You can either change resolv.conf to make your computer test it, or you can test it directly with nslookup (there's probably a way with dig, check the man page) by giving 127.0.0.1 as a second argument.
Hi Herman You don’t need to change resolv.conf manually. I asked about it to understand your configuration. What you can do is to change dns to 127.0.0.1 with net_applet or networkmanager to test; then, you revert back.
Sorry, tablet glitch. You got my comment twice….
Followed suggestion,set dns to 127.0.0.1 Then # systemctl start unbound # systemctl -l status unbound ● unbound.service - Unbound DNS Resolver Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2022-08-24 09:17:56 CEST; 5s ago Main PID: 3940 (unbound) Tasks: 1 (limit: 4364) Memory: 7.3M CPU: 106ms CGroup: /system.slice/unbound.service └─3940 /usr/sbin/unbound -c /etc/unbound/unbound.conf Aug 24 09:17:56 mach7.hviaene.thuis systemd[1]: Started Unbound DNS Resolver. Aug 24 09:17:56 mach7.hviaene.thuis unbound[3940]: [3940:0] notice: init module 0: validator Aug 24 09:17:56 mach7.hviaene.thuis unbound[3940]: [3940:0] notice: init module 1: iterator Aug 24 09:17:56 mach7.hviaene.thuis unbound[3940]: [3940:0] info: start of service (unbound 1.16.2). And $ dig mageia.org ; <<>> DiG 9.11.37Mageia-1.mga8 <<>> mageia.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64761 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mageia.org. IN A ;; Query time: 4042 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Aug 24 09:18:24 CEST 2022 ;; MSG SIZE rcvd: 39 That's not OK, I guess.
(In reply to Herman Viaene from comment #15) > > ;; Query time: 4042 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Aug 24 09:18:24 CEST 2022 > ;; MSG SIZE rcvd: 39 > > That's not OK, I guess. It is ok. 127.0.0.1 is used as dns server. If you run the dig query twice, you should then get Query time: 0 msec showing the query has been cached
Herman is correct. There is something wrong. # netstat -tapn|grep unbound tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 40357/unbound tcp6 0 0 ::1:53 :::* LISTEN 40357/unbound [root@x3 ~]# dig ANY mageia.org ; <<>> DiG 9.11.37Mageia-1.mga8 <<>> ANY mageia.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51375 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mageia.org. IN ANY ;; ANSWER SECTION: mageia.org. 1605 IN AAAA 2001:bc8:628:1f00::1 mageia.org. 1471 IN MX 10 sucuk.mageia.org. mageia.org. 1471 IN MX 20 neru.mageia.org. ;; Query time: 171 msec ;; SERVER: 2607:f2c0::1#53(2607:f2c0::1) ;; WHEN: Wed Aug 24 13:57:17 EDT 2022 ;; MSG SIZE rcvd: 110 [root@x3 ~]# dig ANY mageia.org ;; communications error to ::1#53: end of file ;; communications error to ::1#53: end of file It's not a consistent error though.
Most of the time when it fails, dig simply does not return an answer section or any error message. # dig ANY mageia.org ; <<>> DiG 9.11.37Mageia-1.mga8 <<>> ANY mageia.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25116 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mageia.org. IN ANY ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Aug 24 14:10:38 EDT 2022 ;; MSG SIZE rcvd: 39 After stopping unbound.service and starting named.service, I consistently get the answer section returned with ;; ANSWER SECTION: mageia.org. 1793 IN MX 10 sucuk.mageia.org. mageia.org. 1793 IN MX 20 neru.mageia.org. mageia.org. 1793 IN SOA ns0.mageia.org. root.mageia.org. 2022071601 7200 3600 86400 300 mageia.org. 1793 IN AAAA 2001:bc8:628:1f00::1 mageia.org. 1793 IN A 163.172.148.228 mageia.org. 1793 IN NS ns1.mageia.org. mageia.org. 1793 IN NS ns0.mageia.org.
I was too much focusing on making sure localhost is the server use to resolve the query…. Indeed, the query is not successful. Are you using the unbound.conf shipped with the package or your own version? Do you get the same results with current version of unbound, 1.13.0? It works well on my side but I have tweaked the unbound.conf to my taste.
I'd never installed unbound prior to installing the testing version, and didn't make any configuration changes prior to starting the unbound.service I'll test the prior version of unbound shortly.
Uninstalled the testing version, deleted /etc/unbound. Installed the release version. [root@x3 ~]# rpm -q unbound unbound-1.13.0-2.mga8 [root@x3 ~]# systemctl stop named.service [root@x3 ~]# systemctl start unbound.service [root@x3 ~]# dig ANY mageia.org ;; communications error to 2607:f2c0::1#53: connection reset After that dig ANY mageia.org consistently returns ;; ANSWER SECTION: mageia.org. 1717 IN A 163.172.148.228 mageia.org. 1717 IN AAAA 2001:bc8:628:1f00::1 mageia.org. 1717 IN SOA ns0.mageia.org. root.mageia.org. 2022071601 7200 3600 86400 300 mageia.org. 1717 IN NS ns1.mageia.org. mageia.org. 1717 IN NS ns0.mageia.org. mageia.org. 1717 IN MX 20 neru.mageia.org. mageia.org. 1717 IN MX 10 sucuk.mageia.org. So while the first failure doesn't look good, the inconsistency is a regression in the updates testing version.
Thanks Dave. I will have a look at the configuration file this weekend. In your test with the current version, what is the server information you get after getting mageia.org resolved?
Ah. Not a regression. # dig ANY google.com ; <<>> DiG 9.11.37Mageia-1.mga8 <<>> ANY google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34138 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;google.com. IN ANY ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Aug 24 16:03:02 EDT 2022 ;; MSG SIZE rcvd: 39
Looks like it's just dig that has problems. Both host and nslookup are working properly with both the release and updates testing versions of unbound.
Back with the updates testing version of unbound ... [root@x3 ~]# host ody.ca ody.ca has address 216.240.0.3 ody.ca mail is handled by 5 mgw.ody.ca. [root@x3 ~]# dig ody.ca ; <<>> DiG 9.11.37Mageia-1.mga8 <<>> ody.ca ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34321 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;ody.ca. IN A ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Aug 24 16:10:49 EDT 2022 ;; MSG SIZE rcvd: 35 So even though dig is failing to return answers, normal dns usage is working.
As it's not a regression and normal usage is working, I'm inclined to ok the update. Ok with you Christian or do you see a way to fix the dig usage.
Hi Dave. I agree to validate it. I will dig more into the dig issue though :) and I will update the package if it is related to the configuration file we ship. Thanks for your support.
Could you comment out the last block of /etc/unbound.conf , restart unbound service and retest ? Block to comment out: #forward-zone: # name: "." # forward-addr: 127.0.0.1@40 # forward-addr: 127.0.0.1@41
I just looked at Fedora and openSUSE spec and configuration files. They go beyond us to configure unbound. They set the root server list up, for instance. We could also activate DNSSEC. I’d like to suggest we follow that path. However, as eatdirt is the official maintainer, I need his view on this first. In the meanwhile, as it is a security update, I propose we validate this update with the same configuration we havé been providing eg the in Testing.
Validating. We can do the config fixes which should fix dig in a future bugfix update. Advisory committed to svn.
Keywords: (none) => advisory, validated_updateWhiteboard: (none) => MGA8-64-OKCC: (none) => sysadmin-bugs
I am back :) Thanks for taking care of this! For the config, we cannot satisfy everyone, I am using unbound everday on top of dnscrypt-proxy, so it does work. Any specific usage will require the configuration to be edited, I do prefer to let this user-side. Cheers, Chris.
Welcome back Chris ! Ok. Got you. Quick question : what is purpose to have the following forward-zone set into the conf file we provide? forward-zone: name: "." forward-addr: 127.0.0.1@40 forward-addr: 127.0.0.1@41
This matches the listen addresses of dnscrypt-proxy, so it you install both packages, dns encryption works out of the box!
Could it confuse dig sometimes to time? I have not seen yet this configuration with other distributions. Shouldn’t it be a user specific configuration, up then to the user to set?
From systemctl status unbound.service Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled; vendor preset: disabled) After installation the user is supposed to ensure the configuration is the way they want it, before enabling and/or starting the service.
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2022-0303.html
Status: NEW => RESOLVEDResolution: (none) => FIXED