Join Log in
Score:2
Jared Young avatar Ubuntu

systemd-resolved not resolving any domains

cn flag
Jared Young

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.
730
0 + 0
dns
cc flag
ubfan1
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.
0
Reply
Jared Young avatar
cn flag
Jared Young
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.
0
Reply
cc flag
ubfan1
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.
0
Reply
Score:4
Linas avatar Ubuntu
cn flag
Linas

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.

+ 3
SomeoneElse avatar
cn flag
SomeoneElse
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).
0
Reply
Linas avatar
cn flag
Linas
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.
0
Reply
SomeoneElse avatar
cn flag
SomeoneElse
(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.
1
Reply
Score:1
ognjen avatar Ubuntu
ky flag
ognjen

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
0 + 0
Josh avatar
cn flag
Josh
While I appreciate the work around is there no solution to this problem?
0
Reply
Jared Young avatar
cn flag
Jared Young
This actually does solve my problem! Agreed, thank you for the work around, but is there no solution?
0
Reply
ognjen avatar
ky flag
ognjen
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.
0
Reply
Jared Young avatar
cn flag
Jared Young
Upgraded to 21.10 and now it is working. No idea what changed, but systemd-resolved is working fine now.
0
Reply
Score:0
AnophelesGreyhoe avatar Ubuntu
ru flag
AnophelesGreyhoe

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.

+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.