I'm probably late to the party but...
I use pihole dns in v5 also for acme dns challenges (TXT-records).
I add dns challenges on the fly to /etc/dnsmasq.d and then restartdns .
It's not an option to restart the whole container all the time - as this stops all dns requests for a long time.
I also have processes to update the IP of a machine (eg based on location: Home vs.VPN)
Any way to fix this in v6?
Thank you!
Is there an API solution to this nowadays in v6
There might be, I havent seen it yet. Running into additional problems as some parts of the API are undocumented.
The entire API documentation exists on your Pi-hole install already.
For version 6 yes. 
So, this should be doable.
This is in the version 6 category.
Yep! My original post as referenced by the poster was for v5 - apparently setting .txt records was not possible.
Unfortunately the api command /api/action/restartdns restarts the whole webserver (incl. dnsmasq). This renders the service unresponsive for seconds (not as long as a container restart but notably).
The two commands
pihole reloaddns or
pihole reloadlists
do not reread /etc/dnsmasq.d/-files.
Once enabled with FTLCONF_misc_etc_dnsmasq_d="true" this should be handled somewhere.
Anyway this is not a very nice and easy change in v6
If you add your changes to misc.dnsmasq_lines (instead of enabling misc.etc_dnsmasq_d), Pi-hole will reload the configuration automatically.
I saw that, however I did not get this to work from a docker-compose env var.
Seems to have trouble to double encode list items.
Can i just enter items one per line?
Plus it would probably overwrite changes to pihole .toml on the next restart, wouldn't it?
Can I set single items on the command line?
And if so, would you have examples?
Currently I use /etc/dnsmasq.d for cnames, custom IPs that need to update from shell scripts, plus the TXT records for acme dns validations.
CNAMES and IPs are really a pain, as they will no longer reflect in the UI - plus duplicates in file and UI will lead to complete failure of pihole to start DNS.
BTW: updates of IPs through the API are really painful, as the "key" is IP and not the name. So you first have to DELETE the old entry with the old IP (that may not be available anymore) and then PUT the new one.
I may have created a few unusual use cases in v5, but that makes this upgrade especially hard.
Example usage from the compose file:
environment:
FTLCONF_misc_dnsmasq_lines: |
server=/61.10.in-addr.arpa./127.0.0.1#953
server=/example.invalid./127.0.0.1#953
server=/else.invalid./127.0.0.1#953
server=/domain.invalid./127.0.0.1#95
Once a config item is set via the environment variable it becomes read only, effectively locking it and ensuring a single source of truth.
Thank you @PromoFaux.
I still see the problem with dynamically added TXT dnsmasq entries for acme verification.
How can I enter them without the UI? Putting them into /etc/dnsmasq.d will need a complete restart, API is not available, cli does not seem to be available either.
Any suggestion?
My preferred solution would be a quicker reload option (like with the service restart in v5).
Would it be feasible to add the reload of /etc/dnsmasq.d to one of
pihole reloaddns
pihole reloadlists
if the option is used...
Thanks for thinking about it.
Reloading config files always needs a full restart of dnsmasq. This was the case with v5 as well. There is no need to restart the whole system, restarting pihole-FTL alone is sufficient. This is also possible through the API, via the CLI, the web interface, ...
And how would that work from cli with the docker container? I would need a scriptable solution (like in v5).
Sending a 'kill -<?>' to pihole-FTL? 'kill -HUP' kills the whole container.
API restartDNS takes almost 2mins and during this time 'pihole status' returns all OK but dns queries fail 
What kind of environment are you running Pi-hole in that you can't wait for this period of time?
If your're running Pi-hole in a container and need zero downtime, you can setup something like traefik and spin up multiple containers with a fail-over logic.
I'm running on docker and have even keepalived to get HA. However adding a TXT-record for acme.sh needs two minutes to add and two minutes to remove. And that is not on the second instance!
That's quite some time and it's never for granted that the CA will wait for that amount of time - and timeout.
I'm not sure why this needs so much more time to cycle just to reload of the dnsmasq-conf-files.
If I'm reading the logs correctly it starts completely new: reconfiguring, writing pihole.toml, initializing db, Import on-disk DB, parsing queries in DB (over 500000!), restart webservice.
Why?
2025-03-08 18:02:52.739 CET [48M] INFO: ########## FTL started on pi-hole! ##########
2025-03-08 18:02:52.739 CET [48M] INFO: FTL branch: master
2025-03-08 18:02:52.739 CET [48M] INFO: FTL version: v6.0.4
2025-03-08 18:02:52.740 CET [48M] INFO: FTL commit: b7eb53bf
2025-03-08 18:02:52.740 CET [48M] INFO: FTL date: 2025-03-04 17:22:10 +0000
2025-03-08 18:02:52.740 CET [48M] INFO: FTL user: pihole
2025-03-08 18:02:52.740 CET [48M] INFO: Compiled for linux/arm/v7 (compiled on CI) using cc (Alpine 14.2.0) 14.2.0
2025-03-08 18:02:53.653 CET [48M] INFO: 11 FTLCONF environment variables found (11 used, 0 invalid, 0 ignored)
2025-03-08 18:02:53.653 CET [48M] INFO: [✓] FTLCONF_dns_expandHosts is used
2025-03-08 18:02:53.653 CET [48M] INFO: [✓] FTLCONF_dns_listeningMode is used
2025-03-08 18:02:53.653 CET [48M] INFO: [✓] FTLCONF_ntp_ipv4_active is used
2025-03-08 18:02:53.654 CET [48M] INFO: [✓] FTLCONF_misc_etc_dnsmasq_d is used
2025-03-08 18:02:53.654 CET [48M] INFO: [✓] FTLCONF_ntp_ipv6_active is used
2025-03-08 18:02:53.654 CET [48M] INFO: [✓] FTLCONF_dns_domain is used
2025-03-08 18:02:53.654 CET [48M] INFO: [✓] FTLCONF_webserver_api_password is used
2025-03-08 18:02:53.654 CET [48M] INFO: [✓] FTLCONF_webserver_port is used
2025-03-08 18:02:53.654 CET [48M] INFO: [✓] FTLCONF_dns_upstreams is used
2025-03-08 18:02:53.654 CET [48M] INFO: [✓] FTLCONF_dns_domainNeeded is used
2025-03-08 18:02:53.654 CET [48M] INFO: [✓] FTLCONF_dns_dnssec is used
2025-03-08 18:02:53.657 CET [48M] INFO: Wrote config file:
2025-03-08 18:02:53.657 CET [48M] INFO: - 153 total entries
2025-03-08 18:02:53.658 CET [48M] INFO: - 134 entries are default
2025-03-08 18:02:53.658 CET [48M] INFO: - 19 entries are modified
2025-03-08 18:02:53.658 CET [48M] INFO: - 10 entries are forced through environment
2025-03-08 18:02:53.662 CET [48M] INFO: Parsed config file /etc/pihole/pihole.toml successfully
2025-03-08 18:02:53.662 CET [48M] INFO: PID file does not exist or not readable
2025-03-08 18:02:53.662 CET [48M] INFO: No other running FTL process found.
2025-03-08 18:02:53.668 CET [48M] INFO: PID of FTL process: 48
2025-03-08 18:02:53.670 CET [48M] INFO: listening on 0.0.0.0 port 53
2025-03-08 18:02:53.687 CET [48M] INFO: listening on :: port 53
2025-03-08 18:02:53.690 CET [48M] INFO: PID of FTL process: 48
2025-03-08 18:02:53.694 CET [48M] INFO: Database version is 21
2025-03-08 18:02:53.695 CET [48M] INFO: Database successfully initialized
2025-03-08 18:03:32.720 CET [48M] INFO: Imported 517069 queries from the on-disk database (it has 5311029 rows)
2025-03-08 18:03:32.720 CET [48M] INFO: Parsing queries in database
2025-03-08 18:03:32.913 CET [48M] INFO: 10000 queries parsed...
2025-03-08 18:03:33.060 CET [48M] INFO: 20000 queries parsed...
2025-03-08 18:03:33.205 CET [48M] INFO: 30000 queries parsed...
2025-03-08 18:03:33.360 CET [48M] INFO: 40000 queries parsed...
2025-03-08 18:03:33.512 CET [48M] INFO: 50000 queries parsed...
2025-03-08 18:03:33.646 CET [48M] INFO: 60000 queries parsed...
2025-03-08 18:03:33.780 CET [48M] INFO: 70000 queries parsed...
2025-03-08 18:03:33.934 CET [48M] INFO: 80000 queries parsed...
2025-03-08 18:03:34.078 CET [48M] INFO: 90000 queries parsed...
2025-03-08 18:03:34.216 CET [48M] INFO: 100000 queries parsed...
2025-03-08 18:03:34.374 CET [48M] INFO: 110000 queries parsed...
2025-03-08 18:03:34.534 CET [48M] INFO: 120000 queries parsed...
2025-03-08 18:03:34.683 CET [48M] INFO: 130000 queries parsed...
2025-03-08 18:03:34.841 CET [48M] INFO: 140000 queries parsed...
2025-03-08 18:03:34.981 CET [48M] INFO: 150000 queries parsed...
2025-03-08 18:03:35.118 CET [48M] INFO: 160000 queries parsed...
2025-03-08 18:03:35.258 CET [48M] INFO: 170000 queries parsed...
2025-03-08 18:03:35.417 CET [48M] INFO: 180000 queries parsed...
2025-03-08 18:03:35.554 CET [48M] INFO: 190000 queries parsed...
2025-03-08 18:03:35.692 CET [48M] INFO: 200000 queries parsed...
2025-03-08 18:03:35.831 CET [48M] INFO: 210000 queries parsed...
2025-03-08 18:03:36.019 CET [48M] INFO: 220000 queries parsed...
2025-03-08 18:03:36.181 CET [48M] INFO: 230000 queries parsed...
2025-03-08 18:03:36.325 CET [48M] INFO: 240000 queries parsed...
2025-03-08 18:03:36.464 CET [48M] INFO: 250000 queries parsed...
2025-03-08 18:03:36.613 CET [48M] INFO: 260000 queries parsed...
2025-03-08 18:03:36.767 CET [48M] INFO: 270000 queries parsed...
2025-03-08 18:03:36.907 CET [48M] INFO: 280000 queries parsed...
2025-03-08 18:03:37.046 CET [48M] INFO: 290000 queries parsed...
2025-03-08 18:03:37.213 CET [48M] INFO: 300000 queries parsed...
2025-03-08 18:03:37.358 CET [48M] INFO: 310000 queries parsed...
2025-03-08 18:03:37.508 CET [48M] INFO: 320000 queries parsed...
2025-03-08 18:03:37.670 CET [48M] INFO: 330000 queries parsed...
2025-03-08 18:03:37.827 CET [48M] INFO: 340000 queries parsed...
2025-03-08 18:03:37.967 CET [48M] INFO: 350000 queries parsed...
2025-03-08 18:03:38.121 CET [48M] INFO: 360000 queries parsed...
2025-03-08 18:03:38.268 CET [48M] INFO: 370000 queries parsed...
2025-03-08 18:03:38.414 CET [48M] INFO: 380000 queries parsed...
2025-03-08 18:03:38.579 CET [48M] INFO: 390000 queries parsed...
2025-03-08 18:03:38.731 CET [48M] INFO: 400000 queries parsed...
2025-03-08 18:03:38.889 CET [48M] INFO: 410000 queries parsed...
2025-03-08 18:03:39.037 CET [48M] INFO: 420000 queries parsed...
2025-03-08 18:03:39.195 CET [48M] INFO: 430000 queries parsed...
2025-03-08 18:03:39.339 CET [48M] INFO: 440000 queries parsed...
2025-03-08 18:03:39.480 CET [48M] INFO: 450000 queries parsed...
2025-03-08 18:03:39.625 CET [48M] INFO: 460000 queries parsed...
2025-03-08 18:03:39.779 CET [48M] INFO: 470000 queries parsed...
2025-03-08 18:03:39.940 CET [48M] INFO: 480000 queries parsed...
2025-03-08 18:03:40.082 CET [48M] INFO: 490000 queries parsed...
2025-03-08 18:03:40.230 CET [48M] INFO: 500000 queries parsed...
2025-03-08 18:03:40.371 CET [48M] INFO: 510000 queries parsed...
2025-03-08 18:03:40.471 CET [48M] INFO: Imported 516883 queries from the long-term database
2025-03-08 18:03:40.472 CET [48M] INFO: -> Total DNS queries: 516883
2025-03-08 18:03:40.472 CET [48M] INFO: -> Cached DNS queries: 509430
2025-03-08 18:03:40.472 CET [48M] INFO: -> Forwarded DNS queries: 6169
2025-03-08 18:03:40.472 CET [48M] INFO: -> Blocked DNS queries: 898
2025-03-08 18:03:40.472 CET [48M] INFO: -> Unknown DNS queries: 266
2025-03-08 18:03:40.472 CET [48M] INFO: -> Unique domains: 889
2025-03-08 18:03:40.472 CET [48M] INFO: -> Unique clients: 32
2025-03-08 18:03:40.472 CET [48M] INFO: -> DNS cache records: 107
2025-03-08 18:03:40.472 CET [48M] INFO: -> Known forward destinations: 3
2025-03-08 18:03:41.073 CET [48M] INFO: FTL is running as user pihole (UID 1000)
2025-03-08 18:03:41.119 CET [48M] INFO: Web server ports:
2025-03-08 18:03:41.119 CET [48M] INFO: - 0.0.0.0:80 (HTTP, IPv4, OK)
2025-03-08 18:03:41.120 CET [48M] INFO: Restored 3 API sessions from the database
2025-03-08 18:03:41.150 CET [48M] INFO: Blocking status is enabled
It's doing this to hold the queries from the last 24h in memory to provide the dashboard graphs and the query log. You can disable import on startup with Settings > All Settings > Database > database.DBimport
This is not solving the problem...
I still argue, why is this so much slower than in v5? And why is there a reload for lists that works in the blink of an eye...
Hmmm
You need to provide more information. Setting the database import to false should speedup the startup - in your case by roughly 50 seconds
What I'm trying to say is, that the full cycle is worse than the service reload dnsmasq (config reload) in v5 and ask if it would be feasible to get this functionality back...
Why is the webserver including database in this cycle