1

When I connect to my phone hotspot I would expect systemd-resolved to use dhcp provided dns list. For some reason it seems to not be the case for me.

I am using Ubuntu 22.04.1 LTS

/etc/systemd/resolved.conf is empty

When I connect to my phone wifi I get the results below:

ip a show wlp3s0

3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.138.69/24 brd 192.168.138.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 3411sec preferred_lft 3411sec

journalctl

paź 03 09:25:46 pc systemd-resolved[5434]: wlp3s0: Bus client set DNS server list to: 192.168.185.139, 192.168.22.175, 192.168.78.16

tcpdump -i wlp3s0 -e -nn -vv

tcpdump: listening on wlp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:25:46.427512 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 339: (tos 0xc0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 325)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx, length 297, xid 0xd83b70be, secs 1, Flags [none] (0x0000)
      Client-Ethernet-Address xx:xx:xx:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message (53), length 1: Request
        Client-ID (61), length 7: ether xx:xx:xx:xx:xx:xx
        Parameter-Request (55), length 17: 
          Subnet-Mask (1), Time-Zone (2), Domain-Name-Server (6), Hostname (12)
          Domain-Name (15), MTU (26), BR (28), Classless-Static-Route (121)
          Default-Gateway (3), Static-Route (33), YD (40), YS (41)
          NTP (42), Unknown (119), Classless-Static-Route-Microsoft (249), Unknown (252)
          RP (17)
        MSZ (57), length 2: 576
        Requested-IP (50), length 4: 192.168.138.69
        Hostname (12), length 13: "pc"
09:25:46.445267 yy:yy:yy:yy:yy:yy > xx:xx:xx:xx:xx:xx, ethertype IPv4 (0x0800), length 366: (tos 0x0, ttl 64, id 44909, offset 0, flags [DF], proto UDP (17), length 352)
    192.168.138.79.67 > 192.168.138.69.68: [udp sum ok] BOOTP/DHCP, Reply, length 324, xid 0xd83b70be, Flags [none] (0x0000)
      Your-IP 192.168.138.69
      Server-IP 192.168.138.79
      Client-Ethernet-Address xx:xx:xx:xx:xx:xx
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message (53), length 1: ACK
        Server-ID (54), length 4: 192.168.138.79
        Lease-Time (51), length 4: 3599
        RN (58), length 4: 1799
        RB (59), length 4: 3149
        Subnet-Mask (1), length 4: 255.255.255.0
        BR (28), length 4: 192.168.138.255
        Default-Gateway (3), length 4: 192.168.138.79
        Domain-Name-Server (6), length 4: 192.168.138.79
        Hostname (12), length 13: "pc"
        Vendor-Option (43), length 15: 65.78.68.82.79.73.68.95.77.69.84.69.82.69.68

The expected DNS is used if I execute dhclient -r wlp3s0 && dhclient wlp3s0

journalctl

paź 03 09:45:02 pc systemd-resolved[5434]: wlp3s0: Bus client set DNS server list to: 192.168.138.79

Issuing systemctl restart systemd-resolved brings back the unexpected ips.

Why does systemd-resolved assign the ips: 192.168.185.139, 192.168.22.175, 192.168.78.16 instead of the dhcp provided 192.168.138.79? How does it come up with the ips?

UPDATE

resolvectl

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (wlp3s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.78.16
       DNS Servers: 192.168.185.139 192.168.22.175 192.168.78.16
        DNS Domain: --

Link 3 (docker0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

cat /usr/lib/NetworkManager/conf.d/10-dns-resolved.conf

[main]
# We need to specify "dns=systemd-resolved" as for the time being our
# /etc/resolv.conf points to resolvconf's generated file instead of
# systemd-resolved's, so the auto-detection does not work.
dns=systemd-resolved

journalctl -b -g "dns" | grep -i -v avahi

paź 07 23:31:17 pc kernel: Key type dns_resolver registered
paź 07 23:31:18 pc NetworkManager[1067]: <info>  [1665178278.7520] Read config: /etc/NetworkManager/NetworkManager.conf (lib: 10-dns-resolved.conf, 20-connectivity-ubuntu.conf, no-mac-addr-change.conf) (run: 10-globally-managed-devices.conf) (etc: 10-ubuntu-fan.conf, default-wifi-powersave-on.conf)
paź 07 23:31:18 pc NetworkManager[1067]: <info>  [1665178278.8699] dns-mgr[0x5653847524a0]: init: dns=systemd-resolved rc-manager=unmanaged (auto), plugin=systemd-resolved
paź 07 23:31:18 pc freshclam[1299]: Fri Oct  7 23:31:18 2022 -> ^Invalid DNS reply. Falling back to HTTP mode.
paź 07 23:31:22 pc NetworkManager[1067]: <info>  [1665178282.8547] policy: set 'x' (wlp3s0) as default for IPv4 routing and DNS
paź 07 23:31:22 pc systemd-resolved[1021]: wlp3s0: Bus client set DNS server list to: 192.168.185.139, 192.168.22.175, 192.168.78.16
paź 07 23:31:39 pc systemd-resolved[1021]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.185.139.
paź 07 23:31:44 pc systemd-resolved[1021]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.22.175.
paź 07 23:31:49 pc systemd-resolved[1021]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.78.16.
paź 07 23:31:54 pc systemd-resolved[1021]: Using degraded feature set TCP instead of UDP for DNS server 192.168.185.139.
paź 07 23:32:04 pc systemd-resolved[1021]: Using degraded feature set TCP instead of UDP for DNS server 192.168.22.175.
paź 07 23:32:14 pc systemd-resolved[1021]: Using degraded feature set TCP instead of UDP for DNS server 192.168.78.16.
paź 07 23:32:35 pc systemd-resolved[1021]: Using degraded feature set UDP instead of TCP for DNS server 192.168.22.175.
paź 07 23:32:50 pc systemd-resolved[1021]: Using degraded feature set UDP instead of TCP for DNS server 192.168.185.139.
paź 07 23:32:56 pc systemd-resolved[1021]: Using degraded feature set TCP instead of UDP for DNS server 192.168.22.175.
paź 07 23:33:06 pc systemd-resolved[1021]: Using degraded feature set UDP instead of TCP for DNS server 192.168.78.16.
paź 07 23:33:11 pc systemd-resolved[1021]: Using degraded feature set TCP instead of UDP for DNS server 192.168.185.139.
paź 07 23:33:21 pc systemd-resolved[1021]: Using degraded feature set UDP instead of TCP for DNS server 192.168.22.175.
paź 07 23:33:27 pc systemd-resolved[1021]: Using degraded feature set TCP instead of UDP for DNS server 192.168.78.16.

systemd-analyze cat-config systemd/resolved.conf

# /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

#[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
Improve this question
6
  • 1
    To answer your last question see the man page from "The DNS servers contacted are determined from ...". If you still can't work out where they're coming from then it might be you have a second resolver installed?
    – pbhj
    Oct 7, 2022 at 16:56
  • 1
    Post your resolvectl output. Check that the file "/usr/lib/NetworkManager/conf.d/10-dns-resolved.conf" has content "dns=systemd-resolved". You could also do journalctl -b -g "dns" | grep -i -v avahi to show dns/DNS appearances in logs of current boot. Ah, hang on, also systemd-analyze cat-config systemd/resolved.conf as systemd-resolved can take config from elsewhere not just from its resolved.conf file. In your output journalctl says x.x.x.79 which isn't in either of your lists of DNS that you expect? Is that a typo? Is 192.168.138.79 the correct gateway (a router?)?
    – pbhj
    Oct 7, 2022 at 21:25
  • 1
    Presumably your dhclient.conf (used when you run dhclient) is just over-riding the DNS from elsewhere and those nameservers are in that file. In which case are you running /etc/dhcp/dhclient-exit-hooks.d/resolved which over-rides resolved with the dhclient settings I think.
    – pbhj
    Oct 7, 2022 at 21:31
  • 1
    I updated the post with more details, 192.168.138.79 is the expected IP provided by DHCP, it was a typo.
    – Marcin Król
    Oct 7, 2022 at 21:48
  • 1
    @pbhj Thank you for all your suggestions, I discovered the culprit. For whatever reason I had statically configured list of dns ips in /etc/NetworkManager/system-connections/name.nmconnection.
    – Marcin Król
    Oct 7, 2022 at 22:01

1 Answer 1

Reset to default
-1

The reason was statically configured list of IP addresses in /etc/NetworkManager/system-connections/name.nmconnection.

Improve this answer

You must log in to answer this question.

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