I don't think there's a way for two DNS servers in different forests to do multi-master two-way sync... but maybe there's another way:
This may reduce security but what if you setup one forest as a primary rDNS zone, and the other forest as the secondary rDNS zone. I don't think secondary could be stored in AD so you'd need to setup secondary on each DNS server in second forest.
Then configure both forests' rDNS zone to allow zone transfers and enable notify. Limit to DNS server IP's for security sake.
The snag is what will a client on second forest do? It updates DDNS in it's forest but I'm not sure if client or DNS Service is what updates the rDNS zone. And since I think secondary zone for the rDNS is read-only, then somehow a referral needs to be made to the primary rDNS in first forest. If that actually happened, then I would imagine first forest rDNS would need to be changed from secure updates only to nonsecure and secure. Not as big a deal for rDNS zones, but still.
This is a rare scenario but curious myself if it can be done. Let us know how it goes. I could be totally wrong in my thinking here.
Answer found, and it's a bit unpleasant (at least if you were expecting the people creating management packs to actually know what they are doing).
Extracted from the monitor's description:
This monitor verifies forwarder availability by performing an
NSLOOKUP on the targeted forwarder.
The script executes nslookup -timeout=<value> -querytype=<type> <name> <server>
<type> is A, NS, SOA.
<name> is target DNS name to resolve. If unconditional forwarder, the
override value is used else the forwarder domain name is used.
<server> is the name of the server where the NSLOOKUP query occurs.
The value is $Target/Property[Type="DNS!Microsoft.Windows.DNSServer.Library.Server"]/ListeningIP$
which provides a listing of all IP addresses that the current DNS
server is listening on.
<value> is timeout seconds/3 because timeout seconds is used to set
the maximum time the script can run.
Unconditional Forwarder Example: NSLOOKUP -timeout=30 -querytype=a www.microsoft.com 10.0.0.5 would query server 10.0.0.5 for the DNS
name for www.microsoft.com. In this case, you would set the actual
timeout seconds to 90 monitor override.
Conditional Forwarder Example: NSLOOKUP -timeout=30 -querytype=a www.msn.com 10.0.0.5 would query server 10.0.0.5 for the actual name
of the conditional forwarder targeted by this monitor.
What this means is that the SCOM agent will try to perform queries like these ones:
nslookup -timeout=30 -querytype=a domainB.dom <server>
nslookup -timeout=30 -querytype=a someotherzone.local <server>
nslookup -timeout=30 -querytype=a 0.0.10.in-addr.arpa <server>
This would work for the main AD domain's DNS zone (because DCs automatically register themselves as empty A records for that zone), but would fail for "someotherzone.local", which didn't have any empty A record (I can confirm that, after manually creating one, the alert disappeared and the monitor returned to green).
The third query, of course, would always fail, because it just doesn't make any sense at all to look for an A record in a reverse lookup zone.
Resolution: override the DNS Forwarder Availability Monitor to perform a NS or SOA query for the forwarded zone instead of an A query.
Which is what it should have been doing from the very beginning.
Best Answer
Reverse DNS for private IP space that is company unique should live on DNS servers that are likewise reachable by all internally facing production DNS servers, to maximize unique ownership. Given the security policies that should be in place for your AD infra, it's unlikely that this central authority will be your AD servers without adequate planning and replication.
This isn't to say your AD servers should have no reverse authority. Just limit it to what is actually necessary (very little is, like joe said in the comments) and use forwarders for the rest to ensure that automatic creation of reverse records doesn't get out of hand.
(Disclaimer: I'm well aware that these are idealistic recommendations that are frequently ignored by most large companies. Those companies also have to deal with different PTR records being returned depending on which DNS servers are being used, with very few of those PTR records ever being properly cleaned up after IPs are reclaimed. In short, it's a madhouse and it always will be unless you plan to make it otherwise.)