Bug 85555 - systemd-resolve daemon creates invalid resolv.conf
Summary: systemd-resolve daemon creates invalid resolv.conf
Status: RESOLVED DUPLICATE of bug 85397
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL: https://gist.github.com/xorpaul/764fd...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-28 13:10 UTC by Andreas Paul
Modified: 2014-12-09 00:34 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Andreas Paul 2014-10-28 13:10:03 UTC
My CoreOS VM is supposed to work with DHCP, but creates an invalid resolv.conf and does not send its hostname to the DHCP server, which prevents the DNS resolution of the VM's FQDN from working.

```
# systemctl --version
systemd 215
-PAM -AUDIT -SELINUX +IMA -SYSVINIT +LIBCRYPTSETUP -GCRYPT -ACL -XZ +SECCOMP -APPARMOR
```
```
# cat /etc/lsb-release 
DISTRIB_ID=CoreOS
DISTRIB_RELEASE=444.5.0
DISTRIB_CODENAME="Red Dog"
DISTRIB_DESCRIPTION="CoreOS 444.5.0"
```
Hostname from the /var/lib/coreos-install/user_data works, but no domain is available:

```
# hostname
vm-coreos
# hostname -f
hostname: Unknown host
```

The FQDN of this VM should be vm-cores.test.lan, but the systemd-resolved adds all *search* domains to the actual domain and doesn't add any search domains at all:

```
# cat /etc/resolv.conf 
# This file is managed by systemd-resolved(8). Do not edit.
#
# Third party programs must not access this file directly, but
# only through the symlink at /etc/resolv.conf. To manage
# resolv.conf(5) in a different way, replace the symlink by a
# static file or a different symlink.

domain test.lan foo.lan bar.domain kamenzu.local 
nameserver 1.2.3.4
nameserver 1.2.3.5
```
```
# journalctl -l | awk 'BEGIN{IGNORECASE=1} /dhcp/ || /network/'
Oct 28 11:21:31 localhost systemd[1]: Starting Network Time Service...
Oct 28 11:21:31 localhost systemd[1]: Started Network Time Service.
Oct 28 11:21:31 localhost systemd[1]: Starting Network Service...
Oct 28 11:21:32 localhost systemd-networkd[480]: lo              : gained carrier
Oct 28 11:21:32 localhost systemd[1]: Started Network Service.
Oct 28 11:21:32 localhost systemd[1]: Starting Network.
Oct 28 11:21:32 localhost systemd[1]: Reached target Network.
Oct 28 11:21:32 localhost systemd[1]: Starting Network Name Resolution...
Oct 28 11:21:32 localhost systemd-networkd[480]: eth0            : link configured
Oct 28 11:21:32 localhost systemd-networkd[480]: lo              : link configured
Oct 28 11:21:32 localhost systemd-networkd[480]: eth0            : gained carrier
Oct 28 11:21:32 localhost systemd[1]: Started Network Name Resolution.
Oct 28 11:21:32 localhost systemd-networkd[480]: eth0            : DHCPv4 address 1.9.3.3/22 via 1.2.3.1
Oct 28 11:21:32 localhost systemd-networkd[480]: eth0            : link configured
Oct 28 11:21:33 vm-andpaul-coreos coreos-cloudinit[460]: 2014/10/28 11:21:33 Wrote file /etc/systemd/network/20-dhcp.network to filesystem
Oct 28 11:21:34 vm-andpaul-coreos docker[687]: [937208fd] +job init_networkdriver()
Oct 28 11:21:34 vm-andpaul-coreos docker[687]: [937208fd.init_networkdriver()] creating new bridge for docker0
Oct 28 11:21:34 vm-andpaul-coreos systemd-networkd[480]: docker0         : link configured
Oct 28 11:21:34 vm-andpaul-coreos systemd-networkd[480]: docker0         : gained carrier
Oct 28 11:21:34 vm-andpaul-coreos systemd-networkd[480]: docker0         : lost carrier
Oct 28 11:21:34 vm-andpaul-coreos docker[687]: [937208fd.init_networkdriver()] getting iface addr
Oct 28 11:21:34 vm-andpaul-coreos docker[687]: [937208fd] -job init_networkdriver() = OK (0)
Oct 28 11:35:45 vm-andpaul-coreos update_engine[467]: [1028/113545:ERROR:omaha_request_action.cc(629)] Omaha request network transfer failed.
```

If I use dhcpd to get a new IP from the DHCP server:

```
# dhcpcd eth0
dhcpcd[853]: version 6.2.0 starting
dhcpcd[853]: DUID 00:01:00:01:1b:e2:3f:d9:00:1a:4a:94:32:ba
dhcpcd[853]: eth0: IAID 4a:94:32:ba
dhcpcd[853]: eth0: soliciting an IPv6 router
dhcpcd[853]: eth0: soliciting a DHCP lease
dhcpcd[853]: eth0: offered 1.9.3.8 from 172.19.64.36
dhcpcd[853]: eth0: leased 1.9.3.8 for 3600 seconds
dhcpcd[853]: eth0: adding route to 1.9.3.0/22
dhcpcd[853]: eth0: adding default route via 1.9.3.1
/lib/dhcpcd/dhcpcd-run-hooks: line 122: /etc/ntp.conf: Read-only file system
dhcpcd[853]: forked to background, child pid 920
```

I get a correct and valid resolv.conf:
```
# cat /etc/resolv.conf 
# Generated by dhcpcd from eth0
# /etc/resolv.conf.head can replace this line
domain test.lan
search foo.lan bar.domain kamenzu.local
nameserver 1.2.3.4
nameserver 1.2.3.5
# /etc/resolv.conf.tail can replace this line
```

and more importantly the FQDN can be resolved from the outside:
```
host vm-coreos.test.lan
vm-coreos.test.lan has address 1.9.3.8
```
hostname -f still does not work:

```
# hostname -f
hostname: Unknown host
```

Added both lease files:
correct one from dhcpd:
```
# cat /run/dhcpcd/resolv.conf/eth0 
# Generated by dhcpcd from eth0
domain test.lan
search foo.lan bar.domain kamenzu.local
nameserver 172.19.254.1
nameserver 172.19.255.1
```
invalid domain name from systemd:
```
# cat /run/systemd/netif/leases/2 
# This is private data. Do not parse.
ADDRESS=1.9.3.3
NETMASK=255.255.252.0
ROUTER=1.9.3.1
SERVER_ADDRESS=1.2.3.1
NEXT_SERVER=1.2.3.7
DNS=1.2.3.4 1.2.3.5
NTP=1.2.7.4 1.2.7.5
DOMAINNAME=test.lan foo.lan bar.domain kamenzu.local
```
Comment 1 Lennart Poettering 2014-12-09 00:34:39 UTC

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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.