local doh with pihole

[tigernero79]

I'm trying to figure out how to implement local doh for use with pihole, at the moment pihole listens to dnsproxy on 127.0.0.1:54 and all is well.

how can I feed firefox to local doh knowing that all devices have dns pihole which then turns to dnsproxy?

also in the non hop wiki found the guide I saw in the toml file that must be enabled 127.0.0.1:3000 but then the path and certificates how to do it?

excuse my ignorance on the subject

[jedisct1]

See https://www.reddit.com/r/dnscrypt/comments/e36dsm/new_version_2034beta1_released/

[tigernero79]

if use cert_file = "localhost.pem"

how does path mean the / home of raspbian or does it mean the folder where dnscrypt-proxy is running?

furthermore the other PCs in the network as it should firefox call url

https://127.0.0.1:3000/dns-query

should they call pihole's ip?

example:

https://192.168.1.79:3000/dns-query

[jpgpi250]

I do have the same / similar question. I want to run dsncrypt-proxy as a local DOH server so browsers can use a DOH configuration. I want to be able to get to the following configuration:

normal DNS client (using system configured dns, port 53) -> pihole -> unbound recursive resolver DOH client -> dnscrypt-proxy DOH -> pihole (same instance as above) -> unbound recursive resolver

Is this even possible? I've read the reddit post, but couldn't determine the required toml settings to achieve this.

Sorry for my ignorance on this subject. Thank you for your time and effort. Thank you for your quick response to the CNAME problem.

[tigernero79]

I partly solved using:

listen_addresses = ['192.168.6.79:3000']

where 192.168.6.79 is my pihole's ip and in fact the other pc with firefox pointing to https://192.168.6.79:3000/dns-query

they see the self-signed certificate and url.

but should the path = /dns-query be created physically? or is it a symbolic path?

being in vpn there are problems? because I reach pihole with url as you see above but anyway the cloudflare site does not give me active "esni"

[tigernero79]

was and is a problem with the cloudflare test site.

because as they say they also go here:

https://www.cloudflare.com/cdn-cgi/trace

you will have to find the item sni=encrypted :

fl=39f84
h=www.cloudflare.com
ip=62.211.102.86
ts=1575026643.056
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
colo=MXP
http=http/2
loc=IT
tls=TLSv1.3
**sni=encrypted**
warp=off

and this is true so it works

[tigernero79]

@jedisct1

Why do I get this error when I point the firefox browser to my url?

[jedisct1]

The URL path is what is after the hostname in a URL. This is not a file. For example, if listen_address is 127.0.0.1:3000 and path is /dns, the URL will be https://127.0.0.1:3000/dns.

You can use whatever you want. /dns-query is just a common choice by convention.

In order to listen to all the IP addresses in listen_addresses, you can use 0.0.0.0 instead of 127.0.0.1, for example 0.0.0.0:3000.

I can't read what's on the screenshots on my phone.

[tigernero79]

@jedisct1 since I have to call up url from a pc on the net do I have to declare ip where the local doh is running, if I put 0.0.0.0:3000 that changes? however I have to put the pc's ip where it runs local doh in the other pc

 error that gives me on a pc with firefox is: TLS handshake error from 192.168.6.95:42422: write tcp 192.168.6.79:3000->192.168.6.95:42422: i/o timeout

nov 29 14:04:37 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:37] [NOTICE] Network connectivity detected
nov 29 14:04:37 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:37] [NOTICE] Source [public-resolvers] loaded
nov 29 14:04:38 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:38] [NOTICE] Source [relays] loaded
nov 29 14:04:38 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:38] [NOTICE] Anonymized DNS: routing [ibksturm] via [sdns://gRIxODUuOTQuMTkzLjIzNDo0NDM sdns://gRE1MS4xNS4xMDYuMTc2OjQ0Mw]
nov 29 14:04:38 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:38] [NOTICE] Anonymized DNS: routing [scaleway-fr] via [sdns://gRIxODUuOTQuMTkzLjIzNDo0NDM sdns://gRE1MS4xNS4xMDYuMTc2OjQ0Mw]
nov 29 14:04:38 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:38] [NOTICE] Anonymized DNS: routing [securedns] via [sdns://gRIxODUuOTQuMTkzLjIzNDo0NDM sdns://gRE1MS4xNS4xMDYuMTc2OjQ0Mw]
nov 29 14:04:38 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:38] [NOTICE] Firefox workaround initialized
nov 29 14:04:38 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:38] [NOTICE] Now listening to 127.0.0.1:54 [UDP]
nov 29 14:04:38 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:38] [NOTICE] Now listening to 127.0.0.1:54 [TCP]
nov 29 14:04:38 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:38] [NOTICE] Now listening to 192.168.6.79:3000 [DoH]
nov 29 14:04:48 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:48] [NOTICE] [scaleway-fr] OK (DNSCrypt) - rtt: 39ms
nov 29 14:04:53 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:53] [NOTICE] [securedns] OK (DNSCrypt) - rtt: 53ms
nov 29 14:04:55 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:55] [NOTICE] [cloudflare] OK (DoH) - rtt: 32ms
nov 29 14:04:55 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:55] [NOTICE] Sorted latencies:
nov 29 14:04:55 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:55] [NOTICE] -    32ms cloudflare
nov 29 14:04:55 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:55] [NOTICE] -    39ms scaleway-fr
nov 29 14:04:55 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:55] [NOTICE] -    53ms securedns
nov 29 14:04:55 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:55] [NOTICE] Server with the lowest initial latency: cloudflare (rtt: 32ms)
nov 29 14:04:55 PiVpnPiHole dnscrypt-proxy[4739]: [2019-11-29 14:04:55] [NOTICE] dnscrypt-proxy is ready - live servers: 3
nov 29 14:05:04 PiVpnPiHole dnscrypt-proxy[4739]: 2019/11/29 14:05:04 http: TLS handshake error from 192.168.6.95:42422: write tcp 192.168.6.79:3000->192.168.6.95:42422: i/o timeout
nov 29 14:05:05 PiVpnPiHole dnscrypt-proxy[4739]: 2019/11/29 14:05:05 http: TLS handshake error from 192.168.6.95:42412: write tcp 192.168.6.79:3000->192.168.6.95:42412: i/o timeout
nov 29 14:05:05 PiVpnPiHole dnscrypt-proxy[4739]: 2019/11/29 14:05:05 http: TLS handshake error from 192.168.6.95:42418: write tcp 192.168.6.79:3000->192.168.6.95:42418: i/o timeout
nov 29 14:05:05 PiVpnPiHole dnscrypt-proxy[4739]: 2019/11/29 14:05:05 http: TLS handshake error from 192.168.6.95:42420: write tcp 192.168.6.79:3000->192.168.6.95:42420: i/o timeout
nov 29 14:05:05 PiVpnPiHole dnscrypt-proxy[4739]: 2019/11/29 14:05:05 http: TLS handshake error from 192.168.6.95:42416: write tcp 192.168.6.79:3000->192.168.6.95:42416: i/o timeout
nov 29 14:05:05 PiVpnPiHole dnscrypt-proxy[4739]: 2019/11/29 14:05:05 http: TLS handshake error from 192.168.6.95:42414: write tcp 192.168.6.79:3000->192.168.6.95:42414: i/o timeout
nov 29 14:05:06 PiVpnPiHole dnscrypt-proxy[4739]: 2019/11/29 14:05:06 http: TLS handshake error from 192.168.6.95:42426: write tcp 192.168.6.79:3000->192.168.6.95:42426: i/o timeout
nov 29 14:05:06 PiVpnPiHole dnscrypt-proxy[4739]: 2019/11/29 14:05:06 http: TLS handshake error from 192.168.6.95:42434: write tcp 192.168.6.79:3000->192.168.6.95:42434: i/o timeout
nov 29 14:05:06 PiVpnPiHole dnscrypt-proxy[4739]: 2019/11/29 14:05:06 http: TLS handshake error from 192.168.6.95:42440: EOF

[jedisct1]

You can put 0.0.0.0 on the server, but on clients, you need to put the real IP address so that they know what host to connect to.

Thanks for copy/pasting the actual messages instead of a screenshot. In addition to being readable, now other people with the same issue can find your post (text in images is not indexed by the Github search engine).

These are just debug messages, you can safely ignore them. They won't be printed any more when 2.0.34 will not be in beta any more.

[sergeevabc]

@jedisct1, consider adding a passage to the wiki about accepting localhost.pem as a trusted certificate, which is done by opening https://127.0.0.1:3000/dns-query in the browser and clicking “Accept” button next to the error message like Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, otherwise Firefox won’t connect to local DoH and DNSCrypt logs will be full of messages like 2019/12/02 00:05:47 http: TLS handshake error from 127.0.0.1:65431: remote error: tls: bad certificate.

[jedisct1]

But... looks like this is already documented, isn't it? https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Local-DoH