1592556 - PAC: dnsResolve() lags and unexpected behavior

Status: UNCONFIRMED

(Core :: Networking: DNS, defect, P2)

Description

[brook.qays]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36 OPR/63.0.3368.107

Steps to reproduce:

Affected versions 69.* - 70.0 (64-bit) for Windows. Other versions didn't check.

1. Block some tracking and advertising domains (ad.doubleclick.net and etc). By example, through Access Control Rule Management of SUITABLE router. It is IMPORTANT, there must be no ANY responses from DNS (check via Wireshark on port 53) for blocked domains to reproduce the bug. Maybe blocking domains via hosts file can be an alternative to the router (I didn't check it).
2. Enable proxy via PAC file containing dnsResolve() function.
3. Open page which contains ads, tracking or other content from blocked domains.

Actual results:

Even unproxed sites are loaded very slowly (loading take from 2x to 25x more time, depending on the number of requests). Reason: Function dnsResolve() calls for every domain. Resolving through dnsResolve() doesn't work the same way as resolving through a browser's engine. dnsResolve() slowing down browser's engine and content loading until timeout because function doesn't receive ANY responses from DNS for blocked domains. Also, dnsResolve() doesn't use DNS-over-HTTPS even if DoH enabled in settings.

Expected results:

dnsResolve() must work the same way as resolving through a browser's engine and not slow down content loading if DNS didn't send ANY responses for blocked domains. I think this is possible because on Webkit browsers the dnsResolve() function works without any visible lags even if doesn't receive ANY responses from DNS for blocked domains. Maybe Webkit doing resolving for dnsResolve() asynchronously or not via JS engine.

Comment 1

[brook.qays]

I made a mistake, by Webkit I mean browsers based on Blink.

Comment 2

[Dragana Damjanovic [:dragana]]

Which mode of DoH are you using, probably mode 2 thatt is falling back to native dns.

Comment 3

[brook.qays]

I have tested all modes (default and custom). Without proxy.pac all modes work fine (no packets on port 53 in Wireshark).

Comment 4

[brook.qays]

I didn't change the mode in about:config. It's a bug if Firefox falling back to native DNS when DoH-servers are available.

Comment 5

[Sébastien Dinot]

Hi,

It seems that I have the same issue with Firefox 68 on GNU/Linux (Debian Bullseye) :

• User agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
• Firefox version: 68.2.0esr
• Kernel version: Linux 5.2.0-3-amd64

If I choose the automatic configuration of the proxy through a proxy.pac file published by our proxy, the DNS resolution is awfully slow. It takes 10 or 20 seconds before the requested page is displayed.

If I choose the manual configuration of the proxy (host proxy.example.com, port 3128 for all protocols), the DNS resolution is instantaneous. The requested page is displayed without delay.

Here is the proxy.pac file:

function FindProxyForURL(url, host) {
	var mydest=dnsResolve(host);
        if (shExpMatch(host, "example.com")) {
                return "DIRECT";
	} else if (shExpMatch(host, "localhost")) {
		return "DIRECT";
        } else if (isInNet(mydest, "127.0.0.0",  "255.0.0.0")) {
                return "DIRECT";
        } else if (isInNet(mydest, "10.0.0.0",  "255.0.0.0")) {
                return "DIRECT";
        } else if (isInNet(mydest, "192.168.0.0",  "255.255.0.0")) {
                return "DIRECT";
        } else if (isInNet(mydest, "172.16.0.0",  "255.240.0.0")) {
                return "DIRECT";
        } else return "PROXY proxy.example.com:3128; DIRECT";
}

Comment 6

[Sébastien Dinot]

(In reply to Sébastien Dinot from comment #5)

It seems that I have the same issue with Firefox 68 on GNU/Linux

I resolved the issue by changing the "Content blocking" settings in the "Privacy and security" section, switching from "Custom" (with all options enabled) to "Standard".

Now, even with the automatic proxy configuration and all filtering extensions enabled (Privacy Badger, uBlock Origin and NoScript), the requested pages are quickly displayed.

Sébastien

Comment 7

[Valentin Gosu [:valentin] (he/him)]

Hi,

Are you still seeing this bug? Could you check in the latest Firefox nightly if possible?