0

I am working through configuring an ubuntu 20.04 server and am attempting to switch over from using ifupdown to using netplan. I am not a network guru by any stretch, but I believe my problem has something to do with DNS:

root@local:~# curl https://google.com
curl: (6) Could not resolve host: google.com

I followed the top answer from this post to start link. I made sure that I removed these packages: net-tools, ifupdown (and removed lines in /etc/network/interfaces and files in /etc/network/interfaces.d) and resolvconf. I believe that I have my netplan config set up correctly as follows:

---
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
      dhcp6: no
      addresses:
        - 172.16.15.161/24
      routes:
        - to: default
          via: 172.16.15.1
      nameservers:
        addresses: [10.x.x.x, 10.x.y.x]

and when a I do a netplan --debug generate and netplan apply I don't get any errors, I made sure to reboot after changes. To make sure it wasn't our dns servers causing the issue I tried using 8.8.8.8 as well. I also checked that /etc/resolv.conf was symlinked to /run/systemd/resolve/stub-resolv.conf, DNSSEC=no and that my dns servers are listed when doing a resolvectl and looking at eth0. For what it's worth, we originally had a bond interface when configured with ifupdown but we got rid of it when switching to netplan since we have only one eth interface (I got rid of it by doing ip link delete dev bond0). We get the feeling that maybe something from the old configuration is possibly still lingering causing issues.

EDIT: adding output of ip a

root@local:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:50:56:b7:41:7f brd ff:ff:ff:ff:ff:ff
    inet 172.16.15.161/24 brd 172.16.15.255 scope global eth0
       valid_lft forever preferred_lft forever
Zack Schmidt
  • 1

2 Answers2

0

We eventually found that iptables was the cause of our issues. Firstly we were dropping all loopback traffic so we added the below rule. I believe this was an issue because of how systemd-resolved works on 127.0.0.53:53.

-A INPUT -i lo -j ACCEPT

Secondly, with the way our iptables is configured, since we got rid of our bond0 interface iptables didn't know where to send traffic coming in over eth0 so it was never making it to our rules to allow tcp/udp traffic on port 53. Those rules look like:

-A OUTPUT -p udp -m udp --dport 53 -m state --state NEW,ESTABLISHED -m comment --comment "Allow dns (UDP)" -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -m state --state NEW,ESTABLISHED -m comment --comment "Allow dns (TCP)" -j ACCEPT

To anyone else who might need some inspiration check out this thread or similar searches link.

Zack Schmidt
  • 1
-1

I had the same problem resulting, I suppose, from systemd trying to resolve DNS on its own, and not honoring the netplan configured nameservers, and that the entries listed in /etc/resolv.conf don't resolve names correctly (or the file is empty!). Also tried to use the resolvconf package to let it manage that file, but without success.

After reading man systemd-resolved.service found that the problem is resolved (no pun intended) by deleting the symlink /etc/resolv.conf and replacing it with a real file including my desired name servers. In your case you'll use (as root):

rm -f /etc/resolv.conf
echo -e 'nameserver 10.x.x.1\nnameserver 10.x.x.2' >/etc/resolv.conf
chmod 444 /etc/resolv.conf

The -e option of echo allows inserting the '\n' character to get two distinct lines in a single command, and so the resulting /etc/resolv.conf content is:

nameserver 10.x.x.1
nameserver 10.x.x.2

The 444 rights of chmod(r--r--r--) are an effort to avoid unintended modifications by program installers/updaters.

Fjor
  • 314
  • 2
  • 10