Debian 10/9/8 DNS configuration bug
This bug was originally filed in Launchpad as LP: #1850310
Launchpad details
affected_projects = [] assignee = None assignee_name = None date_closed = None date_created = 2019-10-29T12:45:21.422366+00:00 date_fix_committed = None date_fix_released = None id = 1850310 importance = medium is_complete = False lp_url = https://bugs.launchpad.net/cloud-init/+bug/1850310 milestone = None owner = dshemin owner_name = Dmitry Shemin private = False status = triaged submitter = dshemin submitter_name = Dmitry Shemin tags = [] duplicates = []
Launchpad user Dmitry Shemin(dshemin) wrote on 2019-10-29T12:45:21.422366+00:00
I use cloud-init with NoCloud data source for configuring my VM's and got strange bug with DNS configuration on official Debian images like https://cdimage.debian.org/cdimage/openstack/current-10/debian-10-openstack-amd64.qcow2.
My network config:
version: 2
ethernets:
eth0:
set-name: eth0
match:
macaddress: <MAC address>
addresses: [ <IP address> ]
gateway4: <GATEWAY ADDRESS>
nameservers:
addresses: [8.8.8.8,8.8.4.4]
After creating new VM I got next configuration in /etc/network/interfaces.d/50-cloud-init.cfg which is seems ok:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.52.240.11/16
dns-nameservers 8.8.8.8 8.8.4.4
gateway 10.52.1.1
But /etc/resolv.conf contains:
nameserver 127.0.0.1
Which leads to the fact that I can’t resolve any domain name, for example:
# ping google.com
ping: google.com: Temporary failure in name resolution
Launchpad user Dmitry Shemin(dshemin) wrote on 2019-10-29T12:45:21.422366+00:00
Launchpad attachments: cloud-init.tar.gz
Launchpad user Ryan Harper(raharper) wrote on 2019-10-30T15:34:35.067799+00:00
Thanks for filing the bug.
Cloud-init itself does not render /etc/resolv.conf on Ubuntu/Debian; In Ubuntu, the resolvconf package is installed which handles maintain /etc/resolv.conf.
Looking at:
https://cdimage.debian.org/cdimage/openstack/current-10/debian-10-openstack-amd64-packages.list
resolvconf package is not present, hence the bug. I would suggest that the images include this package.
That said, cloud-init could detect if resolvconf is not present and render resolv.conf directly.
Launchpad user Adam Conrad(adconrad) wrote on 2019-10-30T15:53:08.950232+00:00
In Ubuntu, the resolvconf package is installed which handles maintain /etc/resolv.conf.
This hasn't been true for years. That said, it's still handled "magically" today, just that now we do it with systemd-resolved.
Launchpad user Ryan Harper(raharper) wrote on 2019-10-30T16:08:06.595966+00:00
@Adam,
In the context of Ubuntu images which still use ifupdown by default (Xenial); they also include resolvconf which is what manages resolv.conf.
As you note, newer Ubuntu uses systemd-resolved as replacement for resolvconf; cloud-init on Ubuntu does not directly render contents into /etc/resolv.conf for these reasons.
Launchpad user Dmitry Shemin(dshemin) wrote on 2019-10-30T18:03:52.568215+00:00
The documentation says that the 'resolvconf' package is optional for Debian. https://wiki.debian.org/NetworkConfiguration#Defining_the_.28DNS.29_Nameservers So temporarily I used 'systemd-resolved' for DNS configuration by adding this line to my user data:
runcmd:
- |
cat << EOL > /etc/systemd/resolved.conf
[Resolve]
DNS=8.8.8.8
EOL
- |
cat << EOL > /etc/resolv.conf
nameserver 127.0.0.53
EOL
- systemctl enable systemd-resolved
- systemctl start systemd-resolved
But I think it's worth doing something about it.
Launchpad user Brian King(inflatador) wrote on 2020-05-29T17:17:00.830918+00:00
I'm affected as well. Running an Openstack cloud with the config-drive and static IP information. The DNS servers are in the network-data.json file, but cloud-init on Debian 10 does not set the DNS servers unless the resolvconf package is present.
Launchpad user TJ(zimmertr) wrote on 2020-08-26T21:52:27.905610+00:00
I'm affected as well. Got around this like so:
write_files:
- path: /etc/resolvconf/resolv.conf.d/base content: nameserver 192.168.1.100 runcmd:
- [ systemctl, restart, resolvconf ]
This is still an issue on Debian 12.