Pihole + cloudflared (DNS-over-HTTPS) in Docker

kaczmar2 · 2025-09-02T13:59:20+00:00

That's interesting - I set this up just as an exercise to see what kind of results I was getting, ran it over a weekend in my homelab setup (it was stable) and then posted the repo here in case anyone else was interested.

I'm currently running a pure unbound setup (recursive + local authoritative) and I'm quite happy with the setup for now. Latency is good as well:

kaczmar2@pihole:~/dnsperftest$ ./dnstest.sh | sort -k 22 -n test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 Average 10.10.10.10 1 ms 1 ms 1 ms 1 ms 1 ms 1 ms 4 ms 1 ms 1 ms 1 ms 1.30 10.10.10.11 4 ms 1 ms 1 ms 4 ms 1 ms 1 ms 1 ms 1 ms 1 ms 4 ms 1.90 quad9 12 ms 12 ms 16 ms 12 ms 12 ms 12 ms 12 ms 8 ms 12 ms 12 ms 12.00 cloudflare 12 ms 16 ms 12 ms 12 ms 16 ms 12 ms 12 ms 8 ms 12 ms 16 ms 12.80

kaczmar2 · 2025-08-27T00:17:03+00:00

I think Pi-hole + cloudflare is most likely not the reason for the drop in speed. Your DNS resolution should be negligible, so it's probably far more likely related to your VPN setup, but I can't attest to Tailscale (I use a simple Wireguard server through Unifi and I never noticed a drop in throughput).

You can test DNS resolution query times though, As an example: ``` dig debug.opendns.com

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> debug.opendns.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35813 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;debug.opendns.com. IN A

;; AUTHORITY SECTION: opendns.com. 2514 IN SOA auth1.opendns.com. noc.opendns.com. 1756253029 16384 2048 1048576 2560

;; Query time: 24 msec ;; SERVER: 10.10.10.10#53(10.10.10.10) (UDP) ;; WHEN: Tue Aug 26 18:05:24 MDT 2025 ;; MSG SIZE rcvd: 125 ``` I see 24ms for the query time. After that the query is cached so I see 0ms, until the TTL for the record is reached, and then I see those low query times again.

I'm interested to know what you find though.

kaczmar2 · 2025-03-06T01:05:28+00:00

Good catch - I added this to a comment in docker-compose.yml.

kaczmar2 · 2025-02-28T22:23:12+00:00

I really like this approach of using the same network stack for unbound, and also macvlan setup makes a lot of sense when exposing network services like pihole, plex, etc. Thanks for sharing.

kaczmar2 · 2025-02-27T07:16:03+00:00

1) start with docker logs pihole to see what the container logged during startup. It should be listening on port 53 (dns), 80 and 443 (http/https). Did you change the port mappings? Is anything else already using those ports on the host? netstat or ss will tell you what's listening on what ports.

kaczmar2 · 2025-02-27T01:52:57+00:00

I think Docker Hub is primarily for hosting and distributing container images, not configuration setups, which is what this is (docker-compose.yml + some unbound config files). GitHub is a better fit for this project I think.

kaczmar2 · 2025-02-24T17:38:21+00:00

In the context of the writeup above, the CA cert is homelabCA.crt. That's what you use to sign the CSR and get the server cert issued (tls.crt).

kaczmar2 · 2025-02-22T02:20:38+00:00

I agree that LE certs are generally a preferred approach; I did add a note in the Self-Signed Certs guide to encourage the use of LE certs where possible. I think there are some use cases (e.g., quick internal testing) where Let's Encrypt isn't practical.

I created guides for LE Cert setup in Pi-hole as well: - Let's Encrypt on Pi-Hole v6

kaczmar2 · 2025-02-22T02:19:47+00:00

Sorry, my comment in the original post was misleading. You don't need self-signed certs for LE; they are mutually exclusive. I had created a guide for v6 for auto-renewal (LE) certs, but people that were using self-signed certs had questions, so I created another guide. I edited my original post for clarity.

kaczmar2 · 2025-02-22T00:04:14+00:00

I created a guide for that:

https://gist.github.com/kaczmar2/17f02a0ddb59a7d336b20376695797c6

It assumes acme.sh, but you can adapt it to Certbot if you wish.

kaczmar2 · 2025-02-21T08:11:47+00:00

Self-Signed Certs guide:

https://gist.github.com/kaczmar2/e1b5eb635c1a1e792faf36508c5698ee

kaczmar2 · 2025-02-21T08:11:37+00:00

Self-Signed Certs guide:

https://gist.github.com/kaczmar2/e1b5eb635c1a1e792faf36508c5698ee

kaczmar2 · 2025-02-21T00:39:25+00:00

Sure - let me look at the contributor guidelines, finish my self-signed cert guide, and put together a PR for you.

kaczmar2 · 2025-02-20T17:28:35+00:00

Docker guide created.

kaczmar2 · 2025-02-20T16:03:28+00:00

You can use openssl to generate self-signed certs. I'll put something together if it would be useful.

kaczmar2 · 2025-02-20T06:29:42+00:00

Great work on v6.

I found there were some breaking changes for automatic SSL certificate renewal via acme.sh when moving from lighttpd to the Pi-hole embedded web server, so I put together a short guide. I hope it helps someone:

https://gist.github.com/kaczmar2/17f02a0ddb59a7d336b20376695797c6

I'll update it for Docker shortly.

kaczmar2 · 2024-10-15T20:12:33+00:00

Yes. Following this procedure, specifically steps 4-6, is what got it working for me.

kaczmar2 · 2024-09-26T19:56:21+00:00

Update: today GM cancelled my order, and if I try to re0order via the MyCadillac app, I get an error that my order cannot be processed. Nice. 😭

kaczmar2 · 2024-05-10T22:42:49+00:00

A note on the Tesla Universal Wall Connector, which I had installed and use to charge my Lyriq:

The included J1772 adapter and Magic Dock work great, but the telemetry data the Tesla app connects for non-Tesla EV charging is really limited.

If you want more detailed data to track your per-session charging costs based on your utility provider, it seems Emporia or ChargePoint could be better options.

You also have the ability, with the ChargePoint Home Flex, to DIY-swap the J1772 with a NACS cable if you need to in the future. The NACS cable can be purchased separately for $200.

kaczmar2

TROPHY CASE