Very slow DNS lookup

Question

I'm on Ubuntu 16.04 LTS, and when I visit a website/curl/wget/ping/etc anything that isn't an IP address, it takes an annoyingly long time (> 5 s), whereas anything directly using an IP address is pretty much instant (< 10 ms, as one would expect).

When I cat /etc/NetworkManager/NetworkManager.conf, I get:

[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq

[ifupdown]
managed=false

I've tried changing to #dns=dnsmasq, but it didn't have any noticeable effect.

cat /etc/network/interfaces is also quite basic:

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

A bit odd is cat /etc/resolv.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 10.63.240.10
nameserver 127.0.1.1
search $companydomain$.com

The nameserver 10.63.240.10 is something a colleague doesn't have, and is the only way in which the above 3 files differ for us. I suspect that is the root of the issue, because when I do host www.stackexchange.com 10.63.240.10, I get:

;; connection timed out; no servers could be reached

Commenting it out and restarting the network-manager fixes the issue temporarily, only to return upon rebooting.

I've also noticed in the Network Connections menu, two (seemingly) auto-generated Bridge entries are listed: br-8f98800bd128 and br-bd749c12d64c. If I delete these, they're back after a reboot. My aforementioned colleague doesn't have these either.

I've also tried the suggestions from How do I configure my DNS settings in Ubuntu server? and Extrememly slow DNS lookup, but the issue remains.

Per M. Becerra's suggestion, I ran sudo updatedb; locate 10.63.240.10. This didn't give me any output.

Mikael Schultz suggested I do nmcli device show, which outputs:

GENERAL.DEVICE:                         br-8f98800bd128
GENERAL.TYPE:                           bridge
GENERAL.HWADDR:                         02:42:50:5E:58:3B
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     br-8f98800bd128
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/2
IP4.ADDRESS[1]:                         172.18.0.1/16
IP4.GATEWAY:                            
IP6.GATEWAY:                            

GENERAL.DEVICE:                         br-bd749c12d64c
GENERAL.TYPE:                           bridge
GENERAL.HWADDR:                         02:42:B1:85:6D:E3
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     br-bd749c12d64c
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/3
IP4.ADDRESS[1]:                         172.19.0.1/16
IP4.GATEWAY:                            
IP6.GATEWAY:                            

GENERAL.DEVICE:                         docker0
GENERAL.TYPE:                           bridge
GENERAL.HWADDR:                         36:CA:3D:66:B7:03
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     docker0
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/1
IP4.ADDRESS[1]:                         172.17.0.1/16
IP4.GATEWAY:                            
IP6.GATEWAY:                            

GENERAL.DEVICE:                         wlp3s0
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         00:28:F8:9C:2A:4D
GENERAL.MTU:                            0
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     Crowdynews
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnection/0
IP4.ADDRESS[1]:                         10.0.0.27/24
IP4.GATEWAY:                            10.0.0.1
IP4.ROUTE[1]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.DNS[1]:                             8.8.8.8
IP4.DNS[2]:                             8.8.4.4
IP4.DOMAIN[1]:                          crowdynews.com
IP6.ADDRESS[1]:                         fe80::9264:b967:1c59:3e50/64
IP6.GATEWAY:                            

GENERAL.DEVICE:                         enp4s0
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         C8:5B:76:F1:1C:EC
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
WIRED-PROPERTIES.CARRIER:               off

GENERAL.DEVICE:                         lo
GENERAL.TYPE:                           loopback
GENERAL.HWADDR:                         00:00:00:00:00:00
GENERAL.MTU:                            65536
GENERAL.STATE:                          10 (unmanaged)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
IP4.ADDRESS[1]:                         127.0.0.1/8
IP4.GATEWAY:                            
IP6.ADDRESS[1]:                         ::1/128
IP6.GATEWAY:

ip address prints:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether c8:5b:76:f1:1c:ec brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:28:f8:9c:2a:4d brd ff:ff:ff:ff:ff:ff
inet 10.0.0.27/24 brd 10.0.0.255 scope global dynamic wlp3s0
   valid_lft 1660731sec preferred_lft 1660731sec
inet6 fe80::9264:b967:1c59:3e50/64 scope link 
   valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
link/ether 02:42:f3:cd:08:8c brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
   valid_lft forever preferred_lft forever
5: br-8f98800bd128: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
link/ether 02:42:50:5e:58:3b brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-8f98800bd128
   valid_lft forever preferred_lft forever
6: br-bd749c12d64c: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
link/ether 02:42:b1:85:6d:e3 brd ff:ff:ff:ff:ff:ff
inet 172.19.0.1/16 brd 172.19.255.255 scope global br-bd749c12d64c
   valid_lft forever preferred_lft forever

cat /etc/resolvconf/resolv.conf.d/head:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 10.63.240.10

cat /etc/resolvconf/resolv.conf.d/base generates no output.

How do I fix this?

Try to change to a name server like 8.8.8.8 - Side note: https://whois.domaintools.com/10.63.240.10 — M. Becerra, May 29 '18 at 11:06
I've tried adding a line with dns-nameservers 8.8.8.8 in /etc/network/interfaces, but that didn't fix it, because 10.63.240.10 was still tried first. — Ghost, May 29 '18 at 11:32
Please comment out the original name server to let 8.8.8.8 be used — M. Becerra, May 29 '18 at 11:52
Where? Removing nameserver 10.63.240.10 from /etc/resolv.conf and then manually restarting the network-manager only works temporarily. It's back after a reboot. I can't find where it keeps coming from, but it always returns. — Ghost, May 29 '18 at 11:59
Sorry I meant sudo grep -r "10.63.240.10" /*.Also try to comment out the current name server at /etc/resolv.conf by editing it like this # nameserver 10.63.240.10 and then append nameserver 8.8.8.8 — M. Becerra, May 29 '18 at 13:04
As mentioned, commenting out nameserver 10.63.240.10 from /etc/resolv.conf seems to work, but a reboot reinstates the problem. — Ghost, May 29 '18 at 14:19
Could you edit your answer with the output of the command nmcli device show? And also the output of the command ip address. — , May 29 '18 at 19:15
Nice, but it looks okay to me. Can you also insert the output of cat /etc/resolvconf/resolv.conf.d/head and cat /etc/resolvconf/resolv.conf.d/base? — , May 31 '18 at 16:46

score 3 · Accepted Answer · answered Jun 08 '18 at 17:20

3

The problem seems to be that there is a faulty DNS server in the file /etc/resolvconf/resolv.conf.d/head.

Edit the head file and delete the line that says nameserver 10.63.240.10 and you should have solved your problem.

Run sudo nano /etc/resolvconf/resolv.conf.d/head from the Terminal to edit the file and make sure that the only content of the file is:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

Hope this solves your problem.

answered Jun 08 '18 at 17:20

It seems your suggestion worked. Should this be a permanent solution? Because it even says in the file any modifications will be overwritten. I've rebooted, but that didn't seem to restore the file to the version with nameserver 10.63.240.10, so DNS requests are still quick. :) Do you have any idea where the custom DNS server might've come from? As far as I know, I haven't set it myself, and I'm the only one who's installed anything on this laptop. Could it have been set by some network settings? – Ghost Jun 11 '18 at 10:21
I would consider it a permanent solution. If it isn’t I’m sure someone will object :) It should not have been there in the first place and I have no idea how it got there. These (head and base) are the files that will be the source of the file /etc/resolv.conf when it is generated, that is why the text is saying that modifications will be overwritten. – Jun 11 '18 at 11:17
Aha, so the # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN line is only in the /etc/resolv.conf.d/head file so it finds its way into the regular /etc/resolv.conf file? Thanks! – Ghost Jun 11 '18 at 15:08
Yes that is my understanding. No problem :) – Jun 11 '18 at 17:33

score 2 · Answer 2 · answered Mar 28 '23 at 12:14

2

Meybe this can help someone (THE PROBLEM IS THE DOCKER). I had the same problem on UBUNTU 22.04, after a long time changing network related configs the solutions was.

docker network prune

I had a lot of docker networks and this was causing a slow DNS Lookup (I could reach some sites and others was giving timeout)

answered Mar 28 '23 at 12:14

Juan Andrade

121

Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Community Mar 29 '23 at 10:36

score 1 · Answer 3 · answered May 01 '19 at 04:06

I had the same problem. To solve it, I changed my DNS server settings and now everything gets resolved really fast (apt update, Firefox startup, git, etc.).

Change DNS server settings:

If you are using a wired network, go to Ubuntu Settings > Network > Wired > Options > IPv4. Make sure IPv4 Method is Automatic (DHCP) and choose your DNS server (I personally use https://1.1.1.1/dns/). You can do the same for IPv6, make sure to put a valid IPv6 to the DNS server.

If you are using a Wireless connection, go to Ubuntu Settings > Wireless > [YourWifi] > Options and follow the same instructions.

OP seems to like using terminal, the equivalent way is using nmtui (NetworkManager TUI) — Pablo Bianchi, Sep 14 '19 at 19:03

Very slow DNS lookup

3 Answers3

Linked