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 Jan 05 07:30:51 Jdnsmasq dnsmasq[255]: reply api.snapcraft.io is 185.125.188.59 ... Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply archive.ubuntu.com is 185.125.190.39 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply archive.ubuntu.com is 91.189.91.81 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply archive.ubuntu.com is 91.189.91.83 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply archive.ubuntu.com is 2620:2d:4000:1::16 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply archive.ubuntu.com is 2620:2d:4002:1::103 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply archive.ubuntu.com is 2620:2d:4002:1::102 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply archive.ubuntu.com is 2620:2d:4000:1::19 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply archive.ubuntu.com is 2620:2d:4002:1::101 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 185.125.190.36 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 91.189.91.81 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 91.189.91.83 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 91.189.91.82 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 185.125.190.39 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 2620:2d:4000:1::16 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 2620:2d:4002:1::101 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 2620:2d:4002:1::103 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 2620:2d:4000:1::19 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply security.ubuntu.com is 2620:2d:4002:1::102 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: query[SRV] _https._tcp.motd.ubuntu.com from 127.0.0.1 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: forwarded _https._tcp.motd.ubuntu.com to 8.8.8.8 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply _https._tcp.motd.ubuntu.com is NXDOMAIN Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: query[A] motd.ubuntu.com from 127.0.0.1 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: forwarded motd.ubuntu.com to 8.8.8.8 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: query[AAAA] motd.ubuntu.com from 127.0.0.1 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: forwarded motd.ubuntu.com to 8.8.8.8 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 54.171.230.55 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 34.254.182.186 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 54.217.10.153 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 34.243.160.129 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 54.247.62.1 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 2a05:d018:91c:3200:5e0d:21a9:26ca:90b5 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 2a05:d018:91c:3200:c8f:1a06:a2dd:450f Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 2a05:d018:91c:3200:2846:99fb:81b6:1e11 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 2a05:d018:91c:3200:d8b6:37bc:63f9:703c Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply motd.ubuntu.com is 2a05:d018:91c:3200:c887:2f22:290f:a7c Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: query[SRV] _https._tcp.esm.ubuntu.com from 127.0.0.1 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: forwarded _https._tcp.esm.ubuntu.com to 8.8.8.8 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply _https._tcp.esm.ubuntu.com is NXDOMAIN Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: query[A] esm.ubuntu.com from 127.0.0.1 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: forwarded esm.ubuntu.com to 8.8.8.8 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: query[AAAA] esm.ubuntu.com from 127.0.0.1 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: forwarded esm.ubuntu.com to 8.8.8.8 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 185.125.190.23 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 91.189.91.47 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 91.189.91.46 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 185.125.190.24 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 185.125.190.75 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 2001:67c:1562::21 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 2620:2d:4000:1::30 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 2620:2d:4000:1::2f Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 2001:67c:1562::22 Jan 05 07:38:29 Jdnsmasq dnsmasq[765]: reply esm.ubuntu.com is 2620:2d:4000:1::2e And overall the systems network functions (currently going through dnsmasq for name resolution) seem happy. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/2015562 Title: [SRU] Segfault in dnsmasq when using certain static domain entries + DoH (bugfix possibly exists upstream) Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Jammy: Fix Committed Bug description: [ 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/:: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2015562/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
