Mobile phone hotspot unusable due to systemd-resolved not liking the DNS

Bug #1920781 reported by Sergio Callegari on 2021-03-22

This bug report was marked for expiration 1 days ago. (find out why)

8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Undecided
Unassigned
Focal
Undecided
Unassigned
Groovy
Undecided
Unassigned

Bug Description

Seen in 20.04.

Trying to connect to the internet using the mobile phone hotspot is impossible due to systemd-resolved not resolving and reporting things like:

resolve call failed: DNSSEC validation failed: incompatible-server

and

systemd-resolved[81699]: DNSSEC validation failed for question d.3.1.b.d.e.1.e.1.6.9.e.7.8.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN PTR: no-signature
DNSSEC validation failed for question b.d.e.1.e.1.6.9.e.7.8.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa IN DS: no-signature

etc etc.

Name resolution works just fine from the mobile phone.

Funny thing is that the issue persists if DNSSEC is disabled via resolvectl for the interface:

Link 3 (wlan0)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: opportunistic
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 192.168.43.1
         DNS Servers: 192.168.43.1

Systemd-resolved won't accept the issue to be reported upstream saying that a too old version of systemd is being used.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: systemd 245.4-4ubuntu3.5
ProcVersionSignature: Ubuntu 5.8.0-45.51~20.04.1-generic 5.8.18
Uname: Linux 5.8.0-45-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Mon Mar 22 15:39:23 2021
EcryptfsInUse: Yes
InstallationDate: Installed on 2020-02-16 (400 days ago)
InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
MachineType: SCHENKER SCHENKER_SLIM14_SSL14L19
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-45-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 (303 days ago)
dmi.bios.date: 10/02/2019
dmi.bios.release: 7.4
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.ec.firmware.release: 7.2
dmi.modalias: dmi:bvnINSYDECorp.:bvr1.07.04RTR1:bd10/02/2019:br7.4:efr7.2: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
modified.conffile..etc.systemd.resolved.conf: [modified]
mtime.conffile..etc.systemd.resolved.conf: 2021-02-10T11:20:21.512139
mtime.conffile..etc.systemd.sleep.conf: 2020-08-13T07:55:23.365733

Revision history for this message
Sergio Callegari (callegar) wrote :
Revision history for this message
Dan Streetman (ddstreet) wrote :

Have you tried disabing resolved DNSSEC completely (not only for one interface) to see if your mobile hotspot works then?

Changed in systemd (Ubuntu):
status: New → Incomplete
Changed in systemd (Ubuntu Focal):
status: New → Incomplete
Changed in systemd (Ubuntu Groovy):
status: New → Incomplete
Revision history for this message
Sergio Callegari (callegar) wrote :

Happened again today.

How do you disable dnssec completely in systemd-resolved? resolvectl does not seem to have an option for that. Is editing resolved.conf and restarting resolved the only way?

In any case I could not try, I was too much on a hurry and reconfiguring network manager to use google dns for the connection was quicker.

Still: why should one need to disable dnssec globally when there is a per connection setting?

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

@callegar

It would be nice to see the full resolvectl status.

Because depending on which things you have configured it might be expected to have DNSSEC validation working, and the request is routed to multiple interfaces, and none of them return results or the results fail to validate.

Also note that strict DNSSEC is off by default.... did you turn it on in the first place?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers