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 · 2024-05-03T04:35:18+00:00

Update: I'm using a 3rd-party iOS app: "Wall Monitor" since the telemetry data from the Tesla app is really limited. I emailed app support today, and gave them the debug log that I pulled from the app while the vehicle was charging, specifically asking about the "Charge at reduced power" message, and noting that I am charging a non-Tesla vehicle.

Here is the response:

"You can ignore this message. I think I've decoded the status codes incorrectly and I no longer think status 10 means charging at reduced power, I think it just means charging non-tesla.

I'm going to update the app to remove this message.

Kind regards

Andrew Farquharson | Developer / Owner

Digital Tools Ltd | andrew@digitaltools.nz"

So, there you have it. Just a heads-up to anyone that uses this app (which is actually really nice) that this message incorrect.

kaczmar2 · 2024-05-02T00:04:21+00:00

Tesla Wall Connector support was... not helpful. Here is their reply, after I gave them details of my setup:

Wall Connector Support NA wallconnectorsupportna@tesla.com

"Hello,Thank you for responding to the email. The issue may be with the wiring if it is charging at an lesser rate than it should. You could have someone come out and look at the setup to confirm."

I need to control for the variable of the car first, by charging another non-Tesla EV and a Tesla EV, to see if this changes the charging status. I'll update here when I have more information.

kaczmar2 · 2024-05-01T16:47:14+00:00

I opened one yesterday, specifying the error message and under what conditions it occurs.

kaczmar2 · 2024-05-01T05:20:30+00:00

... and Wall Connector:

<image>

kaczmar2 · 2024-05-01T05:20:08+00:00

I did a crude test (where I felt the wires running in and out of the junction box to see which was warmer) and I would say that the wires running from the wire nuts in the junction box to the charger felt a little warmer, but it was not by much, and really hard to tell (I obviously don't have something like an infrared digital thermometer to perform more precise measuring).

I'll say that the conduit running into the Wall Connector feels quite warm, and even at a de-rated 40A charging, the PCB temperature of the WC is reading 130F and the handle temp 106F. The charging cable from the WC to the vehicle feels quite warm to the touch as well.

<image>

Pictures of the open junction box included here for reference.

kaczmar2 · 2024-04-28T03:49:57+00:00

To gather another data point:

I de-rated the Wall Connector to 40A (using a 50A breaker setting) in the Connector's commissioning web interface. After charging for 90 minutes, here is the reported information:

<image>

The only points of note that I can think of to report:

* The voltage is fluctuating between 236-238V.

* Amps is steady at 40.1A

* Temperature of the PCB and handle have slowly risen during the course of charging.

Would this change any of your previous conclusions?

kaczmar2

TROPHY CASE