" Override internal DNS" option for static interfaces?

May be look at Policy routing. The handbook shows there is a " source-ip" option in the " config system dns" , maybe play around with that. (Though not sure what exactly that does.) On some of our base configs we sometimes uses a public DNS (e.g. Googles or Open DNS) as a back up in case the primary/secondary DNS fails.

Thanks Dave. While I was writing the above post, Virtual IPs crawled into my mind. And I thought " hey... what about like a Virtual IP pool who' s ' translated IP' is actually a load balanced group... a ' what' group? Load balancing!" So I' m taking the " HTTP load balancing to three real web servers" example in the FortiOS handbook and flipping it so that one Virtual Server (IP) offered out of my internal interface uses the " First Alive" method (I think that will fit) to route access to the DNS servers! Hopefully I can work it out. If anyone has any more ideas, please let me know! Thanks, Matt [UPDATE] This did it... the trickiest thing is: If: bind the virtual server to the internal1 Public_DNS_Server_VS_group Policy must read: source interface = internal1 source address = [source address] destination interface = wan1 [interface where the member servers live!] destination address = Public_DNS_Server_VS_group [load balancing group virtual address object name] Now to test fail over and we' re good! Read the below thread for more info on caveats.

Hah! Which thing did you try? Load balanced DNS or Fortigate as the Forwarding DNS server? What is your recommendation?

I found that the FGT introduced a substantial delay in the DNS processing. So much that the users bitched, and I eventually scrapped it.

Oh no! That' s not good. I just implemented it at the site I' m at. We' ll see. We use Windows DNS Servers, and I failed to find something that can do X, then reconfigure the Windows DNS servers, and was going to start writing my own monitoring solution. What did you eventually end up doing to solve the problem? Thanks! Matt

Thanks for the reply! In my testing, it doesn' t appear that the Conditional Forwarders we had configured actually performed a failover (at least until the higher priority servers came back up). For instance, our Primary ISP has two DNS servers, our secondary ISP has two DNS servers. If primary ISP is down, we are on secondary ISP. Primary ISP doesn' t allow access from Secondary ISP. Windows DNS Server times out (in my case) at 5 seconds as follows: primary ISP Server 1, primary ISP Server 2... secondary ISP server 1 then services the lookup (+10 seconds). In this case, I' ve just read that the Windows DNS server should actually remember that primary ISP Server 1 and primary ISP Server 2 are down, and forward directly to secondary ISP server 1. However, (and this is really why I' ve started in to solve this) this simply isn' t the case. For every single (qualified) DNS query, it takes no less than 10 seconds to resolve (less servicing from cache). So, what am I missing with properly configuring Windows DNS Server conditional forwarding to support DNS Server forwarding failover? Thanks, Matt

Bob, I made it two weeks and finally had a problem reported. It' s quite an odd situation, in that the host uses a round-robin strategy for the DNS record (which happens to be a CNAME), and the TTL of the CNAME record is about 5 minutes and the A record is 20 seconds. 95% of the time, the client receives the complete resolution of the CNAME record to the A record' s IP without an issue (either from it' s local cache (ipconfig /displaydns), or from the local DNS server' s cache or resolution procedure). If I trace a transaction ID of a failed lookup, I am able to see query packets being sent from the client (pcap), arriving and processing at the DNS server (DNS logs), the CNAME record is resolved to the A record, but the A record response is never received by the server. The server then goes out to the SOA servers for the domain to resolve the target of the CNAME (the A record). The strategy of using such a low A record TTL with a higher CNAME record TTL really seems like a bad idea to me, particularly since the resource is an external host (at least the introduction of a CNAME and two varying TTL). I' m having the person test by using the A record that' s the target of the CNAME to see if the problem continues to occur. (fyi: from a political/appearance stand point the A record name is within the domain of a swallowed up company, so they just " threw a CNAME at it." ) Thanks, Matt [UPDATE/CONCLUSION/SOLUTION] Reviewing the Windows DNS Server logs, revealed the problem. Time CNAME' s A records is asked for by the Windows DNS server: 20130227 12:59:02 (asking Fortigate' s Virtual Server Address) 20130227 12:59:08 (asking geographically_dispersed_SOA_server_1) 20130227 12:59:12 (asking geographically_dispersed_SOA_server_2) 20130227 12:59:16 (asking geographically_dispersed_SOA_server_3) 20130227 12:59:16 (asking geographically_dispersed_SOA_server_4) 20130227 12:59:23 (asking Fortigate' s Virtual Server Address) [note that the time is 20 seconds, like the A record' s TTL] Time responded to: 20130227 12:59:23 (answered by Fortigate' s Virtual Server Address) Using: nslookup -qa=A -debug [FQDN of CNAME] [Fortigate' s Virtual Server address] I' m able to see the SOA servers FQDNs and see the list of geographically dispersed SOA servers correlate. So, although the Fortigate' s Virtual Server failed to (at least) return a response (from the public DNS server in it' s Real Server pool, maybe), the Windows DNS Server tried it' s secondary method of resolving the DNS Problem: The Windows DNS server was only able to access port 53 of the Virtual Server address by firewall policy. Solution: Allow the Windows DNS server to access any IP address over port 53 by firewall policy. Unfortunately this doesn' t answer why the Fortigate failed to deliver a lookup response in the first place, but it is a good workable solution. You could implement two policies, and place the one with the destination IP of the Virtual Server before the policy targeting ' all' then review the policy hit ' count' column to see how common this " problem" is (for instance). Bob: this may solve your issue. Thanks, Matt