Re: [Doh] DoH and PAC

Hi Guoye,

We had the same problem in Firefox, and our solution was the same [1].
Given the way PAC is used I think not using DoH makes sense.
We also had a similar deadlock with OCSP [2], where you need to wait for
the OCSP check for the DoH server's certificate, but that OCSP check also
needs to resolve DNS.

Cheers!

[1]
https://searchfox.org/mozilla-central/rev/3f9dcc016dd96a0336d46f4a19aeabdd796ab9e9/netwerk/base/ProxyAutoConfig.cpp#237-242
[2]
https://searchfox.org/mozilla-central/rev/3f9dcc016dd96a0336d46f4a19aeabdd796ab9e9/netwerk/protocol/http/HttpBaseChannel.cpp#488-494

On Mon, 5 Sept 2022 at 20:06, Guoye Zhang <guoye_zhang=
40apple.com@dmarc.ietf.org> wrote:

> Hi,
>
> Recently, we identified an issue that DNS over HTTPS (DoH) and Proxy
> Auto-Configuration (PAC) deadlock with each other.
>
> To briefly introduce what they are: As its name indicates, DoH is DNS
> queries over HTTPS; PAC is a JavaScript function where given a URL, it
> tells you whether we should go over a proxy or connect directly.
>
> The problem arises when both DoH and PAC are configured on the system. In
> order to fetch an HTTP resource, we first need to consult the PAC script.
> The PAC script is usually fetched from an HTTP URL and we are smart enough
> not to consult PAC script for itself. However, fetching the script does
> require DNS resolution which goes over DoH. DoH creates an HTTP connection
> and consults PAC and here is where it deadlocks. Another case is where PAC
> scripts can also manually initiate DNS resolution through JavaScript APIs
> like `dnsResolve()`.
>
> DoH depends on PAC and PAC depends on DoH. We have to break the chain
> somewhere, and the decision was to never use DoH in PAC: Fetching PAC
> script and JavaScript DNS APIs inside PAC always use cleartext DNS.
>
> Are there any other HTTP client implementations facing the same issue?
> What are your solutions?
>
> Thanks,
> Guoye Zhang
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>

Received on Tuesday, 6 September 2022 10:55:21 UTC