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
10
  • Please see https://netplan.io and https://netplan.io/examples.
    – waltinator
    Apr 5, 2022 at 19:51
  • 1
    describe your LAN (Local Area Network). Your computer is on the 172.16.15.0 sub-net, but the name servers are on 10.?.?.? sub-net, which must also be local. Where does the translation between the two nets occur (it must be via 172.16.15.1) and are the routes setup correctly? Apr 5, 2022 at 21:01
  • Plrease edit your question to show: ip a Welcome to Ask Ubuntu.
    – chili555
    Apr 5, 2022 at 21:27
  • @DougSmythies - sorry for the confusion, we use a public name server I was just told to obfuscate it when posting here, I should have specified that differently. The default route looks like it's set up correctly default via 172.16.15.1 dev eth0 proto static onlink 172.16.15.1 goes out to the internet Apr 5, 2022 at 21:27
  • Now let's see: cat /etc/network/interfaces Thanks.
    – chili555
    Apr 5, 2022 at 21:55

2 Answers 2

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.

-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.

2
  • Thanks for the detailed reply, unfortunately after changing my resolv.conf to look like that it still wasn't resolving, just hanging instead now though. I was under the impression that with netplan and the systemd-resolved.service they needed 127.0.0.53 in resolv.conf now as a sort of "internal" dns server that then directs to the dns servers you have listed in your net plan config depending on the interface? Apr 6, 2022 at 13:30
  • No, the point of having a standalone /etc/resolv.conf is precisely to bypass resolved resolution. Maybe the DNS server accesibility is off or maybe that server don't have the domain name queried correctly defined. First execute dig mysite.com to check which is the default server used, and then execute dig mysite.com @a.b.c.d where a.b.c.d is the IP of the desired DNS server. The first confirm which is the default server queried and the second if the server is accesible and responds correctly.
    – Fjor
    Apr 6, 2022 at 16:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .