DNS Configuration question

WD 250GB 5400 RPM 8 MB WD2500LPVX hard drive
8GB RAM
SUPERMICRO MBD-A1SAM-2550F-O uATX
SuperChassis CSE-512L-200B
Sophos UTM 9.3

Workstations should have the internal interface IP of the UTM for DNS, then in WebAdmin:

Network Services > DNS > Global Add your Internal (Network) to Allowed Networks
Network Services > DNS > Forwarders Add Google DNS servers and untick Use forwarders assigned by ISP.

DNS availability group

Browse to: Definitions & Users | Network Definitions | New network definition
Configure 2 separate network definitions with the following properties
Name: Google DNS 1 & Google DNS 2
Type: Host
IPv4 Address: 8.8.8.8 & 8.8.4.4
Browse to: Definitions & Users | Network Definitions | New network definition
Configure the definition as follows:
Name: Google DNS Servers
Type: Availability Group
Members:
Google DNS 1
Google DNS 2

UTM will not allow that IPv4 address: "The host object requires an IPv4 address for the IPv4 address attribute"

I just made an Availability Group with both Google DNS servers and am not seeing this issue. At what exact point are you seeing the error? Can you get screenshots?  Version 9.352?

BTW, you don't need to go to network definitions, you can create everything from Network Services > DNS > Forwarders.

For those who may come across this thread in future, I worked with Patrick offline to resolve the issue, but I'd like to report the cause and solution so that it may help someone else down the road. I'm not going to give too much detail , due to it not being my network. Bear in mind that the below solution didn't come up in 5 minutes. It took a few days Q&A back and forth, in short sessions, when both of us were available (not working, sleeping, eating, doing things with kids, etc.), with significant delays between responses. If all of the gap time was taken away, total time of diagnosis and solution was probably in the realm of 30 minutes.

Scenario: Simple standard home use setup. Modem--->UTM--->dumb switch--->all client hosts. The DNS issue listed in the op was a symptom of the actual problem. Not all, but many hosts had static entries in the UTM for IP. Multiple internal hosts could not reach the UTM and the UTM could not reach them. Most of them had connectivity intermittently, but one specific one would not work at all. A FreeNAS box couldn't reach the UTM and vice versa, but other LAN clients could reach the FreeNAS.

Diagnosis: Went through a number of troubleshooting steps from the UTM itself. Three of these came up with a crucial piece of information...
1) kernel messages log filled with martian packet entries for the static IP assigned to the FreeNAS on the LAN interface. Martian Packets are those that are considered alien to that network interface (alien....hence martian). These are frequently associated with fun times like routing loops. Bad cheap switch, cabling errors, could be a number of things. Now recall that there was no connectivity when trying to access the NAS by IP, nor could the NAS contact the UTM......but yet there were some packets getting to the UTM.
2) DHCP log showed requests from the IP. Hhhmm, I wonder that kind of traffic a DHCP Discover is?
3) Looked at the ARP cache and a quick packet dump to make certain there wasn't another MAC address being associated for that IP...there wasn't.

Cause: Long story short, FreeNAS has a built-in hypervisor.for small apps. It's called jail, because it's isolated from the host OS. Amazingly enough, jail has it's own DHCP server for these VMs. The scope for which was set (default) to the exact same subnet as the LAN, with the first lease being given for 192.168.1.1. One of these app VMs had the same IP as the LAN gateway (UTM internal interface) for the network. Fantastic.

So, the FreeNAS OS itself, when trying to reach the gateway has the traffic looped back to a VM in its' jail...hence no connectivity at all for it. Some packets from other LAN machines for the gateway were being routed to the VM, based on the -arp table, depending on whether the switch had last received a packet from the UTM or VM. For those who aren't network engineers, the reason that DHCP Discover packet could still reach the UTM, but nothing else, is that they are broadcast...sent to the whole network, not just a single IP.

Solution: Turn off the FreeNAS jail DHCP server, setting it to use the LAN network for DHCP. Restarted the offending VM so it could release 192.168.1.1 and then get an IP from the UTM DHCP. All better.

Amazing job Scott. Sophos is very lucky to have such a dedicated, helpful, and very trusting member of their team. Thank you very much for taking the time to solve my issue!