There is another variant that can be used to test and query a specific URL and follow the DNS lookup request on the FortiGate. This can be done by enabling the following debug and performing an ICMP test. The example uses www.fortinet.com as follows:
diagnose debug disable
diagnose debug reset
diagnose debug application dnsproxy -1
diagnose debug console timestamp enable
diagnose debug enable
execute ping www.fortinet.com
To stop debugging:
diagnose debug disable
diagnose debug resetÂ
For FortiOS version 6.0, more information was added:
diagnose test application dnsproxy ?
1. Clear DNS cache
2. Show stats
3. Dump DNS setting
4. Reload FQDN
5. Requery FQDN
6. Dump FQDN
7. Dump DNS cache
8. Dump DNS DB
9. Reload DNS DB
10. Dump secure DNS policy/profile
11. Dump Botnet domain
12. Reload Secure DNS setting
13. Show Hostname cache
14. Clear Hostname cache
15. Show SDNS rating cache
16. Clear SDNS rating cache
17. DNS debug bit mask
 Note: Include any of these debugs in the Support ticket raised when trying to resolve a DNS issue on the FortiGate. Fortinet support will advise further should other debugging be required.  In FortiOS versions 7.0, 7.2, and 7.4, more information was added:
diagnose test application dnsproxy ?
1. Clear DNS cache
2. Show stats
3. Dump DNS setting
4. Reload FQDN
5. Requery FQDN
6. Dump FQDN
7. Dump DNS cache
8. Dump DNS DB
9. Reload DNS DB
10. Dump secure DNS policy/profile
11. Dump Botnet domain
12. Reload Secure DNS setting
13. Show Hostname cache
14. Clear Hostname cache
15. Show SDNS rating cache
16. Clear SDNS rating cache
17. DNS debug bit mask
18. DNS debug obj mem
99. Restart dnsproxy worker
 In FortiOS version 7.6, even more information was added:
diagnose test application dnsproxy ?Â
1. Clear DNS cache
2. Show stats
3. Dump DNS setting
4. Reload FQDN
5. Requery FQDN
6. Dump FQDN
7. Dump DNS cache
8. Dump DNS DB
9. Reload DNS DB
10. Dump secure DNS policy/profile
11. Dump Botnet domain
12. Reload Secure DNS setting
13. Show Shared Memory Hostname cache
14. Clear Shared Memory Hostname cache
15. Show SDNS rating cache
16. Clear SDNS rating cache
17. DNS debug bit mask
18. DNS debug obj mem
19. Show nameserver cache
99. Restart dnsproxy worker
Â
Scenario: Users can load the homepage of a website; however, after trying to log in or access a different link on the website, the page keeps loading. The firewall policy for this traffic uses the FQDN address object for the destination only. Checking the Forward Traffic Logs page under 'Log & Report' shows traffic is allowed to the FQDN; however, after some time, traffic events with the result client-rst, server-rst, or timeout can be found. There is a good chance this problem is a product of the website sub-directory pages being hosted on IP addresses that belong to other domains or do not resolve that website's hostname. An example of such a scenario is hosting the website services over Content Delivery Network (CDN) servers. One way to find out is to check other traffic from the same source IP at the same time the access to sub-pages of that website failed or did not load. If there are destinations that are being denied at the same time that did not have any name resolution showing on the logs or showing they belong to CDN vendors such as AKAMAI, Fastly, or AWS, this indicates this traffic is meeting this scenario. A solution would be to expand the allowed destination on the firewall policy matching this traffic to include the additional IP addresses or hostnames required to access the failed pages.
 Starting from FortiOS v7.0.0 and above, 'diagnose test application dnsproxy 15' will not show SDNS cache results because the DNS filter in flow mode is handled by the IPS engine. If changing to proxy mode, the results will be displayed.  Starting from FortiOS v7.6.0, the DNS system database config has the option to configure the 'source-ip-interface' to overcome the challenges of dynamic IP address change.  Related documents: | 
