systemd-resolved does not allow you to connect using subdomains using search domains which are in /etc/resolv.conf

Bug #1636375 reported by Sean Crosby
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
systemd
Fix Released
Unknown
systemd (Ubuntu)
Won't Fix
Medium
Unassigned

Bug Description

systemd-resolved doesn't seem to allow you to use subdomains when connecting to hosts in domains that are part of /etc/resolv.conf

e.g.

16:01|scrosby@stewie: ~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver W.X.Y.Z
nameserver A.B.C.D
nameserver 127.0.0.53
search blah1 blah2 blah3 blah4 blah5

with systemd-resolved running

16:05|scrosby@stewie: ~$ ping foo.bar
ping: foo.bar: Name or service not known

without systemd-resolved running

16:05|scrosby@stewie: ~$ ping foo.bar
PING foo.bar.blah3 (E.F.G.H) 56(84) bytes of data.
64 bytes from foo.bar.blah3 (E.F.G.H): icmp_seq=1 ttl=52 time=1.68 ms
64 bytes from foo.bar.blah3 (E.F.G.H): icmp_seq=2 ttl=52 time=1.09 ms

It does seem like looking up hosts without a . in their name does use the search domains in resolv.conf though

16:05|scrosby@stewie: ~$ ping foo2
PING foo2.blah3 (I.J.K.L) 56(84) bytes of data.
64 bytes from foo2.blah3 (I.J.K.L): icmp_seq=1 ttl=52 time=1.34 ms
64 bytes from foo2.blah3 (I.J.K.L): icmp_seq=2 ttl=52 time=1.29 ms

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: systemd 231-9git1
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
Date: Tue Oct 25 16:13:38 2016
InstallationDate: Installed on 2016-06-08 (139 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
MachineType: Dell Inc. OptiPlex 990
ProcEnviron:
 LANGUAGE=en_AU:en
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-26-generic root=UUID=67011022-ac91-464f-ab8f-c97c6cb5a439 ro quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: Upgraded to yakkety on 2016-10-24 (0 days ago)
dmi.bios.date: 08/26/2015
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A19
dmi.board.asset.tag: UOM97917
dmi.board.name: 0VNP2H
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.asset.tag: UOM97917
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA19:bd08/26/2015:svnDellInc.:pnOptiPlex990:pvr01:rvnDellInc.:rn0VNP2H:rvrA00:cvnDellInc.:ct3:cvr:
dmi.product.name: OptiPlex 990
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

Revision history for this message
Sean Crosby (richardnixonshead) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu):
status: New → Confirmed
Revision history for this message
Benjamin Drung (bdrung) wrote :

I am seeing the exact same behavior on my Ubuntu 16.10 (yakkety) machine.

Revision history for this message
Benjamin Drung (bdrung) wrote :

The workaround described above solved the issue:

$ systemctl disable systemd-resolved.service

Martin Pitt (pitti)
tags: added: resolved
Revision history for this message
Michał Sawicz (saviq) wrote :

Same issue here, my dhcp sends "bar.name" and "name" as search domains, systemd-resolve --status reports them correctly:

Link 1 (enxxxxxxxxxxxx)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: no
         DNS Servers: 10.1.0.1
          DNS Domain: bar.name
                      name

But:

 ping foo
PING foo.bar.name (10.1.0.2) 56(84) bytes of data.
[...]

 ping foo.bar
ping: foo.bar: Name or service not known

 ping foo.bar.name
PING foo.bar.name (10.1.0.2) 56(84) bytes of data.
[...]

Martin Pitt (pitti)
Changed in systemd (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Changed in systemd:
status: Unknown → New
Revision history for this message
Martin Pitt (pitti) wrote :

I'm afraid this is by design and wontfix, see https://github.com/systemd/systemd/issues/4821#issuecomment-264995354 for details. This isn't something which we reasonably can/should change downstream, so I suggest to direct discussions to the upstream bug. Thanks!

Changed in systemd (Ubuntu):
status: Triaged → Won't Fix
Changed in systemd:
status: New → Fix Released
Revision history for this message
Vincent Gerris (vgerris) wrote :

Again Martin, this is NOT a solution.
A fix would be something that avoids the problem from emerging in the first place.
If stopping systemd-resolvd is a solution, that let's make sure it is NOT enabled nor installed in 17.04 by default and let's FIX it to be the same in 16.10 if possible.

Thank you

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.