Question

0

DNS issue migrating from ifupdown to netplan

rated 0 times [ 0] [ 0] / answers: 1 / hits: 651 / 2 Years ago, thu, january 27, 2022, 3:12:18

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

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

assionortly

Add To Favorites

Follow

Total Points: 423

Total Questions: 121

Total Answers: 115

Location: Chad

Member since Wed, Sep 30, 2020

4 Years ago

answered 2 Years ago dersol · Accepted Answer

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.