Finished my investigation. Guess it is not a bug after all, rather — I
would say — a matter of extremely dispersed documentation plus very
unfriendly behavior from the ISP.
The situation is that even if you put mdns_minimal in front of other
entries in hosts in nsswitch, mdns /is not queried/ if the DNS declares
SOA for the "local" domain. Mine does. This is the reason why I was
getting the impression of systemd-resolved passing queries to DNS even
when it should not have. It was actually nss_mdns to let it do so. The
fact that for some time my isp has directed all dns queries to its own
nameserver even when another one was selected did not help in verifying
the behavior with a dns not declaring SOA for local.
Yet, this aspect of the linux mdns implementation should be documented
with much better emphasis, or even better, there should be a way to make
mdns_minimal report/log what it is doing. Currently, you find mention of
the mdns "handover" to dns for local only looking at the very end of
/usr/share/doc/libnss-mdns/README.md.gz where the heuristics is
explained.
Because heuristics /can go wrong/, the item should IMHO be given much
better emphasis. For instance, I suggest that ubuntu ships with a man
page for nss_mdns and nss_mdns_minimal.
** Changed in: systemd (Ubuntu)
Status: New => Invalid
** Package changed: systemd (Ubuntu) => nss-mdns (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1883793
Title:
systemd-resolved leaks mDNS queries to DNS
Status in nss-mdns package in Ubuntu:
Invalid
Bug description:
On a freshly installed ubuntu focal machine, access to local machines
advertised via mDNS is now broken. This is a regression wrt eoan where
it used to work.
Trying to ping something like <host>.local invariably results in
pinging 40.68.249.35 because systemd-resolved passes the query to the
DNS even if .local is reserved for multicast DNS and for some reasons
<anything>.local seems to resolve to 40.68.249.35. This happens even
if the avahi daemon is up and running.
Stopping systemd-resolved makes the mDNS resolution work as expected.
Not only this breaks standard workflows, but it also means that anyone
pretending to be 40.68.249.35 on the network could probably
impersonate any local host.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: systemd 245.4-4ubuntu3.1
ProcVersionSignature: Ubuntu 5.4.0-37.41-generic 5.4.41
Uname: Linux 5.4.0-37-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.2
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Tue Jun 16 23:43:22 2020
EcryptfsInUse: Yes
InstallationDate: Installed on 2020-02-16 (121 days ago)
InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
MachineType: SCHENKER SCHENKER_SLIM14_SSL14L19
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-37-generic
root=/dev/mapper/VG_NVMe-root ro quiet splash vt.handoff=7
SourcePackage: systemd
SystemdDelta:
[EXTENDED] /usr/lib/systemd/system/rc-local.service →
/usr/lib/systemd/system/rc-local.service.d/debian.conf
[EXTENDED] /usr/lib/systemd/system/user@.service →
/usr/lib/systemd/system/user@.service.d/timeout.conf
2 overridden configuration files found.
UpgradeStatus: Upgraded to focal on 2020-05-23 (24 days ago)
dmi.bios.date: 10/02/2019
dmi.bios.vendor: INSYDE Corp.
dmi.bios.version: 1.07.04RTR1
dmi.board.asset.tag: Tag 12345
dmi.board.name: N141CU
dmi.board.vendor: SCHENKER
dmi.board.version: Not Applicable
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Notebook
dmi.chassis.version: N/A
dmi.modalias:
dmi:bvnINSYDECorp.:bvr1.07.04RTR1:bd10/02/2019:svnSCHENKER:pnSCHENKER_SLIM14_SSL14L19:pvrNotApplicable:rvnSCHENKER:rnN141CU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A:
dmi.product.family: Not Applicable
dmi.product.name: SCHENKER_SLIM14_SSL14L19
dmi.product.sku: Not Applicable
dmi.product.version: Not Applicable
dmi.sys.vendor: SCHENKER
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nss-mdns/+bug/1883793/+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
