[Bug 1774632] Re: The symbolic link /etc/resolv.conf points to the wrong file by default

[Guy Rouillier]

Lukas Märdian (slyon): "NetworkManager should automatically detect sd-
resolved and integrate nicely"

Thank you for this guidance, Lukas.  I had disabled NetworkManager on
this system because it wasn't configuring my network connections as I
needed them.  I had moved my home LAN onto a separate subnet -
192.168.2.* - as my provider is Verizon FIOS, and it controls
192.168.1.*.  Even though I put specific manual settings into
NetworkManager to tell it to use 192.168.2.*, it was still picking DNS
servers on 192.168.1.*.

But your post encouraged me to try again (2 years later) and this time I
got NetworkManager working with Manual configuration.  So, I now have
everything configured as default with stub-resolv.conf and
NetworkManager enabled, and it's all working correctly.  The only place
I have DNS servers specified is in NetworkManager, separately for each
interface ("Wired connection 1" and "docker0").  I'm providing these
details in case someone finds this report via search.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1774632

Title:
  The symbolic link /etc/resolv.conf points to the wrong file by default

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  When using nslookup for local machine names, the local DNS was being
  ignored (not queried) and none of the local machines could be found.

  After much research and digging, it was discovered that the cause was
  the incorrect symbolic link /etc/resolv.conf file.

  The default install caused systemd-resolve to configure the link to point to the stub file:
  /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

  Reomving that link and pointing it to the correct file solved the DNS lookup issue. The correct link looks like this:
  /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

  
  Steps used to test the bug before fixing the link is to perform an nslookup on a local (non FQDN) machine that is in your local DNS (my router is my DNS server for this case) Here is an example of the incorrect output:

  $ nslookup web1

  Server:     127.0.0.53
  Address:    127.0.0.53#53

  ** server can't find web1: SERVFAIL

  
  Switching the symbolic link solves the problem. Here is my solution:

  $ sudo rm -f /etc/resolv.conf
  $ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

  
  After switching the symbolic link, the nslookup functions properly.

  $ nslookup web1

  Server:     192.168.1.1
  Address:    192.168.1.1#53

  Name:   web1
  Address: 192.168.1.107

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jun  1 05:28:41 2018
  InstallationDate: Installed on 2018-01-20 (131 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
  MachineType: Dell Inc. Inspiron 5755
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-22-generic root=UUID=7fe151d3-4033-4903-b356-341d9f16e124 ro acpi=force
  SourcePackage: systemd
  UpgradeStatus: Upgraded to bionic on 2018-04-28 (33 days ago)
  dmi.bios.date: 08/27/2015
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A08
  dmi.board.name: 0VY15F
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: A08
  dmi.modalias: dmi:bvnDellInc.:bvrA08:bd08/27/2015:svnDellInc.:pnInspiron5755:pvrA08:rvnDellInc.:rn0VY15F:rvrA00:cvnDellInc.:ct8:cvrA08:
  dmi.product.name: Inspiron 5755
  dmi.product.version: A08
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1774632/+subscriptions