[SRU] Segfault in dnsmasq when using certain static domain entries + DoH (bugfix possibly exists upstream)

[Gordon G]

[ Impact ]

Some users may face an unpleasant segmentation fault if they combine configurations options like
server=/domain/# with server|address=/domain/<ip> since the domain matching functionality was rewritten in
version 2.86.

The special server address ’#’ means "use the standard servers". The SEGV occurs due to the struct server
datastructure associated with it is passed to forward_query() call without been properly reserved and filled
due to resolvconf servers didn't belong to the priority list.

Without resolving this, dnsmasq stops running due to the SEGV and (non-experienced) users might not notice it.

[ Test Plan ]

#0.Prepare a VM or Container. i.e:
# lxc launch ubuntu-daily:jammy Jdnsmasq

#1. Install dnsmasq
# apt update && apt upgrade -y
# apt install -y dnsmasq

#2. Disable systemd-resolved service and enabling resolution through dnsmasq, configuring DNS servers through it.

# systemctl disable --now systemd-resolved.service
# rm -f /etc/resolv.conf
# cat > /etc/resolv.conf << __EOF__
nameserver 127.0.0.1
__EOF__
# echo "server=8.8.8.8" >> /etc/dnsmasq.conf (or edit the file to add it if you prefer)
# (Optional) echo "log-queries" >> /etc/dnsmasq.conf
# (optional) echo "log-debug" >> /etc/dnsmasq.conf
# systemctl start dnsmasq.service

3. Copy netflix-nov6.conf into /etc/dnsmasq.d/
# cat > /etc/dnsmasq.d/netflix-nov6.conf << __EOF__
# Null AAAA response on these domains
server=/netflix.com/#
address=/netflix.com/::
server=/netflix.net/#
address=/netflix.net/::
server=/nflxext.com/#
address=/nflxext.com/::
server=/example.com/#
address=/example.com/::
__EOF__

#4. Restart/reload dnsmasq
# systemctl restart dnsmasq

#5. Verify that dnsmasq resolves domains correctly:

root@Jdnsmasq:~# dig +short -tA ubuntu.com @127.0.0.1
185.125.190.21
185.125.190.20
185.125.190.29
root@Jdnsmasq:~# dig +short -tAAAA ubuntu.com @127.0.0.1
2620:2d:4000:1::28
2620:2d:4000:1::26
2620:2d:4000:1::27

#6. Perform a type65 / HTTPS recordtype query for netflix.com towards the dnsmasq server twice:

root@Jdnsmasq:~# dig A netflix.com @127.0.0.1

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> A netflix.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 48730
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 23 (Network Error)
;; QUESTION SECTION:
;netflix.com. IN A

;; Query time: 23 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Nov 15 16:46:19 UTC 2023
;; MSG SIZE rcvd: 46

root@Jdnsmasq-checking:~# dig A netflix.com @127.0.0.1
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused

#7. Check logs to verify segfault:
# journalctl -u dnsmasq

Apr 27 11:22:52 Jdnsmasq systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
Apr 27 11:22:53 Jdnsmasq dnsmasq[111585]: query[type=65] netflix.com from 127.0.0.1
Apr 27 11:22:53 Jdnsmasq dnsmasq[111585]: config error is REFUSED (EDE: network error)
Apr 27 11:22:54 Jdnsmasq dnsmasq[111585]: query[type=65] netflix.com from 127.0.0.1
Apr 27 11:22:54 Jdnsmasq systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV
Apr 27 11:22:54 Jdnsmasq systemd[1]: dnsmasq.service: Failed with result 'core-dump'.

[ Where problems could occur ]

 This cherry picked commit from upstream incorporates a rewrite of the server priority list in the dnsmasq header file.
 Fortunately, that headers are not exported outside dnsmasq, so it cannot impact other third-party pieces of software.
 However, it can lend to think about the matching domain functionality that is being patched: could it be affect in
 some way to other types of server displaced on that list? Does anything change for the rest? In other words... Is the
 matching domain functionality working as expected, without behavioral changes?

 This change is supported yet in lastest version of dnsmasq, so we can suppose it is well tested. But, anyway, in
 [Other Info] section I included some query examples for well-known domains, so we can be more confident with this change.
 Is true that there is always room for disruption in the way the domain queries are answered due to this kind of changes: that's
 the situation on which problems can occur (in this case, mistmached domain: then, yes, it can affect other third parties that uses dnsmasq).

 Could another SEGV situation happen attending to this matching domain patch? At first sight no, because resolvconf servers were the only entity excluded from the matching list by priority.

[ Other Info ]
  Some extra test for checking the domain queries are recovering correct addresses, in basic situations:

    * If we set specifically a pair or domain/address combination in dnsmasq.conf:
      $ echo "address=/domain/1.2.3.4" >> /etc/dnsmasq.conf
      $ systemctl restart dnsmasq
      $ dig +short A domain
      1.2.3.4

    * If we ask for a known domain address, and we check the addres led us to the desired domain (using a web-browser, for example). We can test it
      with the dnsmasq's developers themself:

      $ dig +short A www.thekelleys.org.uk @127.0.0.1
      thekelleys.org.uk.
      85.119.82.65

      -> Browse using http://85.119.82.65 and see that led you to thekelleys web page (unfortunately insecure)

[Original Description]
----------------------------------------------------------------
Hi folks,

I've been using dnsmasq for my home DNS needs, which includes returning null entries for certain domain queries. The specific case in which I found this segfault was returning null AAAA records for Netflix (to ensure Netflix does not try to use my IPv6 tunnel to egress traffic through).

I've been using very simple configuration snippet to achieve this, this is attached as netflix-nov6.conf (the full file contains more entries).

Ever since I've upgraded from Ubuntu 20.04 to 22.04, dnsmasq kept segfaulting at random occasions. I also attempted do an apt update&&upgrade, but there are no newer versions of this package available.

Further research into this issue showed that a surefire way to trigger this segfault was to go to a website blocked via this method (for testing purposes, a dig query works quite well). The segfault can be reproduced reliably, and always occurs after one or a few queries towards the "blocked" domain entries.

I found a commit in the upstream dnsmasq git repo which seems to fix this issue, the fix made it into 2.87:
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=de372d6914ae20a1f9997815f258efbf3b14c39b

Would it be possible to backport this into the version used in the current LTS Ubuntu release? Thanks!

------

$ lsb_release -d
Description: Ubuntu 22.04.2 LTS
$ apt-cache policy dnsmasq
dnsmasq:
  Installed: 2.86-1.1ubuntu0.2
  Candidate: 2.86-1.1ubuntu0.2
  Version table:
 *** 2.86-1.1ubuntu0.2 500
        500 http://de.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages
        100 /var/lib/dpkg/status
     2.86-1.1ubuntu0.1 500
        500 http://de.archive.ubuntu.com/ubuntu jammy-security/universe amd64 Packages
     2.86-1.1 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

------

Excerpt from the dnsmasq logs, with debugging enabled, after I loaded fast.com:
Apr 07 13:47:41 budgie systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
Apr 07 13:47:42 budgie dnsmasq[109976]: query[type=65] fast.dradis.netflix.com from 192.168.10.82
Apr 07 13:47:42 budgie dnsmasq[109976]: config error is REFUSED (EDE: network error)
Apr 07 13:47:43 budgie dnsmasq[109976]: query[type=65] ichnaea-web.netflix.com from 192.168.10.82
Apr 07 13:47:43 budgie systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV
Apr 07 13:47:43 budgie systemd[1]: dnsmasq.service: Failed with result 'core-dump'.

Core dump is also attached.

Reproduction steps:
- 1. Install dnsmasq on Ubuntu 22.04 (or any Ubuntu release using dnsmasq 2.86)
- 1.5. Configure one or multiple DNS servers for dnsmasq
- 2. Copy netflix-nov6.conf into /etc/dnsmasq.d/
- 3. Restart/reload dnsmasq
- 3.5 Verify that dnsmasq resolves domains correctly:

root@budgie:~# dig +short -tA ubuntu.com @127.0.0.1
185.125.190.21
185.125.190.20
185.125.190.29
root@budgie:~# dig +short -tAAAA ubuntu.com @127.0.0.1
2620:2d:4000:1::28
2620:2d:4000:1::26
2620:2d:4000:1::27

- 4. Perform a type65 / HTTPS recordtype query for netflix.com towards the dnsmasq server once or twice:

root@budgie:~# dig +short -tTYPE65 netflix.com @127.0.0.1
root@budgie:~# dig +short -tTYPE65 netflix.com @127.0.0.1
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; no servers could be reached

- 5. Check logs to verify segfault:

Apr 07 14:03:28 budgie systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
Apr 07 14:03:32 budgie dnsmasq[111585]: query[type=65] netflix.com from 127.0.0.1
Apr 07 14:03:32 budgie dnsmasq[111585]: config error is REFUSED (EDE: network error)
Apr 07 14:03:33 budgie dnsmasq[111585]: query[type=65] netflix.com from 127.0.0.1
Apr 07 14:03:33 budgie systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV
Apr 07 14:03:33 budgie systemd[1]: dnsmasq.service: Failed with result 'core-dump'.

--
netflix-nov6.conf:
# Null AAAA response on these domains
server=/netflix.com/#
address=/netflix.com/::
server=/netflix.net/#
address=/netflix.net/::
server=/nflxext.com/#
address=/nflxext.com/::

[Gordon G (vista-ubuntu)]

After further testing, I can also see the crash occurs without with the `dns-no-doh.conf` config snippet loaded, even for a regular `A` record (so the TYPE65 query is also a red herring):

root@budgie:~# dig +short -tA test.netflix.net @127.0.0.1
root@budgie:~# dig +short -tA test.netflix.net @127.0.0.1
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; no servers could be reached
root@budgie:~# journalctl -fu dnsmasq
...
Apr 07 14:53:50 budgie dnsmasq[116972]: query[A] occ-0-4415-3211.1.nflxso.net from 127.0.0.1
Apr 07 14:53:50 budgie systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV
Apr 07 14:53:50 budgie systemd[1]: dnsmasq.service: Failed with result 'core-dump'.

This further makes me think the commit I linked in my initial bug report is indeed the fix for this segfault.

The reproduction steps can be narrowed down to only using the netflix-nov6.conf configuration snippet, and performing a simple A record query on the subdomain of any of the domains listed in the snippet.

Coredump attached of the segfault during this simplified repro.

[Bryce Harrington (bryce)]

Thanks for reporting the bug with steps to reproduce, and identifying a possible patch from upstream.

On a cursory glance, the upstream commit is longer than we usually want for SRU purposes, so I'm not sure it's going to qualify for SRU as is. The patch includes some refactoring changes but I'm not sure if untangling those would necessarily shorten the patch much. But should be straightforward to at least add the patched package to a PPA for you to check, and we can decide from there.

[Sergio Durigan Junior (sergiodj)]

I see that Miriam will work on this one (thanks!).

I was able to reproduce the issue (thank you Gordon for the great bug description), and confirmed that it manifests on Jammy but is fixed in Lunar. I'm trying to reproduce it on Kinetic; will update the bug with results once I have them.

[Sergio Durigan Junior (sergiodj)]

Kinetic doesn't seem to be affected.

[Miriam España Acebal (mirespace)]

Hi Gordon,

I prepared a package with the fix, as suggested by Bryce. Would you be so kind as to test it and share your results? The package is in the following PPA:

https://launchpad.net/~mirespace/+archive/ubuntu/dnsmasq-lp2015562

I could check that the SIGSEV scenario goes away with the fix (thanks, Sergio, for the help and extra pair of eyes on checking the setup for the steps to reproduce!).

A curious thing to me is that the error is not present in Kinetic, but Kinetic and Jammy share the same upstream version: 2.86-1.1. I'm taking a look at the ubuntu modifications that are different between them to see if we can narrow it down to the bits that make it possible, and maybe that would be more feasible to be SRUed to Jammy.

[Miriam España Acebal (mirespace)]

Kinetic and Jammy packages are pretty much the same:

https://paste.ubuntu.com/p/S39n5Yy9gT/

[Miriam España Acebal (mirespace)]

Hi again,

I'm working on a set of DEP-8 tests to check the matching domain functionality modified by this change that fixes the issue to make a stronger SRU submission. Also, I could cover bug LP#1677827.

I found a DEP8 proposal on Debian at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034135, and I'm using it as a starting point (to avoid the maximum diverge, in case it would be accepted in the future).

[Miriam España Acebal (mirespace)]

The DEP-8 tests will be more suitable to be submitted to the development version, so I'll split them from here.

While working on a more specific test for this instead of the ones submitted for review, Sergio discovered that the error wasn't enough reproducible with the following

netflix-nov6.conf:
# Null AAAA response on these domains
server=/netflix.com/#
address=/netflix.com/::
server=/netflix.net/#
address=/netflix.net/::
server=/nflxext.com/#
address=/nflxext.com/::

It needs another double line of server/address: with that, we always get the segmentation fault.

The bad news are that the proposed patch doesn't mitigate the error... so it would need another change introduced in upper versions. Looking for that change now.

[Miriam España Acebal (mirespace)]

Double checked we were right with the proposed patch (some misconfiguration happened in our last tests)... so proceeding further with the SRU.

[Timo Aaltonen (tjaalton)]

 man/dnsmasq.8.orig | 2582 +++++++++++++++++++++++++++++++++++++++++++++++++++++

this must be a leftover from applying the commit?

[Timo Aaltonen (tjaalton)]

An upload of dnsmasq to jammy-proposed has been rejected from the upload queue for the following reason: "cruft in the debdiff".

[Sergio Durigan Junior (sergiodj)]

On Friday, December 08 2023, Timo Aaltonen wrote:

> man/dnsmasq.8.orig | 2582
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> this must be a leftover from applying the commit?

Hm, I don't see this difference. In fact, if I look at the dnsmasq
package that's currently shipped in Jammy, man/dnsmasq.8.orig already
exists there.

--
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

[Timo Aaltonen (tjaalton)]

Hello Gordon, or anyone else affected,

Accepted dnsmasq into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/dnsmasq/2.86-1.1ubuntu0.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Christian Ehrhardt  (paelzer)]

Verifying according to the instructions - Before the update I got this as expected:

root@Jdnsmasq:~# dig A netflix.com @127.0.0.1
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> A netflix.com @127.0.0.1
;; global options: +cmd
;; no servers could be reached

Jan 02 11:13:01 Jdnsmasq systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV
Jan 02 11:13:01 Jdnsmasq systemd[1]: dnsmasq.service: Failed with result 'core-dump'.

---

Upgrade

...
Preparing to unpack .../12-dnsmasq-base_2.86-1.1ubuntu0.4_amd64.deb ...
Unpacking dnsmasq-base (2.86-1.1ubuntu0.4) over (2.86-1.1ubuntu0.3) ...
Preparing to unpack .../13-dnsmasq_2.86-1.1ubuntu0.4_all.deb ...
Unpacking dnsmasq (2.86-1.1ubuntu0.4) over (2.86-1.1ubuntu0.3) ...
...
worked without issues

---

root@Jdnsmasq:~# systemctl status dnsmasq
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2024-01-02 11:18:03 UTC; 3s ago
    Process: 4327 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, status=0/SUCCESS)
    Process: 4335 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
    Process: 4344 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
   Main PID: 4343 (dnsmasq)
      Tasks: 1 (limit: 38247)
     Memory: 588.0K
        CPU: 45ms
     CGroup: /system.slice/dnsmasq.service
             └─4343 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880409bb>

Jan 02 11:18:03 Jdnsmasq dnsmasq[4343]: using standard nameservers for netflix.com
Jan 02 11:18:03 Jdnsmasq dnsmasq[4343]: reading /etc/resolv.conf
Jan 02 11:18:03 Jdnsmasq dnsmasq[4343]: using nameserver 8.8.8.8#53
Jan 02 11:18:03 Jdnsmasq dnsmasq[4343]: ignoring nameserver 127.0.0.1 - local interface
Jan 02 11:18:03 Jdnsmasq dnsmasq[4343]: using standard nameservers for example.com
Jan 02 11:18:03 Jdnsmasq dnsmasq[4343]: using standard nameservers for nflxext.com
Jan 02 11:18:03 Jdnsmasq dnsmasq[4343]: using standard nameservers for netflix.net
Jan 02 11:18:03 Jdnsmasq dnsmasq[4343]: using standard nameservers for netflix.com
Jan 02 11:18:03 Jdnsmasq dnsmasq[4343]: read /etc/hosts - 7 addresses
Jan 02 11:18:03 Jdnsmasq systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.

---

Trying the issue trigger again:

root@Jdnsmasq:~# dig +short -tA ubuntu.com @127.0.0.1
185.125.190.29
185.125.190.20
185.125.190.21
root@Jdnsmasq:~# dig +short -tAAAA ubuntu.com @127.0.0.1
2620:2d:4000:1::27
2620:2d:4000:1::28
2620:2d:4000:1::26
root@Jdnsmasq:~# dig A netflix.com @127.0.0.1

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> A netflix.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63180
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTH...

[Robie Basak (racb)]

"Where problems could occur" says "...in [Other Info] section I included some query examples for well-known domains, so we can be more confident with this change", but I don't see these carried out as part of the SRU verification.

Admittedly they weren't documented as part of the Test Plan, but if that's the case, why weren't they? Or, if they were intended to be part of the Test Plan, then presumably these tests should be performed before we release this update?

[Christian Ehrhardt  (paelzer)]

Hey, while passing by I admit I only looked at the test plan and tried to get this moving by executing it.
Thanks for hinting at these further things to check ...

I still had the environment around

root@Jdnsmasq:~# apt-cache policy dnsmasq
dnsmasq:
  Installed: 2.86-1.1ubuntu0.4
  Candidate: 2.86-1.1ubuntu0.4

That resolved well, asking the configured dns (8.8.8.8 in my case) and returning a proper answer.

root@Jdnsmasq:~# dig +short A www.thekelleys.org.uk @127.0.0.1
thekelleys.org.uk.
85.119.82.65
root@Jdnsmasq:~# dig +short A www.thekelleys.org.uk @127.0.0.1
thekelleys.org.uk.
85.119.82.65
root@Jdnsmasq:~# dig +short A www.thekelleys.org.uk @127.0.0.1
thekelleys.org.uk.
85.119.82.65

Since the original issue was about repeating queries (in other context and situation) I ran it a few times.
The log (we still have verbose logging enabled from the first test) shows the forward resolving just as expected:
Jan 05 07:32:56 Jdnsmasq dnsmasq[255]: query[A] www.thekelleys.org.uk from 127.0.0.1
Jan 05 07:32:56 Jdnsmasq dnsmasq[255]: forwarded www.thekelleys.org.uk to 8.8.8.8
Jan 05 07:32:56 Jdnsmasq dnsmasq[255]: reply www.thekelleys.org.uk is <CNAME>
Jan 05 07:32:56 Jdnsmasq dnsmasq[255]: reply thekelleys.org.uk is 85.119.82.65

---

Now dnsmasqs version of a static entry

root@Jdnsmasq:~# echo "address=/domain/1.2.3.4" >> /etc/dnsmasq.conf
root@Jdnsmasq:~# systemctl restart dnsmasq
root@Jdnsmasq:~# dig +short A domain
1.2.3.4

---

Since I had that running over night I also see in the verbose logs all kind of expected background action and all that worked as well.
Like:
Jan 05 07:30:43 Jdnsmasq dnsmasq[255]: cached api.snapcraft.io is 185.125.188.54
Jan 05 07:30:43 Jdnsmasq dnsmasq[255]: cached api.snapcraft.io is 185.125.188.59
Jan 05 07:30:43 Jdnsmasq dnsmasq[255]: cached api.snapcraft.io is 185.125.188.58
Jan 05 07:30:43 Jdnsmasq dnsmasq[255]: cached api.snapcraft.io is 185.125.188.55
Jan 05 07:30:44 Jdnsmasq dnsmasq[255]: query[AAAA] canonical-bos01.cdn.snapcraftcontent.com from 127.0.0.1
Jan 05 07:30:44 Jdnsmasq dnsmasq[255]: forwarded canonical-bos01.cdn.snapcraftcontent.com to 8.8.8.8
Jan 05 07:30:44 Jdnsmasq dnsmasq[255]: query[A] canonical-bos01.cdn.snapcraftcontent.com from 127.0.0.1
Jan 05 07:30:44 Jdnsmasq dnsmasq[255]: forwarded canonical-bos01.cdn.snapcraftcontent.com to 8.8.8.8
Jan 05 07:30:44 Jdnsmasq dnsmasq[255]: reply canonical-bos01.cdn.snapcraftcontent.com is NODATA-IPv6
Jan 05 07:30:44 Jdnsmasq dnsmasq[255]: reply canonical-bos01.cdn.snapcraftcontent.com is 91.189.91.43
Jan 05 07:30:44 Jdnsmasq dnsmasq[255]: reply canonical-bos01.cdn.snapcraftcontent.com is 91.189.91.42
Jan 05 07:30:51 Jdnsmasq dnsmasq[255]: query[AAAA] api.snapcraft.io from 127.0.0.1
Jan 05 07:30:51 Jdnsmasq dnsmasq[255]: cached api.snapcraft.io is NODATA-IPv6
Jan 05 07:30:51 Jdnsmasq dnsmasq[255]: query[A] api.snapcraft.io from 127.0.0.1
Jan 05 07:30:51 Jdnsmasq dnsmasq[255]: forwarded api.snapcraft.io to 8.8.8.8
Jan 05 07:30:51 Jdnsmasq dnsmasq[255]: reply api.snapcraft.io is 185.125.188.58
Jan 05 07:30:51 Jdnsmasq dnsmasq[255]: reply api.snapcraft.io is 185.125.188.55
Jan 05 07:30:51 Jdnsmasq dnsmasq[255]: reply api.snapcraft.io is 185.125.188.54
J...

[Launchpad Janitor (janitor)]

This bug was fixed in the package dnsmasq - 2.86-1.1ubuntu0.4

---------------
dnsmasq (2.86-1.1ubuntu0.4) jammy; urgency=medium

  * src/dnsmasq.h, src/domain-match.c: Fix confusion when using resolvconf
    servers (combining server|address for a domain), resulting in the struct
    server datastructure for server=/domain/# getting passed to
    forward_query(), rapidly followed by a SEGV. This fix makes
    server=/domain/# a fully fledged member of the priority list.
    The code added here is a cherry pick released in upstream version
    2.87, originating at
    https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=de372d69
    (LP: #2015562)

 -- Miriam España Acebal <email address hidden> Thu, 20 Apr 2023 11:00:27 +0200

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for dnsmasq has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.