Bug 1312778 - [NetworkManager] failure of DNS name resolution
[NetworkManager] failure of DNS name resolution
Status: CLOSED DUPLICATE of bug 1313085
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
24
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-29 04:37 EST by Joachim Frieben
Modified: 2016-03-10 15:04 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-10 15:03:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joachim Frieben 2016-02-29 04:37:02 EST
Description of problem:
For current Fedora 24, DNS name resolution does not work. It is possible to contact remote nodes by IP address but not by name. In the case of a wireless connection, it is possible to log in to the access point and to verify that the Internet connection is actually established.

Release number of selected component (if applicable):
NetworkManager-1.2.0-0.6.beta1.fc24

How reproducible:
Always

Steps to Reproduce:
1. Boot latest live media Fedora-Live-Workstation-x86_64-Rawhide-20160225.0.iso.
2. Create network connection.

Actual results:
Name resolution by DNS does not work. The NetworkManager applet shows a question mark but all connection data looks correct. Remote nodes are accessible via IP address.

Expected results:
Name resolution by DNS works as expected.

Additional info:
- Current Fedora 23 works correctly under identical conditions.
- A wireless network install is possible using Fedora-Workstation-boot-x86_64-24-20160225.n.0.iso even though the network functionality of the corresponding live media Fedora-Live-Workstation-x86_64-Rawhide-20160225.0.iso is broken.
Comment 1 Beniamino Galvani 2016-02-29 05:40:52 EST
Can you please paste the content of /etc/resolv.conf? If there's a nameserver in there, are you able to ping it?
And what's the output of "nmcli c; nmcli g"? Thanks.
Comment 2 Joachim Frieben 2016-02-29 08:16:26 EST
-- Fedora 23 ----------------------------------------------------------------

/etc/resolv.conf:
# Generated by NetworkManager
nameserver 192.168.2.1

Output of 'nmcli c':
NAME        UUID                                  TYPE             DEVICE
ThisVPN     8be1e252-c920-4879-9204-701c09754ee5  vpn              --
enp0s25     51915f63-7819-4924-a37c-55be510840b9  802-3-ethernet   --     
ThisWifi    9b04b922-a70b-49ab-9d4a-fdc0200cfd8d  802-11-wireless  wlp3s0 
virbr0-nic  e70f8f72-ec66-4462-a7bf-d7955843e3db  generic          virbr0-nic
virbr0      1930cfce-d1f0-4e20-acc4-a08862a98b33  bridge           virbr0

Output of 'nmcli g':
STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN 
connected  full          enabled  enabled  enabled  enabled


-- Fedora 24 ----------------------------------------------------------------

/etc/resolv.conf is a symbolic link to a non-existing file resolv.conf in some systemd-related directory

Output of 'nmcli c':
NAME        UUID                                  TYPE             DEVICE 
ThisWifi    7917cfb6-7497-45f7-a01d-ddbf44d2b6cf  802-11-wireless  wlp3s0
Wired Connection 1  0ce34b8d-9861-4cfe-b878-89e7014a41cc  802-3-ethernet   --

Output of 'nmcli g':
STATE                  CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN 
connected (site only)  limited       enabled  enabled  enabled  enabled
Comment 3 Beniamino Galvani 2016-02-29 08:58:46 EST
I tried to upgrade to systemd-229-3 on rawhide, remove
/etc/resolv.conf and reboot. Now I'm in the same situation:

root@rawhide ~ # ll /etc/resolv.conf
lrwxrwxrwx. 1 root root 34 Feb 29 14:45 /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf

root@rawhide ~ # ll /run/systemd/resolve/resolv.conf
ls: cannot access /run/systemd/resolve/resolv.conf: No such file or directory

root@rawhide ~ # systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-resolved.service(8)

NetworkManager doesn't touch resolv.conf when it's a link owned by
another daemon and someone (systemd-networkd ?) created the link but
is not managing the file.

I'm not sure why the link is created on a default installation.
Comment 4 Beniamino Galvani 2016-02-29 09:37:46 EST
Reassigning the bug to systemd.
Comment 5 Zbigniew Jędrzejewski-Szmek 2016-02-29 09:52:02 EST
The link is created by systemd-tmpfiles if it doesn't exist. If it should point at something else, somebody has to create it.
Comment 6 Joachim Frieben 2016-03-02 02:42:02 EST
It seems that the stub link created (prematurely (?)) by systemd prevents NetworkManager from creating the proper file /etc/resolv.conf. After removing the broken symbolic link /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf and turning the network device off and on again, the correct symbolic link /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf is created, and name resolution works as expected.
Comment 7 Adam Williamson 2016-03-10 15:03:28 EST

*** This bug has been marked as a duplicate of bug 1313085 ***

Note You need to log in before you can comment on or make changes to this bug.