Closed Bug 1516692 Opened 6 years ago Closed 6 years ago

Web pages load very slowly when DNS over HTTPS is disabled

Categories

(Core :: Networking: DNS, defect)

64 Branch
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: ari.torhamo, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0 Steps to reproduce: Clicked on links on different search engines to open web pages, using a system with freshly installed Linux Mint 19.1 Cinnamon. Actual results: Web pages opened very slowly, mostly in 8 seconds or more. None of the usually suggested ways to speed up Firefox helped. However, changing the setting "DNS over HTTPS" from disabled to enabled changed the page loading speed to normal. I tested this back and forth several times, and the behaviour was always the same. Expected results: Freshly installed Firefox with default settings should load web pages much faster, on my current hardware usually between one and two seconds.
DNS over https is disabled by default in Firefox64 (network.trr.mode=0). It looks like there is a DNS resolver problem on your system/network if enabling it makes website loading faster.
Component: Untriaged → Networking: DNS
Product: Firefox → Core
I forgot to ask: Other applications on your sxystem do not have problems with the DNS ?
I guess your first nameserver is not working properly, which would explain why the pages are loaded very slow but in the end successfully. Please check all your nameservers, e.g. with "dig" tool. If you're sure they work correctly, please provide HTTP log, see https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Flags: needinfo?(ari.torhamo)
Sorry, I forgot to mention that Chromium works normally, and so does Firefox on Windows without changing network settings.
Flags: needinfo?(ari.torhamo)
Here is what I got from dig (I have never used the tool – is this what you need?): <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65113 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 498706 IN NS j.root-servers.net. . 498706 IN NS a.root-servers.net. . 498706 IN NS l.root-servers.net. . 498706 IN NS b.root-servers.net. . 498706 IN NS g.root-servers.net. . 498706 IN NS k.root-servers.net. . 498706 IN NS c.root-servers.net. . 498706 IN NS m.root-servers.net. . 498706 IN NS h.root-servers.net. . 498706 IN NS f.root-servers.net. . 498706 IN NS e.root-servers.net. . 498706 IN NS d.root-servers.net. . 498706 IN NS i.root-servers.net. ;; Query time: 13 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Sat Dec 29 15:13:48 EET 2018 ;; MSG SIZE rcvd: 239
From the output above it seems that your system is using systemd-resolved. Check content of /etc/resolv.conf file. In this case you'll find the real name servers using following command: $ systemd-resolve --status Then you can check all DNS servers by running dig some.domain.com @ip.of.dns.server, e.g. $ dig www.mozilla.com @8.8.8.8 You may want to try multiple different searches to avoid getting results from the DNS's cache. Name resolution can be also affected by settings in /etc/nsswitch.conf, check line beginning with "hosts:"
Flags: needinfo?(ari.torhamo)

Resolving this incomplete. Please reopen if you have more information!

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE

Sorry for the long delay in answering, Michal. I'm not sure if I understand the steps I should take right. The command "$ systemd-resolve --status" produces the following results:

..........

Global
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 2 (enp4s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.1.1
DNS Domain: Home

..........

When I use the dig command as you suggest, all addresses give me a result similar to this:

dig www.mozilla.com @168.192.in-addr.arpa
dig: couldn't get address for '168.192.in-addr.arpa': not found

The only exeption is "$ dig www.mozilla.com @192.168.1.1", which gives the following result:

..........

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> www.mozilla.com @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64618
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.mozilla.com. 60 IN CNAME redirects.public.mdc1.mozilla.com.
redirects.public.mdc1.mozilla.com. 663 IN A 63.245.208.212

;; Query time: 37 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Jun 04 20:35:35 EEST 2019
;; MSG SIZE rcvd: 96

..........

Here's the line beginning with "hosts" in /etc/nsswitch.conf:

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname

Flags: needinfo?(ari.torhamo)

After re-installing Linux Mint (the same version), I'm not able to reproduce this bug anymore. I'm using the same DNS and other network settings as before (or to be more precise: the other network settings have been in their default states on both installations), but now web pages load at good speed both with "DNS over HTTPS" enabled and disabled.

You need to log in before you can comment on or make changes to this bug.