2

I just upgraded from Ubuntu 17 to 18.04 and everything seemed to go pretty smoothly.

However, after the upgrade, there have been two (probably directly related issues). 1, the configuration application for my VPN (mullvad) no longer starts, which is not too pressing of an issue. 2, perhaps caused by some configuration originally managed by the VPN application, all my DNS queries from browsers are super slow.

I have tested from Chrome, Firefox, and Waterfox, and in all cases, it seems that DNS queries take between 5 to 5.2 seconds. I assume there is some incorrect configuration somewhere which is timing out after 5 seconds, then the browser proceeds with another configuration and gets a quick response back.

Here is a typical page load waterfall: Slow DNS queries from browsers

On the other hand, when I go to the command line and try dig, I get a speedy response:

$ dig www.disney.com

; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> www.disney.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35027
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.disney.com.            IN  A

;; ANSWER SECTION:
www.disney.com.     255 IN  CNAME   matterhornsecure.edgekey.net.
matterhornsecure.edgekey.net. 743 IN    CNAME   e13055.e12.akamaiedge.net.
e13055.e12.akamaiedge.net. 19   IN  A   23.54.221.6

;; Query time: 30 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Jun 04 20:59:26 EDT 2018
;; MSG SIZE  rcvd: 137

I set my DNS server to a Cloudflare DNS server, 1.1.1.1, but I'm not sure how that may be impacting this.

Here is some other information that I have seen asked about on other similar threads:

$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 11020  bytes 915775 (915.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11020  bytes 915775 (915.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.11.0.19  netmask 255.255.0.0  destination 10.11.0.19
        inet6 fdda:d0d0:cafe:1197::1011  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::a6e6:1fa2:8d15:cf1  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 1000 overruns 0  carrier 0  collisions 0

wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.7  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::9b85:3e1:c0d1:d2f9  prefixlen 64  scopeid 0x20<link>
        inet6 2604:2000:81c2:300::3  prefixlen 128  scopeid 0x0<global>
        inet6 2604:2000:81c2:300:b765:7f68:a70b:8ebd  prefixlen 64  scopeid 0x0<global>
        ether 34:02:86:60:d3:30  txqueuelen 1000  (Ethernet)
        RX packets 41063  bytes 49615001 (49.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13120  bytes 2266057 (2.2 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

$ nmcli device show wlp2s0 | grep IP4.DNS
IP4.DNS[1]:                             1.1.1.1
IP4.DNS[2]:                             1.0.0.1
9
  • I also tried this, but it didn't help :-/ askubuntu.com/a/676398/652425 Jul 5, 2018 at 21:10
  • 1
    Can you try removing all mdns references from the hosts: line in /etc/nsswitch.conf? Jul 5, 2018 at 23:19
  • After changing hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname to hosts: hosts: files dns myhostname and restarting, things seem to be fixed. I'll test suspending and a few other things that seemed to cause problems before to confirm, but in the meantime, you may want to add that as an answer so I could award a bounty if continues to work correctly! Jul 7, 2018 at 16:42
  • Actually after a few minutes, it returned to the same behavior. Perhaps the fast behavior was just temporary after restarting Jul 7, 2018 at 17:39
  • Have you tried google dns server 8.8.8.8 and 8.8.4.4? From the dig response, are you using caching name server, named from bind9. I have similar setup but my forwarders using the google dns servers. Query from dig and firefox is fast (< 80ms) and often in the low twenties or zero. Jul 9, 2018 at 18:43

3 Answers 3

2

For me it was a timeout while waiting for an AAAA query (IPv6) to end before responding even though an A record was already resolved. The solution that worked for me is this.

add these lines to /etc/resolv.conf (the options is the secret sauce).

nameserver 1.1.1.1
nameserver 1.0.0.1
options single-request

on desktop systems it should be added to /etc/resolvconf/resolv.conf.d/base instead because /etc/resolv.conf gets rewritten automatically. then run these commands:

sudo resolvconf -u
sudo systemctl restart networking
sudo systemctl restart network-manager

solution from http://www.math.tamu.edu/~comech/tools/linux-slow-dns-lookup/

0

Included a screenshot of my Firefox dns settings that works well for me.

enter image description here

And if you want to try enabling local caching name server.

$ sudo apt-get install bind9 bind9utils bind9-doc
$ sudo vi /etc/bind/named.conf.options

And add the following under the option section.

    forwarders {
            8.8.8.8;
            8.8.4.4;
    };

And restart the bind service.

$ sudo systemctl restart bind9.service

It should do some pretty good caching with the default configurations.

$ dig www.disney.com

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> www.disney.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2237
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.disney.com.            IN  A

;; ANSWER SECTION:
www.disney.com.     300 IN  CNAME   matterhornsecure.edgekey.net.
matterhornsecure.edgekey.net. 7199 IN   CNAME   e13055.e12.akamaiedge.net.
e13055.e12.akamaiedge.net. 19   IN  A   2.19.151.249

;; Query time: 108 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Jul 09 12:48:28 PDT 2018
;; MSG SIZE  rcvd: 137

$ dig www.disney.com

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> www.disney.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 732
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.disney.com.            IN  A

;; ANSWER SECTION:
www.disney.com.     292 IN  CNAME   matterhornsecure.edgekey.net.
matterhornsecure.edgekey.net. 7192 IN   CNAME   e13055.e12.akamaiedge.net.
e13055.e12.akamaiedge.net. 12   IN  A   2.19.151.249

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Jul 09 12:48:35 PDT 2018
;; MSG SIZE  rcvd: 137

Note that the second query takes no time at all. It also takes no time to do dns query in Firefox for me too.

1
  • I had some differences in Firefox's about:config, but nothing significant. I tried setting it like yours, but no luck. I may try setting up this caching solution to help mitigate, but I feel like there is some problem here that is not being addressed Jul 10, 2018 at 11:56
0

Often it helps to check the contents of /etc/resolv.conf. Contrary to @MrBar in my case I had a few (basically correct) entries in it, but as soon as I removed those and redirected every query to the systemd-resolved daemon (with "nameserver 127.0.0.53"), Firefox and all other applications had no problem anymore.

You must log in to answer this question.

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