1592248 - dnsResolve inside PAC-scripts ignores DNS over HTTPS and uses system DNS instead

Status: RESOLVED INVALID

(Core :: Networking: DNS, defect)

Description

[ilyaigpetrov]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36

Steps to reproduce:

1. In Firefox network settings set PAC-script to proxy.pac file with content:

'use strict';

function FindProxyForURL() {

  var ip = dnsResolve('this-domain-doesnt-exist-for-sure.com');
  // Port 9 discards packets, see https://en.wikipedia.org/wiki/Discard_Protocol.
  return 'SOCKS5 127.0.0.1:9';
}

2. In the network settings of FireFox tick “Enable DNS over HTTPS” and "Proxy DNS when using SOCKS v5".
3. Close all tabs except an empty one.
4. Launch WireShark, start listening.
5. Input http://127.0.0.1 in the address bar, press "enter".

Actual results:

In WireShark you see packets to port 53 about this-domain-doesnt-exist-for-sure.com to dns server inside your internal network (mine is 192.168.1.x).

Expected results:

In WireShark you should see no packets to port 53 but see packets to 1.1.1.1 (1.0.0.1) or other DNS over HTTPS server.

Comment 1

[ilyaigpetrov]

Attachment: proxy.pac

Comment 2

[ilyaigpetrov]

On about:config I set:

• network.trr.bootstrapAddress to 1.1.1.1
• network.trr.mode to 3 (see https://wiki.mozilla.org/Trusted_Recursive_Resolver#network.trr.mode)

Fact: After that there is no more requests on port 53 but I also don't see any requests to ips of mozilla.cloudflare-dns.com (104.16.24*.249).
Expected: TCP requests to 104.16.24*.249 or 1.1.1.1 or 1.0.0.1.

Comment 3

[Dragana Damjanovic [:dragana]]

Trr connection may be going through a proxy.

Comment 4

[ilyaigpetrov]

But at the moment of calling dnsResolve proxy is yet not known!
It will be known when FindProxyForURL returns a proxy.
Can we reopen the ticket if I'm right?

Comment 5

[Dragana Damjanovic [:dragana]]

Valentin, can you take a look?

Comment 6

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

So I set network.trr.mode=3, the pac file to the contents supplied in comment 0, a boostrap address, and restarted the browser so we start with an empty DNS cache.
The logs seem to indicate the following:

We get a request for example.com -> PAC script -> resolve this-domain-doesnt-exist-for-sure.com using TRR -> tries connection to DoH server -> we use the PAC script for the DoH connection -> adds callback for when this-domain-doesnt-exist-for-sure.com is resolved.
The TRR channel eventually times out, so we put a negative DNS record for this-domain-doesnt-exist-for-sure.com in the cache. example.com fails to resolve because the TRR channel failed.
We then try to resolve another domain - test.com. Following TRR resolutions will attempt to connect, do the resolution for this-domain-doesnt-exist-for-sure.com which is resolved from the cache, and wind up using the proxy which drops packets.
the resolution for test.com and any following domains fails with 0x804B0048 - NS_ERROR_PROXY_CONNECTION_REFUSED

The only difference for mode=2 is that when the TRR channel fails we fallback to regular DNS, which shows up in wireshark.
I think we can keep the bug closed.