0

I'm trying to pinpoint the issues with my systemd DHCP/DNS resolution and settings. I'm running Kubuntu 18.04 LTS, I've got both wired (eno1) and wireless (wlp2s0) connection.

In some networks (both wired and wireless) I need to use OpenConnect VPN, in some I don't (i.e. when I'm in the office).

I'm using virt-manager to run several VMs with various network configurations (virbr0-nic, virbr0) - I'm mentioning it because KVM is running DNS and DHCP related services to provide network to the VMs. I see that it uses dnsmasq, I never installed nor configured it:

# ps aux | grep dnsmasq 
libvirt+  1159  0.0  0.0  49964   372 ?        S    12:54   0:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
root      1160  0.0  0.0  49936   372 ?        S    12:54   0:00 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper

Currently, when I'm in the office, everything works OK. The DHCP configuration is applied correctly.

But when I connect at home, the systemd-resolve --status tells me that I'm using my office DNS servers (192.9.200.151,192.9.200.149), which are unavailable from my home network:

Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 5 (virbr0-nic)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 4 (virbr0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 3 (wlp2s0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.9.200.151
                      192.9.200.149
                      2a01:1700:2:ffff::9f01
                      2a01:1700:3:ffff::9822

Link 2 (eno1)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

The Network Manager configuration is set to "Automatic", the "Other DNS Servers" field is empty.

The /etc/resolv.conf always lists only 127.0.0.53 (it's a symlink to /run/systemd/resolve/stub-resolv.conf)

In the /etc/systemd/network/ dir I have only one file: eno1.network with:

[DHCP]
UseDNS=true

After connecting to home WiFi journalctl mentions the following:

NetworkManager[878]: <info>  [1531741664.5062] dhcp4 (wlp2s0): dhclient started with pid 5711
dhclient[5711]: DHCPREQUEST of 192.168.1.10 on wlp2s0 to 255.255.255.255 port 67 (xid=0x4234d23a)
dhclient[5711]: DHCPACK of 192.168.1.10 from 192.168.1.254
wpa_supplicant[864]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-35 noise=9999 txrate=144400
NetworkManager[878]: <info>  [1531741664.5648] dhcp4 (wlp2s0):   address 192.168.1.10
NetworkManager[878]: <info>  [1531741664.5654] dhcp4 (wlp2s0):   plen 24 (255.255.255.0)
NetworkManager[878]: <info>  [1531741664.5657] dhcp4 (wlp2s0):   gateway 192.168.1.254
NetworkManager[878]: <info>  [1531741664.5659] dhcp4 (wlp2s0):   lease time 86400
NetworkManager[878]: <info>  [1531741664.5662] dhcp4 (wlp2s0):   hostname 'my-hostname'
NetworkManager[878]: <info>  [1531741664.5664] dhcp4 (wlp2s0):   nameserver '192.9.200.151'                       # <--- This should be same as gateway
NetworkManager[878]: <info>  [1531741664.5667] dhcp4 (wlp2s0):   nameserver '192.9.200.149'
NetworkManager[878]: <info>  [1531741664.5669] dhcp4 (wlp2s0):   domain name 'home'
NetworkManager[878]: <info>  [1531741664.5672] dhcp4 (wlp2s0): state changed unknown -> bound
avahi-daemon[862]: Joining mDNS multicast group on interface wlp2s0.IPv4 with address 192.168.1.10.
avahi-daemon[862]: New relevant interface wlp2s0.IPv4 for mDNS.
avahi-daemon[862]: Registering new address record for 192.168.1.10 on wlp2s0.IPv4.
NetworkManager[878]: <info>  [1531741664.5861] device (wlp2s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
NetworkManager[878]: <info>  [1531741664.6017] device (wlp2s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
NetworkManager[878]: <info>  [1531741664.6022] device (wlp2s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
NetworkManager[878]: <info>  [1531741664.6025] manager: NetworkManager state is now CONNECTED_LOCAL
dhclient[5711]: bound to 192.168.1.10 -- renewal in 36652 seconds.
NetworkManager[878]: <info>  [1531741664.6124] manager: NetworkManager state is now CONNECTED_SITE
NetworkManager[878]: <info>  [1531741664.6126] policy: set 'pipkarybenka' (wlp2s0) as default for IPv4 routing and DNS
NetworkManager[878]: <info>  [1531741664.6132] device (wlp2s0): Activation: successful, device activated.
dnsmasq[1159]: reading /etc/resolv.conf
dnsmasq[1159]: using nameserver 127.0.0.53#53
NetworkManager[878]: <info>  [1531741664.6148] manager: NetworkManager state is now CONNECTED_GLOBAL

Note that the applied nameserver is not correct, should be same as gateway.

After a while following logs start to appear:

systemd-resolved[23209]: Using degraded feature set (UDP) for DNS server 192.9.200.149.
systemd-resolved[23209]: Using degraded feature set (TCP) for DNS server 192.9.200.151.
systemd-resolved[23209]: Using degraded feature set (TCP) for DNS server 192.9.200.149.
systemd-resolved[23209]: Using degraded feature set (UDP) for DNS server 192.9.200.151.
systemd-resolved[23209]: Using degraded feature set (TCP) for DNS server 192.9.200.151.
systemd-resolved[23209]: Using degraded feature set (UDP) for DNS server 192.9.200.151.
systemd-resolved[23209]: Using degraded feature set (UDP) for DNS server 192.9.200.149.
systemd-resolved[23209]: Using degraded feature set (TCP) for DNS server 192.9.200.151.
systemd-resolved[23209]: Using degraded feature set (TCP) for DNS server 192.9.200.149.

Without valid DNS I cannot connect to my VPN service or use the internet whatsoever. If I would manually add proper DNS via systemd-resolve --set-dns=192.168.1.254 --interface=wlp2s0 everything starts to work correctly. At this point I can connect to VPN and the 192.9.200.151 DNS is applied.

Unfortunately, many times after a while the VPN connection drops and I'm back to square one.

I assume that somewhere I have hardcoded wrong DNS entries, most likely related to dnsmasq, but I don't know how to diagnose it. The /var/lib/libvirt/dnsmasq/default.conf contains:

strict-order
user=libvirt-dnsmasq
pid-file=/var/run/libvirt/network/default.pid
except-interface=lo
bind-dynamic
interface=virbr0
dhcp-range=192.168.122.2,192.168.122.254
dhcp-no-override
dhcp-authoritative
dhcp-lease-max=253
dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile
addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts

So, my main question is: why is DHCP unable to set proper DNS entry? How can I pinpoint the issue?

  • If I stop libvirtd service and kill dnsmasq processes, the DHCP still is applied the wrong way – Mirek Jul 16 '18 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.