Description
This article describes that in some cases, the network does not work because the DNS server is down or intermittently available. The DNS server is necessary to resolve domains/URLs to IP addresses. It will not be reachable if the DNS server cannot resolve the domain.
This article assists with DNS troubleshooting.
Scope
FortiGate.
Solution
Troubleshooting.
There are 3 scenarios for DNS issues in the network:
- FortiGate is the DNS server: The PC is using the FortiGate interface as the DNS server.
- The PC is using a local DNS server: The PC is directly using a local DNS server in the network.
- The PC is using a public DNS server: The PC is directly using a public DNS server such as 8.8.8.8 or 1.1.1.1.
This troubleshooting guide focuses on Windows machines.
Open the command prompt and run the following:
ping 8.8.8.8
ping www.google.com
ping xxx.xxx.xx.xx <- Any domain which is not working.
Pinging to 8.8.8.8 verifies internet connectivity. If the PC is able to ping 8.8.8.8, it means internet connectivity is working as expected.
The ping to www.google.com is to verify DNS resolution. If the PC is able to ping 8.8.8.8 but not www.google.com, the DNS is not working.
Windows (or any machine) cannot resolve domains if any of the following conditions are true:
The ping to www.google.com is to verify DNS resolution. If the PC is able to ping 8.8.8.8 but not www.google.com, the DNS is not working.
Windows (or any machine) cannot resolve domains if any of the following conditions are true:
- No Preferred/Alternate DNS Server is configured.
- The DNS server is not reachable.
- The DNS server did not respond to the DNS query.
- The DNS server does not have the DNS record.
Check the Windows configuration as shown below:
The current adapter is using 8.8.8.8 as the Preferred DNS server. 8.8.8.8 is a public DNS server that will resolve public domains/URLs.
This public DNS cannot resolve local URLs/domain names.
Example.
Example.
ping mywebserver.local.my
ping syarif-pc
Because this URL/domain is introduced internally, a public DNS server like 8.8.8.8 will not have this information.
However, 8.8.8.8 can resolve the following addresses:
To check if the DNS is working, change the Preferred DNS server on the Windows machine and perform a domain ping test.
If the internal DNS server did not respond to the request, check on that DNS server.
Additionally, run the following debugging tasks for the ongoing DNS connection:
diagnose test application dnsproxy 3
Run the following sniffer:
diagnose sniffer packet any " port 53 " 6 0 a
When troubleshooting DNS requests, debug logs provide detailed insights into the resolution process. Below is a step-by-step explanation of how to analyze DNS debug logs, using the domain www.site.com as an example. Key log entries are included to illustrate this process.
Lastly, the following debug provides insights into the resolution process:
diagnose debug application dnsproxy -1
diagnose debug enable
DNS Request Received.
The client sends a DNS request to the server. The following log indicates the receipt of the request:
udp_receive_request()-3194: vd=0, vrf=0, intf=21, len=34, alen=16, 192.168.100.23:11849=>192.168.100.99
Handling the Request.
The server processes the query for www.site.com:
dns_local_lookup_common()-2553: vfid=0, real_vfid=0, qname=www.site.com, qtype=28, qclass=1
Cache Lookup or Forwarding.
If the response is cached, it is sent directly:
dns_send_cached_response()-1747: domain=www.site.com
Otherwise, the query is forwarded to an upstream DNS server:
dns_send_resol_request()-1344: orig id: 0x44b4 domain=www.site.com
DNS Response Received.
The server receives and processes the response:
dns_query_handle_response()-2743: domain=www.site.com pktlen=222
Response Sent to Client.
The resolved data is sent back to the client:
dns_send_response()-1645: domain=www.site.com reslen=222
The scenarios outlined in this article apply to Windows machines.
