Turns out one of the DC's had EnableDnsProbes set to 1. As soon as I set it to 0 on both and cleaned cache and restarted DNS Server/NetLogon on both controlers everything seems to resolve good.
dnscmd /config /enableednsprobes 0
As per Microsoft Article.
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
I don't think it is your conditional forwarder that is causing this behaviour. if you have configured the conditional forwarder to forward any query for the domain test.dom to another set of DNS servers then that is the only domain it will resolve using this conditional forwarder.
On your super.dom DNS servers what entries do you have in the forwarders tab? do you have any entries in there? if you have entries like 8.8.8.8 then it is this entry that will try to resolve external.com and not your conditional forwarder. alternatively if you don't have any entries in you forwarders tab then your super.dom DNS servers will be using RootHints to try and resolve external.com
if your Super.dom DNS servers don't have internet access then you can edit the forwarders tab to send all requests that the DNS server cant resolve to another DNS Server that does have internet access.