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.
If this is a standard DNS zone, the easiest way to back it up and restore it is to simply make a copy of the related zone file; you can find it in C:\Windows\System32\DNS, it's named "your.zone.name.dns".
Best Answer
The zone information and DNS server settings are in different places.
Non-AD-integrated DNS server stores its zones as
.dnsfiles in%windir%\system32\dns. Copy these files besidescache.dns, that only contains cached DNS lookups.With AD-integrated DNS server the information is within AD and
dns.exeperforms many LDAP requests to gather this data when it starts. It's possible to Extract Active Directory-Integrated Zone Files withdnscmd /ZoneExport FQDN_of_zonename Zone_export_file, like you have done.Settings are stored in the registry. Things are easy when AD isn't involved, as you can just export the settings with
regedit /eand import by double clicking the.regfile on the target server. With AD-integrated installation you may need to check some values manually before importing. However, here's some registry locations where you can find your server settings:HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\DNS Server\Zones(formerlyHKLM\System\CurrentControlSet\Services\DNS\Zones) is the location in the registry related to the zone files: what zones the server has, what are their settings and where they should be obtained from. The same information that can be obtained withdnscmd /zoneinfo.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parametersis the location for server-level settings. It's the same information that can be obtained withdnscmd /info.The other DNS Registry Entries aren't directly associated with the DNS Server.