Manage DNS across many Pihole servers

I'm working on a tool to allow me to manage Custom DNS across many Pihole servers. The idea is to be able to keep them in-sync whilst also allowing some to have different DNS. I'm probably about three or four weeks away from a working version. Is anyone interested in beta testing this.

Will be Web/gui based so will probably release as docker container to make deployment simple.

Not a commercial product - just for the community and to give me something to do... At this stage I'm trying to work out if others want this too or just me?

Sounds interesting.
I'm willing to test :wink:

Great - I'll post on here when I have something... Thanks.

Keep in mind that v6 is already in beta!

Its an almost complete overhaul and some things working for v5 are completely different now for v6.
Below is popular for v5:

Thanks. Good points I hadn't considered. I have taken a look at the V6 API which seems like a great improvement generally over the V5 API, but I don't see any custom DNS management endpoints so will have to keep a watching brief. I can probably add code to allow me to manage both V5 and V6 endpoints (once I have the V6 API) from the same tool.

Taking that a stage further there is no reason why I couldn't extend what I'm doing to cover non-pihole DNS systems also.

The Gravity sync is interesting but I'm not sure it gives me what I need, which is to manage several (potentially a lot) of piholes in a flexible way (allowing some to have different DNS).

I have made some progress over this weekend. I can now identify the changes needed on each managed or semi-managed pihole to bring it into sync with the main DNS database. I'm on track to have something ready at least by Christmas given work commitments.

1 Like
dehakkelaar@ph6b:~$ curl -s localhost/api/config/dns/hosts | jq .config.dns.hosts[]
"10.0.0.3 nas.home.dehakkelaar.nl"
"10.0.0.2 ph5a.home.dehakkelaar.nl"
"10.0.0.4 ph5b.home.dehakkelaar.nl"
"10.0.0.5 ph6b.home.dehakkelaar.nl"
"10.0.0.1 router.home.dehakkelaar.nl"
"10.0.0.6 xen02.home.dehakkelaar.nl"

EDIT:

dehakkelaar@ph6b:~$ pihole-FTL --config
[..]
dns.hosts = []
[..]
dns.cnameRecords = []

Add one with a --request PUT and remove one with --request DELETE.

OK, I stand corrected - Didn't see the Documentation for that endpoint. I think I'll stay focused on the existing API for now. I can always add the V6 stuff in later. I'm hoping to get a beta out before the second week of December as I have a long business trip and won't be able to work on it for at lest two weeks after that.

Well, here it is. This is at best beta level. It works for me (cold comfort I know). But some of you did say you'd test.

docker hub image

You will need a mysql database - I had to store the DNS records somewhere. I'll try to get some documentation written for it but it is actually pretty simple. The docker repository has instructions on how to run it. If you get past the database configuration piece you should be golden!

Keen for feedback.

Thanks.

The common sense approach, at first glance, would be for the PiHole developers to implement MySQL capability for the gravity database.... I've seen it suggested before, but only from a performance perspective.... which honestly the performance gain would be minimal, so I can understand why they disregarded the feature request.... but I'd think the REAL benefit of implementing optional MySQL support is for this exact thing.... keeping multiple piholes in sync.... If we use a MySQL gravity database, then the primary instance can update the database, and all the other instances use that same MySQL database, and so one database update updates all... no more of these kludgy sync gyrations.... just one database shared by all instances on the network.

But see above, I have created a docker app with Mysql as the back-end to handle this. It has the advantage that you can set a Pihole to fully managed where we keep it in sync with the database or partially managed where we send it DNS entries it doesn't have but don't change ones it already has. Looking for feedback on the app.

I did it this way because I have an extensive homely and want things in the homely to access facilities in my main-network without having the homely specific things - which I tend to create with Terraform, polite my home network, particularly where I'm building a replacement server or something and want it to have the same FQDN as already exists in the broader network.