Krdytkyu

I have a Lenovo Thinkpad X220 running Ubuntu 18.04. It has an Ethernet port and a wireless card. So far as networking goes, everything was automatically configured using defaults during installation. In the resulting setup, DNS resolution only works when the wireless interface is active and connected. Under previous Ubuntu versions, DNS would resolve over either wired or wireless links, depending on which was active.

I have spent quite a lot of time trying to understand how Linux networking is configured and managed and looked at lots of files and run lots of queries but frankly I have no desire to plough through so much detail that can be of interest only to server administrators. I get that the networking subsystem is full-featured and flexible, but mine is a very simple use case and I'm drowning in detail here. Help!!

I've reached a point where I can see this, in the output of systemd-resolve --status :

 Link 3 (wlp3s0)

      Current Scopes: DNS

       LLMNR setting: yes

MulticastDNS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

         DNS Servers: 172.28.16.1



Link 2 (enp0s25)

      Current Scopes: none

       LLMNR setting: yes

MulticastDNS setting: no

      DNSSEC setting: no

    DNSSEC supported: no

I think this explains why DNS resolution is happening over wireless (wlp3s0) rather than the wired link (enp0s25). But how can I cause the wired link to be used instead (or as well)? Can I change some configuration file or issue some systemd-resolve command to make it consider using enp0s25 for DNS?

Update: output from ifconfig and arp:

mark@MESX220:~$ ifconfig -a

enp0s25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 172.28.16.48  netmask 255.255.255.0  broadcast 172.28.16.255

        inet6 fe80::f2de:f1ff:fe91:692b  prefixlen 64  scopeid 0x20<link>

        ether f0:de:f1:91:69:2b  txqueuelen 1000  (Ethernet)

        RX packets 4444447  bytes 6308844438 (6.3 GB)

        RX errors 0  dropped 62  overruns 0  frame 0

        TX packets 1932598  bytes 156360177 (156.3 MB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device interrupt 20  memory 0xf2500000-f2520000  



lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 1000  (Local Loopback)

        RX packets 303309  bytes 15241987 (15.2 MB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 303309  bytes 15241987 (15.2 MB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 172.28.16.168  netmask 255.255.255.0  broadcast 172.28.16.255

        inet6 fe80::85c3:619d:5f54:95df  prefixlen 64  scopeid 0x20<link>

        ether 08:11:96:58:82:bc  txqueuelen 1000  (Ethernet)

        RX packets 63862  bytes 20011006 (20.0 MB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 2859  bytes 572860 (572.8 KB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



mark@MESX220:~$ arp -a

? (172.28.16.70) at dc:3a:5e:fc:e4:15 [ether] on enp0s25

POPLARDS (172.28.16.16) at 00:11:32:0e:f6:02 [ether] on enp0s25

? (172.28.16.32) at 00:15:99:ed:da:64 [ether] on enp0s25

router.asus.com (172.28.16.1) at 38:2c:4a:aa:75:18 [ether] on enp0s25

? (172.28.16.33) at 70:5a:0f:9e:c1:06 [ether] on enp0s25

? (172.28.16.70) at dc:3a:5e:fc:e4:15 [ether] on wlp3s0

? (172.28.16.144) at 34:38:b7:2a:1e:e0 [ether] on enp0s25

router.asus.com (172.28.16.1) at 38:2c:4a:aa:75:18 [ether] on wlp3s0

? (172.28.16.64) at c8:3a:6b:ac:6e:66 [ether] on wlp3s0

? (172.28.16.64) at c8:3a:6b:ac:6e:66 [ether] on enp0s25

Right, I finally twigged what the problem is. I had set a static IP address for the wired interface, but I hadn't supplied an address for DNS resolution. I added a DNS address (my router) and restarted the interface, and now it happily resolves DNS even when the wireless interface is down.

I guess I'd assumed that the system would assume it could resolve DNS via the gateway address. It seems to have worked that way in previous releases.