11

My NetworkManager connects to the internet but I do not have any internet access due to a bad DNS configuration. I do not have much experience with DNS settings, but it appears the issue is with systemd-resolved. I can ping IP addresses directly (e.g. 8.8.8.8) and get a response normally, but I cannot resolve domains when using the default configuration below. I have tried a symlink to the three configuration modes listed in the systemd-resolved docs, but none of them work.

Cannot resolve any domain with the following, but I can ping IPs (tried a bunch and they all work) without any issues.

# /etc/resolv.conf 
nameserver 127.0.0.53
options edns0 trust-ad

I also get timeout errors when using dig or host.

; <<>> DiG 9.16.1-Ubuntu <<>> www.ubuntu.com
;; global options: +cmd
;; connection timed out; no servers could be reached

I can get domain resolution and connect to the internet by changing the resolv.conf nameserver to 8.8.8.8, but resolution takes a long time, with a web page taking >1 min to load even with network speed tests reporting over 100 mbps and ping <30 ms on the same machine.

The configuration below works, sort of, with really slow response times

# /etc/resolv.conf 
nameserver 8.8.8.8
options edns0 trust-ad

Additional info that might be helpful

Like I said, I am new to these systems and I am struggling to troubleshoot the issue. Below is everything that I think might be useful. All outputs below are using nameserver 127.0.0.53

Ubuntu 20.04.3 LTS

Output of systemd-resolve --status

Global
       LLMNR setting: no                  
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
          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 3 (ipv6leakintrf0)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no 
  DNSOverTLS setting: no 
      DNSSEC setting: no 
    DNSSEC supported: no 
  Current DNS Server: ::1
         DNS Servers: ::1
          DNS Domain: ~. 

Link 2 (wlo1)
      Current Scopes: none
DefaultRoute setting: no  
       LLMNR setting: yes 
MulticastDNS setting: no  
  DNSOverTLS setting: no  
      DNSSEC setting: no  
    DNSSEC supported: no  

# /etc/systemd/resolved.conf 
[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#DNSOverTLS=no
#Cache=no-negative
#DNSStubListener=yes
#ReadEtcHosts=yes

# NetworkManager configuration: /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: default-wifi-powersave-on.conf)

[main]
# rc-manager=symlink
# auth-polkit=true
# dhcp=internal
dns=systemd-resolved
plugins=ifupdown,keyfile

[connectivity]
uri=http://connectivity-check.ubuntu.com/

[ifupdown]
managed=false

[logging]
# backend=journal
# audit=true

[device]
wifi.scan-rand-mac-address=no

[device-mac-addr-change-wifi]
match-device=driver:rtl8723bs,driver:rtl8189es,driver:r8188eu,driver:8188eu,driver:eagle_sdio,driver:wl
wifi.scan-rand-mac-address=no

[connection]
wifi.powersave=3

# no-auto-default file "/var/lib/NetworkManager/no-auto-default.state"

The system log on startup

 Starting Network Name Resolution...
sisyphus systemd-resolved[6024]: Positive Trust Anchors:
sisyphus systemd-resolved[6024]: . IN DS 20326 8 2 e17f45b80b8f1d39a95f0b0d7c45a08458e880409bbc683457104237c7f8ec8d
sisyphus systemd-resolved[6024]: Negative trust anchors: 10.in-addr.arpa 16.172.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 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
sisyphus systemd-resolved[6024]: Using system hostname 'sisyphus'.

The system log in debug mode outputs the following, switching between UDP and TCP protocols.

Transaction 33247 for <ntp.ubuntu.com IN A> scope dns on ipv6leakintrf0/*.
systemd-resolved[4805]: Using feature level TCP for transaction 33247.
systemd-resolved[4805]: Sending query via TCP since UDP isn't supported.
systemd-resolved[4805]: Using feature level TCP for transaction 33247.
systemd-resolved[4805]: Connection failure for DNS TCP stream: Connection refused
systemd-resolved[4805]: Retrying transaction 33247.
Improve this question
3
  • Try disabling IPV6 and give your IPV4 your router instead of a circular systemd-resolv reference. The systemd-router status should have the router ip as the DNS entry on the ipv4 link.
    – ubfan1
    Oct 21, 2021 at 21:43
  • How do I disable IPV6 ? I tried disabling IPV6 in the network manager GUI and didn't see any difference in the output of systemd-resolve --status. The same IPV6 DNS server were still listed.
    – Jared Young
    Oct 25, 2021 at 15:41
  • I disable IPV6 at the router as well as in the NetworkManager gui. Nothing else seems odd, except the "UDP is not supported" from your log -- I do get occasional fallbacks to UDP from TCP when certain error conditions occur. I don't even have a dns line in my NetworkManager.conf file.
    – ubfan1
    Oct 25, 2021 at 16:00

3 Answers 3

Reset to default
5

This happens all the time and now i normally get back my /etc/resolv.conf file by disabling systemd-resolved.

 sudo systemctl stop systemd-resolved
 sudo systemctl disable systemd-resolved

Then in your /etc/resov.conf file i add nameserver (IP of DNS server you want to use)

 nameserver 8.8.4.4
Improve this answer
4
  • 4
    While I appreciate the work around is there no solution to this problem?
    – Josh
    Oct 22, 2021 at 16:57
  • 2
    This actually does solve my problem! Agreed, thank you for the work around, but is there no solution?
    – Jared Young
    Oct 25, 2021 at 15:18
  • 2
    Not sure this happens to me a lot so I just gave up fixing it sorry this is one thing where in my experience with systemd has not been that great.
    – ognjen011
    Oct 25, 2021 at 18:55
  • Upgraded to 21.10 and now it is working. No idea what changed, but systemd-resolved is working fine now.
    – Jared Young
    Dec 5, 2021 at 6:52
4

My system does not have a /etc/NetworkManager directory, but otherwise has the same problem. My system is based on the older /etc/network/interfaces style of configuration.

After an upgrade to Ubuntu 22.04, DNS stopped working. The /etc/network/interfaces file hasn't changed in seven years, so that's not the problem.

Turns out there is a brand-new config file located at /etc/systemd/resolved.conf. Editing this and uncommenting the line DNS= and adding a list of servers fixes the problem. This requires service systemd-resolved restart in order to take effect.

Improve this answer
3
  • Thanks - I too have a system using "/etc/network/interfaces" and this "works" in that I can manually apply the DNS settings that should come from DHCP (and look correct in "/etc/network/interfaces"). What it doesn't explain is why systemd isn't using that, or what it was trying to use instead? Everything was working until a week or so ago (Ubuntu 20.04).
    – SomeoneElse
    Feb 20 at 20:29
  • That systemd wants to do things differently is a given. The issue here is that the OS upgrade was bungled: there was no conversion from the old style to the new style, and there were no warnings during the upgrade, and no opportunities to review and correct. Basically, they're rolling out new systemd features as fast as possible, without any kind of testing, and letting users deal with the bugs as they find them.
    – Linas
    Feb 24 at 22:02
  • 1
    (re systemd) that's been in Ubuntu for donkey's years now. To be clear, in my case at least, the issue didn't appear when the system was upgraded to a version using systemd by default (18.04) or even at the last upgrade (20.04), but a couple of weeks ago. The software combination that it shows up on does look like an edge case that accidentally escaped testing, but it's not "a systemd problem" per se.
    – SomeoneElse
    Feb 24 at 22:16
0

In my case, after switching from a wired ethernet interface to a wireless one, I had to restart systemd-networkd.

Prior to that I could see that DNS resolution was working if I "cut out the middle man" and went direct to the router.

Improve this answer

You must log in to answer this question.

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