[systemd-devel] Bug in older resolved breaks mDNS: help needed to identify commit that fixed it for backporting

Sergio Callegari sergio.callegari at gmail.com
Fri Nov 12 11:15:41 UTC 2021


Hi,

the systemd version distributed with ubuntu focal (245.4) has a bug in 
systemd-resolved that ends up breaking local name resolution via mDNS.  
 From tests run with manjaro that uses a much more recent version of 
systemd I have reasons to believe that the issue may already be fixed in 
systemd. Unfortunately, there seems to be little interest in the distro 
about looking into the issue and I understand that there is no easy way 
to upgrade just systemd-resolved to a newer version on the distro. Hence 
I would like to see if there is a commit that is easy enough to backport 
over the ubuntu focal sources and I am seeking help on that. My hope is 
that the memory of those on this mailing list about what has been 
touched in systemd-resolved after version 245.4 can help restricting 
only to sensible commit candidates.

The bug scenario is the following.

Ubuntu ships with nsswitch.conf configured to include a line

hosts:          files mdns4_minimal [NOTFOUND=return] dns

This means that when you need to access an host on .local, the query 
goes first through mdns4.  However, the nss version of the mnds client 
before anything else queries unicast DNS to see if it responds to SOA 
queries for the top level local. In case it does, it assumes that in the 
LAN local is under the control of unicast DNS and it gives up.

The problem is that the ubuntu focal version of systemd-resolved replies 
to SOA queries about local when it should not.  For instance you get 
things like:

host -t SOA local
local has SOA record local. nobody.invalid. 1 3600 1200 604800 10800

Specifically this happens when (the 245.4 version of) systemd-resolved 
accesses some other specific DNS servers such as knot-resolver that 
deliver an authority section:

dig SOA local. @192.168.10.103

; <<>> DiG 9.16.1-Ubuntu <<>> SOA local. @192.168.10.103
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked 
to DNS
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55699
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;local.                         IN      SOA

;; AUTHORITY SECTION:
local.                  10800   IN      SOA     local. nobody.invalid. 1 
3600 1200 604800 10800

;; ADDITIONAL SECTION:
explanation.invalid.    10800   IN      TXT     "Blocking is mandated by 
standards, see references on 
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml"

;; Query time: 4 msec
;; SERVER: 192.168.10.103#53(192.168.10.103)
;; WHEN: Fri Nov 12 08:15:31 CET 2021
;; MSG SIZE  rcvd: 246

As already mentioned, recent versions of systemd-resolved do not seem to 
turn that authority section into a SOA reply.  So I am trying to 
understand when and how that was fixed.

Thanks in advance and best regards,

Sergio Callegari


||

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20211112/0a84eacc/attachment-0001.htm>


More information about the systemd-devel mailing list