Forward rules send forwarded queries as HTTPS - can they be forwarded as A?

[chrisbenincasa]

Per the documentation, I was under the impression that forwarding rule "exceptions" would be sent as non-DoH requests (i.e. A or AAAA) to the configured address:

While all the DNS traffic is usually meant to be sent to secure channels, you can add "exceptions" that will be sent, unencrypted, as regular DNS queries, to specific hosts.

However, I'm seeing behavior where dnscrypt-proxy is forwarding these configured requests back as DoH requests.

My setup uses a pihole with dnscrypt-proxy configured as the upstream server. The proxy is configured to forward a subset of internal domains, lets call it apps.our.house back the pihole, for proper resolution. The pihole has configurations to direct certain wildcard subdomains to a reverse proxy.

My proxy forwarding rules are simple:

apps.our.house 10.5.0.5

I would assume that the flow would be a DoH request hits the PiHole, gets forwarded to dnscrypt, dnscrypt then forwards this unencrypted request back to the PiHole for proper, old-school resolution. Am I misunderstanding "unencrypted" here?

What I see is:
PiHole:

Sep 29 16:06:27 dnsmasq[267]: forwarded test.apps.our.house to 10.5.0.6#5053
Sep 29 16:06:27 dnsmasq[267]: query[HTTPS] test.apps.our.house from 10.5.0.6
Sep 29 16:06:27 dnsmasq[267]: forwarded test.apps.our.house to 10.5.0.6#5053
Sep 29 16:06:27 dnsmasq[267]: query[HTTPS] test.apps.our.house from 10.5.0.6
Sep 29 16:06:27 dnsmasq[267]: forwarded test.apps.our.house to 10.5.0.6#5053
Sep 29 16:06:27 dnsmasq[267]: query[HTTPS] test.apps.our.house from 10.5.0.6
Sep 29 16:06:27 dnsmasq[267]: forwarded test.apps.our.house to 10.5.0.6#5053
Sep 29 16:06:27 dnsmasq[267]: query[HTTPS] test.apps.our.house from 10.5.0.6

proxy:

[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 27ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 23ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 42ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 30ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 46ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 31ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 41ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 48ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 28ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 70ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 80ms    10.5.0.5:53
[2023-09-29 20:06:27]   10.5.0.5        test.apps.our.house        HTTPS   FORWARD 44ms    10.5.0.5:53

This gets caught in a loop until the max concurrency is reached.

[lifenjoiner]

I would say:

1. 'I was under the impression that forwarding rule "exceptions" would be sent as non-DoH requests' is correct.
2. But, in 'query[HTTPS] test.apps.our.house from 10.5.0.6', HTTPS is the DNS record type which is adopted for http3, but not the protocol the query is over.
3. Forward rules make forwarding all types of (unblocked) records to plain DNS.
4. You shouldn't config the 2 forwarding as a circle. Local domains should be resolved at PiHole, without forwarding, or forwarded to where they are mapped.

[chrisbenincasa]

Thanks for the reply. The issue I'm facing is that (as far as I know) there is no way to properly handle DoH at the pihole/dnsmasq level, because it simply does not support it. In fact, the lack of support there is what led me down the road to using the proxy in the first place; DoH requests from mobile devices on my LAN were being forwarded upstream.

I agree that looping back to the original resolver is not ideal, but in theory it should work if the proxy were forwarding requests in a way that wouldnt be interpreted as DoH by the receiver.

For now, duplicating my internal DNS rule with a cloak rule works, but it means I have to duplicate the entry across two services in order to properly handle A/AAAA/HTTPS record types.

[chrisbenincasa]

Rereading...I think I'm understanding a bit more now. Forwarding aside, it seems like my only recourse is to use the proxy + a cloak rule in order to properly answer the HTTPS type queries coming from the mobile devices, since there doesn't really seem to be a way to define those record types on the pihole/dnsmasq

[lifenjoiner]

It is a bit tricky.

For the records:

Sep 29 16:06:27 dnsmasq[267]: forwarded test.apps.our.house to 10.5.0.6#5053
Sep 29 16:06:27 dnsmasq[267]: query[HTTPS] test.apps.our.house from 10.5.0.6

I think they are plain queries, understood by your PiHole. They are on port 53. And you must not config any HTTPS answers for the local domains, I guess. So just block them, or response with a dummy answer, depending on the PiHole capability. Just don't forward them to dnscrypt-proxy, it won't have the the answer.

For the DoH queries, they must be on a different port. If the PiHole can't parse them, forward them to dnscrypt-proxy, and then they are forwarded back to the PiHole's port 53. So, they will be solved without forwarding further.

Am I right, or missed anything?