I have a similar situation to the OP, and tried your solution which resulted in a DNS loop and subsequent rate-limiting by the pi-holes on each other.
Tried your RegEx blacklist rule on pi-hole1 to short-circuit the loop, which worked, but as expected, it blocked the conditionally-forwarded request from pi-hole2 for hostnames that only exist in the current lease list of pi-hole1. While the reverse (lookups against pi-hole2 for hostnames that only exist in the current lease list of pi-hole1) are conditionally forwarded and work brilliantly.
If only there was a way to create a blacklist rule that lets the first request from the respective other pi-hole through and then block the rest for a brief time.
Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
pihole -d
or do it through the Web interface:
Tools > Generate Debug Log
In case multiple Pi-holes are in use, please do so for each of them.
Update: I was successful in implementing flathead's solution, which turns out to be pretty graceful without much loss of pi-hole functionality.
Further to your RegEx blacklist proposed workaround of the DNS loop caused by conditionally-forwarding two pi-holes to each other, I found that even if a way could be found to bypass the rule for the first request for a hostname and reject subsequent requests as they loop, more than just A record forwards would need to be blacklisted. Reverse lookup forwards were also looping, so RegEx would have to be defined for those, too.
flathead's solution is sharing a local/search domain across two DHCP servers.
My alternative approach would have used a separate local/search domain for each.
Whether I would have suggested one blacklist regex to short-circuit potential DNS loops on one Pi-hole in your case would have depended on your specific configuration and use case, which you haven't bothered to detail any further than being somehow similar.
Since you are using flathead's custom.list replication approach and are satisfied with it, you should probably be aware that it is unusual (yet not unreasonable) to have multiple DHCP servers on a single link, but that approach comes with its own drawbacks.
E.g. it overwrites any local DNS records you've defined via Pi-hole's UI, or if one server would suddenly go offline, it would leave the replicated local name definitions on the other intact, which may then cause naming issues for hosts acquiring a lease through the remaining operational DHCP server: As their aspired name may already be in use, they may show up by a generic name assigned by dnsmasq rather than by the name they'd like to claim for themselves.
