Score:0

Netplan, networkd, resolvconf conflicts: Can't change DNS servers

lt flag

I'm running Ubuntu 22.04.1 on a headless server and trying to change the DNS that the server uses. I set up the netplan .yaml file like this to use Cloudflare's servers:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - xxxx.xxxx.xxx::2/64
      routes:
        - to: default
          via: xxx.xxx.xxx.xxx
          metric: 100
          on-link: true
        - to: ::/0
          via: fe80::1
      nameservers:
        addresses:
          - 1.1.1.1
          - 2606:4700:4700::1111
          - 1.0.0.1
          - 2606:4700:4700::1001

After a sudo netplan apply, everything seemed copasetic. Except nslookup somewebsite.com showed that the DNS used was 8.8.8.8.

I traced the source of this, I think, to the /etc/resolv.conf file, which is not a symbolic link and which looks like this:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual #nameservers.
#nameserver 127.0.0.53
nameserver 8.8.8.8

Not only does that file say that it's not to be edited, it in fact can't be edited. And I'm sure that, if I were to edit it, it would be overwritten (by resolvconf, I assume) with that Google nameserver.

I'm now in a position where everything checks out except the actual DNS being used, which is stubbornly stuck on 8.8.8.8.

For example, sudo networkctl status enp0s31f6 returns this:

● 2: enp0s31f6                                                                       
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /run/systemd/network/10-netplan-enp0s31f6.network
                          Type: ether
                         State: routable (configured)
                  Online state: online                                               
                          Path: pci-0000:00:1f.6
                        Driver: e1000e
                        Vendor: Intel Corporation
                         Model: Ethernet Connection (2) I219-LM
                    HW Address: xx:xx:xx:xx:xx:xx (Fujitsu Technology Solutions GmbH)
                           MTU: 1500 (min: 68, max: 9000)
                         QDisc: pfifo_fast
  IPv6 Address Generation Mode: eui64
          Queue Length (Tx/Rx): 1/1
              Auto negotiation: yes
                         Speed: 1Gbps
                        Duplex: full
                          Port: tp
                       Address: xxx.xxx.xxx.xxx
                                xxxx:xxx:xx:xxxx::2
                                xxxx::xxxx:xxx:xxxx:xxxx
                       Gateway: xxx.xxx.xxx.xxx
                                xxx.xxx.xxx.xxx
                                fe80::1
                           DNS: 1.1.1.1
                                1.0.0.1
                                2606:4700:4700::1111
                                2606:4700:4700::1001
             Activation Policy: up
           Required For Online: yes
             DHCP6 Client DUID: DUID-EN/Vendor:0000ab11edfd2edd2491a9410000

And sudo resolvctl status gives this:

    Global
           Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: foreign
  Current DNS Server: 1.1.1.1
         DNS Servers: 1.1.1.1
Fallback DNS Servers: 1.0.0.1

Link 2 (enp0s31f6)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001

Link 8 (wg0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

So everything I look at tells me that 1.1.1.1 is the primary DNS for my server. Except nslookup askubuntu.com which stubbornly always returns this:

    Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   askubuntu.com
Address: 151.101.65.69
Name:   askubuntu.com
Address: 151.101.193.69
Name:   askubuntu.com
Address: 151.101.129.69
Name:   askubuntu.com
Address: 151.101.1.69

I verified that 8.8.8.8 is indeed being used by running sudo tcpdump -n -vv -i enp0s31f6 -W 1200 | grep google.com in one window while running nslookup google.com in another.

How can I get my server to stop using 8.8.8.8 and start using the DNS I've been trying to get it to run?

dummyuser avatar
uy flag
Welcome, is your `systemd-resolved.service active` and running? `systemctl status systemd-resolved.service`
Steve S. avatar
lt flag
Thanks. Yes it is running.
dummyuser avatar
uy flag
if I look at 22.04.1 (server and desktop), there is `/etc/resolv.conf` a link to `../run/systemd/resolve/stub-resolv.conf`. somehow your system is tainted there.
Steve S. avatar
lt flag
Yes, that seems to be what most people have. I'm not at all sure why I have an actual file instead of a symlink.
us flag
Do you have the resolvconf package installed?
us flag
(the comments in /etc/resolv.conf suggest that you do.) Anyway, resolvconf is deprecated, and you should remove it from your system. If you installed it: why?
Steve S. avatar
lt flag
I see from the logs that I did install it but I have no idea why or as part of what. I have since managed to get things working by changing the attributes on /etc/resolv.conf, deleting it and replacing it with a symlink to /run/systemd/resolve/stub-resolv.conf. I would like to uninstall resolvconf, but fear doing so will mess things up....
Steve S. avatar
lt flag
Just realized why and how resolvconf got installed on my system. It was installed by the script I used to configure wireguard. I figured this out when wireguard no longer worked after I removed resolvconf. The fix for that was just to comment out the DNS line in wg0.conf.
I sit in a Tesla and translated this thread with Ai:

mangohost

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.