Bug 1312778 - [NetworkManager] failure of DNS name resolution
Summary: [NetworkManager] failure of DNS name resolution
Status: CLOSED DUPLICATE of bug 1313085
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 24
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-02-29 09:37 UTC by Joachim Frieben
Modified: 2016-03-10 20:04 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-03-10 20:03:28 UTC
Type: Bug

Attachments (Terms of Use)

Description Joachim Frieben 2016-02-29 09:37:02 UTC
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):

How reproducible:

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 10:40:52 UTC
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 13:16:26 UTC
-- Fedora 23 ----------------------------------------------------------------

# Generated by NetworkManager

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':
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':
connected (site only)  limited       enabled  enabled  enabled  enabled

Comment 3 Beniamino Galvani 2016-02-29 13:58:46 UTC
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 14:37:46 UTC
Reassigning the bug to systemd.

Comment 5 Zbigniew Jędrzejewski-Szmek 2016-02-29 14:52:02 UTC
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 07:42:02 UTC
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 20:03:28 UTC

*** 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.