Firefox really slow since switching to DoT

1

Hi,

following environment:

  • IPFire 2.25 - Core Update 141 with webproxy/DoT activated, several DoT-server are listed and used (i.e. kaitain.restena.lu, sinodun.com, digitalcourage.de, switch.ch, unicast.censurfridns.dk etc.) and all checked as ok, responce-times of the dns-servers are from 15ms to 900ms (checked with uemegges dot-check-script; i guess ipfire is using the fastest?)
  • Windows Domain Network with 2x Windows-DNS-Server, both forwarding to IPFire. Resolver-part of windows-dns-server is activated for dnssec-validating (is this necessary, when ipfire is also dnssec-validating? and i guess, with wpad/proxy activated, http-clients are using ipfire/webproxy for dns-resolving?).
  • Clients are using IPFire-webproxy by wpad.dat-offering in dhcp and dns. Dns-servers used in clients are both mentioned windows-dns-servers (although they should be only used for non-proxy-traffic). In firefox doh is deactivated by enterprise-policy.

Problem: Since i installed core update 141 and switched on DoT, firefox is painfully slow with a lot of website, when loading first time (or after some time passing by, perhaps some dns-cache gets deleted?). With google chrome or firefox with deactivated proxy everything is fine. It looks like, if some initial dns-resolving takes really long. But i couldn’t figure out, why chrome doesn’t have that problem. Looks really strange. I don’t think, that the mentioned windows-dns-server-resolving is relevant for webbrowsers when using proxy/wpad. I only mention this here for completion.

Someone experiencing similar behavior with firefox+webproxy+dot? Thx 4 help.

2

Kick off all DNS servers with a latency higher than 100ms. I have no performance issues with firefox + proxy + DoT. Also I don’t understand why your clienst use the DNS of your domain controllers/servers. Hosts config with ipfire and all hostnames will be resolved. But however if your servers have no performance issues with the internet connections it’s not up to that -> check it (actually they must have the same issue since they need to use the ipfire DNS for the internet. There are a few things you can check to find the bottleneck with changing settings for a test client in your network. Try direct DNS nor your servers or ipfires DNS servers. Deactivate TLS and try again. Cut down your DNS servers list. Did you even trace the clients connections?

3

I activated only the 2 fastest dns-server (25ms and 46ms) but somehow it makes no difference to me. Perhaps ipfire is already using the fastest servers in the list (as stated in patchnotes). After that i switched back to UDP and now webbrowsing-speed with firefox and activated proxy is back to normal. And i have to correct me: In Chrome there is also a slowdown with dot+proxy, but that is not so intense (perhaps Chrome has some mitigation against slow connections?).

4

unbound is at the moment not able to reuse a existing tls connection.

5

Thx 4 hint, arne. I think that is the answer, cause the pages with extense slowdowns has a lot of external domains/sources. So i can only hope, that unbound gets an upgrade regarding tls-connection establishment.

Edit: But why ist that problem so intense, only when using webproxy? If i disable proxy in firefox, firefox should now use dns-servers in windows-client-configuration, which are 2 windows-dns-servers (cause of windows domain), for dns-resolving. And those windows-dns-servers are only forwarding dns-requests, which answer they don’t know, to ipfire. And this is faster, although there is one more “dns-resolving-hop”.

6

There should be no difference here because the DNS lookups are all the same. This might slightly improve with Core Update 142, because we have made some further improvements, but ultimately unbound needs to implement re-using existing TLS connections and not opening a new one for each query. That adds a lot of overhead and therefore you have those slow responses.

7

I figured out, what causes slowness in Firefox in conjunction with Dot + Webproxy (used through wpad auto config): IPFire is creating the wpad.dat file for you, when saving settings in webproxy. But, ipfire is generating some entries with using the function “isInNet()”.

According to Mozilla’s docs regarding pac-/wpad-files, using “isInNet()” is slow, cause of the additional DNS-queries: Proxy Auto-Configuration (PAC) file - HTTP | MDN

Usage of isInNet(), isResolvable() and dnsResolve() functions should be carefully considered, as they require the DNS server to be consulted. All the other autoconfig-related functions are mere string-matching functions that don’t require the use of a DNS server. If a proxy is used, the proxy will perform its DNS lookup which would double the impact on the DNS server. Most of the time these functions are not necessary to achieve the desired result.

And now this makes sense, why this issue is more pronounced, when using DoT.

And the solutions for Firefox, that are working for me (and to keep DoT enabled):

either

  • kill all isInNet()-entries in wpad-file manually (will be overwritten by Webproxy-Interface on saving settings) and find other solutions/functions, to distinguish targets and sources for direct- and proxy-access. These isInNet()-entries will be created, the more subnets (inkl. vpns) you have and the more subnet-exclusions in webproxy are defined.

or

  • don’t use automatic proxy-configuration in Firefox. Put in proxy-server, port and exclude-list manually (or by local-settings.js-Script).

I have to add, that in Google Chrome the problem is way less with that created wpad-file from ipfire. Perhaps Chrome has some tricks to minimize the dns-querries produced by isInNet()-entries or is caching answers more efficiently. Idk, I did not deep dive into it. So i don’t want to blame developers to much. Everything else is working fine here, so great job @all :>.

Edit: Ok, Microsoft is explaining a better solution and it works good: Slow browsing in Internet Explorer - Browsers | Microsoft Learn

And i think, this is, what Google Chrome is doing on its own. It is minimizing the amount of dns-querries by optimizing wpad-configuration or caching dns-answers for it, which Firefox doesn’t.

Perhaps some devs could consider this solution, to minimize dns-querries with proxy-wpad-/pac-file-using with some more subnets and subnet-exclusions (e.g. i got 8 IsInNet-Entries in my wpad-file)?

Edit2: Ok, solution from microsoft is a little bit better, but not as good, as manually putting in proxy-settings into Firefox. So, there’s still a performance-hit. Meanwhile i think, the problem is more related to Firefox, than ipfire. Perhaps Firefox is misbehaving whith use of several isInNet()-entries, perhaps it is all doing correctly (but unoptimized) and Google Chrome is misbehaving (but optimized).

8

Just wondering what version(s) of Firefox?
Would also be interesting to know if new Windows Edge-Chrome is slow too.

9

I only tested standard versions and 64bit. But i don’t think it makes a difference if you are using 32bit or ESR-version. I didn’t tested very old builds. You always get a performance hit when using a proxy (either manual or per wpad), but with DoT enabled the performance hit when distributing proxy-settings per wpad is a pain in the a… in Firefox.

There also seems to be bug in proxy-settings of Firefox in Windows. If you set proxy to “use system proxy-settings” and system-proxy is set to “automatic” (as for wpad-autodetection), IE, Edge, Chrome are using automatic settings just fine, but firefox is still making direct connections. You have to set proxy to “detect proxy-settings for this network automatically” for wpad-autodetection to work correctly in Firefox. But that’s a different story…

10

Just want to add: Core 154 is hell of speed improvement for webproxy + dot users. Great work all! Now everything is really snappy and fast, almost like without webproxy/dot.

1 Like