In Transparent DNS, each Zone on the firewall has its own DNS server specified. If a query comes in from the DMZ zone and it hits a rule that uses a Host or Domain object the DNS server for the DMZ zone is queried. If that DNS server specified for the DMZ zone actually resides off a different zone (say, internal) you must then have a Rule to pass DNS traffic from the DMZ to the internal zone. By default, on all firewalls, there is a DNS rule which passes all DNS traffic from all zones to all zones to the DNS server you specified when you initially configured the firewall. If you change or add DNS servers to Zones you must then specify them in that rule as a Destination object. In regards to why this works using 'dig' and not via the Access Control Rules it's because dig is most likely using a different DNS server than what you have specified in your DNS config. The firewall uses the DNS servers listed in /etc/resolv.conf.dflt (in that order) when you do queries on the CLI and does not require rules to do queries.
Please read my answers in this Community thread about using DNS-objects in your policy. The short answer is do not use DNS-objects in your policy unless you have absolute control over the DNS replies. Your firewall is relying on unreliable-UDP for critical policy decisions. If, in your example above, someone rebooted that DNS server or it crashed, your rules to this external site will not work until that server starts replying again. Thus, your policy would work great if you used IP objects but now does not work because some other device is not working correctly.
I have actually solved it. I only had one DNS server configured (both internal and external had the DNS configured as the external DNS server) so I couldn't be using another DNS server and the solution did not need a rule to pass DNS traffic to another zone. The configuration I had was correct but I was running version 8.3.2 and by upgrading to 8.3.2P06 it fixed the problem.
I looked at adding "dns" on the host line in nsswitch.conf, which resulted in me being able to ping using the host name where before it was not resolving. With the host name being able to be resolved using ping and dig, I concluded that there must have been a bug in the access-list implementation of DNS queries, especially when a tcpdump on both internal and external interfaces did not display anything using port 53.
As for the recommendation for not using DNS-objects, our customer has stated that using static IP addresses is less reliable as these target IP addresses are likely to go down for maintenance and any change to our system requires approval even if it was an IP address change which could take days to approve. Also, any downtime as a result of a failure to the external network is not our problem but our system will need to have some sort of attempt at resilience hence the change from static IP addresses to DNS-objects.