Score:0

Ubuntu

Duplicate DNS entries after updating to 22.04

DrLime2k10

3/30/24, 11:12 AM

My server has two network interfaces configured with DHCP and after updating from Ubuntu 20.04 5.4.0-144-generic to 22.04 5.15.0-67-generic, this results in /var/run/systemd/resolve/resolv.conf containing duplicate DNS entries.

My /etc/netplan used to look like,

$ cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    eno1:
      dhcp4: true
    eno2:
      dhcp4: true
  version: 2

But after updating this now results in something like:

$ cat /var/run/systemd/resolve/resolv.conf
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.18.2
nameserver 192.168.18.1
nameserver 192.168.18.2
# Too many DNS servers configured, the following entries may be ignored.
nameserver 192.168.18.1
search .

On the server I haven't updated, /var/run/systemd/resolve/resolv.conf looks like:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 192.168.18.2
nameserver 192.168.18.1

The netplan configuration is identical on both servers, both servers use two interfaces, but only the new one duplicates the DNS' with the dhcp4: true setting.

Normally I wouldn't care as much, since I expect it just chooses one at random anyways. But I'm running a kubelet service, which only expects two DNS servers in this particular file, and now that breaks.

My temporary fix is to use dhcp4: false for the eno2 interface, (in the netplan config) and manually configure the routes and addresses I need, but this is obviously a workaround.

I've tried to look online for changes between the two Ubuntu versions, and netplan and duplicate DNS entries, but I've not been able to find anything, and I don't really feel like updating the other servers until I have a good solution for this.

Update:

From Am I running NetworkManager or networkd? both servers are running systemd-networkd.

415

1 + 10

networking

dns

netplan

22.04

David

3/30/24, 12:00 PM

What did you update from? At the end of the question you mention Ubuntu 20 and 22 which would be Ubuntu Core product version numbers.

slangasek

3/30/24, 7:20 PM

Why do you care about the contents of /run/systemd/resolve/resolv.conf ? /etc/resolv.conf should be a symlink pointing to /run/systemd/resolve/stub-resolv.conf.

DrLime2k10

3/31/24, 4:20 PM

I updated from 20.04 `5.4.0-144-generic` to 22.04 `5.15.0-67-generic`, does that help? @David

David

3/31/24, 4:24 PM

Do not add info in comments, correct the question please.

DrLime2k10

3/31/24, 4:25 PM

The kubelet uses the `/run/systemd/resolve/resolv.conf` file, see: https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues Personally I couldn't care less about the contents of either file. But it was working, I updated, and now the file behaviour has changed, which is "funny." @slangasek

Thomas Ward

3/31/24, 4:36 PM

@DrLime2k10 Did you have any type of configuration which did *not* use ResolveD as the resolver? The only reason that Netplan would write directly to resolv.conf in this manner in this way is two-fold: (1) Netplan DHCP for *both* interfaces on the same subnet serve those DNS servers, and it as such sets both for resolv.conf. (2) You are using resolv.conf and NOT SystemD ResolveD, which handles resolving better.

DrLime2k10

4/5/24, 8:15 AM

@ThomasWard I don't think I have any special configuration in terms of using/not using ResolveD. `systemd-resolved` is running on the server. I believe you're correct in that DHCP for both interfaces serve the DNS servers, and thus set both. I've inserted what the `resolve.conf` looks like on the machine I haven't update. Does that help?

Marco

4/5/24, 8:17 AM

netplan is not the "network manager". netplan tells the real network manager what you want. Now the question is which network manager is in use? networkd, NetworkManager, ifupdown, ... ?

DrLime2k10

4/5/24, 8:26 AM

@Marco `systemd-networkd` seems to be the network manager on both servers. I've updated the question.

Marco

4/6/24, 6:22 AM

it is hard to give a general answer, because there are many details. My suggestion is to configure systemd-networkd manually in `/etc/system/network` as needed.

Score:1

Ubuntu

jpvrenen

6/26/24, 2:52 PM

Instead of:

dhcp4: false

try:

dhcp4: true
dhcp4-overrides:
  use-dns: false

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Duplicate DNS entries after updating to 22.04

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.