Score:0

DNS server not working anymore

cn flag

I started my computer two hours ago and was confused that my browser (Firefox) didn't work anymore. Took my some time and research to realize that my DNS server seems to fail. I don't know why it's not working anymore. On my last session I installed ProtonVPN client, maybe it misconfigured something? I have actually never done any changes to any DNS settings ever in my life before.

So how can I solve my problem that I can't browse? What I've found out so far:

  1. Pinging e.g. 8.8.8.8 works, so there is definitely a connection to the internet (I'm writing here using TOR browser which works btw so I'm really online)

  2. The DNS server to use is specified in /etc/resolv.conf. Beside a long comment there is just this:

    nameserver 127.0.0.53  
    options edns0 trust-ad
    

So the DNS server is a local name server running on port 53. According to my research this seems to be the default value.

  1. I found this command lsof -Pn -iUDP:53 to make sure that the name server is running (guess that's what it is doing? There seems to be no man page for this command...)

    COMMAND   PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
    lollypop 3433 jonas   21u  IPv4 529240      0t0  UDP 127.0.0.1:49435->127.0.0.53:53 
    lollypop 3433 jonas   22u  IPv4 529816      0t0  UDP 127.0.0.1:43447->127.0.0.53:53 
    lollypop 3433 jonas   24u  IPv4 529250      0t0  UDP 127.0.0.1:53369->127.0.0.53:53 
    lollypop 3433 jonas   26u  IPv4 528227      0t0  UDP 127.0.0.1:39800->127.0.0.53:53 
    lollypop 3433 jonas   27u  IPv4 527211      0t0  UDP 127.0.0.1:43076->127.0.0.53:53 
    lollypop 3433 jonas   28u  IPv4 527215      0t0  UDP 127.0.0.1:51560->127.0.0.53:53 
    lollypop 3433 jonas   29u  IPv4 529792      0t0  UDP 127.0.0.1:43262->127.0.0.53:53 
    lollypop 3433 jonas   30u  IPv4 530442      0t0  UDP 127.0.0.1:38656->127.0.0.53:53 
    lollypop 3433 jonas   31u  IPv4 529238      0t0  UDP 127.0.0.1:42753->127.0.0.53:53
    

I found also this command sudo systemctl status systemd-resolved to check whether the server is running

```
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset:>
     Active: active (running) since Sun 2021-08-08 22:06:19 CEST; 1h 26min ago
       Docs: man:systemd-resolved.service(8)
             https://www.freedesktop.org/wiki/Software/systemd/resolved
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configurati>
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 991 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 9338)
     Memory: 11.1M
     CGroup: /system.slice/systemd-resolved.service
             └─991 /lib/systemd/systemd-resolved
```

So it really looks like the DNS server is running right? But why can it then not lookup addresses?

Using dig google.com I only get the following error:

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

I hope anyone can help me here? I would just like to reset it to Ubuntu's defaults as it was all the time before. Any maybe even someone got an idea what might have caused this problem?

jpbrain avatar
ca flag
Hellow. Can you uninstall proton-VPN and try again? If traffic is being redirected through proton that could explain this behavior.
A. Herlas avatar
bz flag
Edit /etc/resolvconf/resolv.conf.d/head and add `search gatewayIP`, then this will make it permanent change.
Score:0
cn flag

So according to A. Herlas' solution I could solve this problem. Even though I didn't understand your solution instantly some research fixed it for me.

Basically I found the answer here. So i just installed resolvconf, changed /etc/resolvconf/resolv.conf.d/head as Herlas suggested and everything does finally works fine again :)

Thanks for your help!

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.