Skip to main content
smkml
Staff
Staff
May 20, 2025

Troubleshooting Tip: Unable to resolve DNS issues

  • May 20, 2025
  • 0 replies
  • 1313 views
Description

 

This article describes how to troubleshoot when DNS cannot be resolved from FortiManager/FortiAnalyzer.

 

ping bad address.png

 

When pinging to a fully FQDN or a domain, it will throw a 'bad address' error.

 

Scope

 

FortiManager, FortiAnalyzer.

 

Solution

 

  1. Isolate the issue if able to ping the IP address.

 

Wira-kvm20 # execute ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=116 time=4.043 ms
64 bytes from 8.8.8.8: seq=1 ttl=116 time=3.851 ms
64 bytes from 8.8.8.8: seq=2 ttl=116 time=3.696 ms
64 bytes from 8.8.8.8: seq=3 ttl=116 time=3.499 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 3.499/3.772/4.043 ms

 

  1. Check if the DNS server is configured correctly, or isolate to use a public DNS server

 

Wira-kvm20 # show system dns
config system dns
set primary 8.8.8.8
set secondary 1.1.1.1
end

 

Note:

When changing to a new DNS server, it will still have a cache (10 minutes) of the previous server until it is cleared. Manually kill the DNS daemon to clear the cache as per the steps below.

 

  • Check netstat and get the pid, 'diagnose system print netstatExample: tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 29007/dns
  • Kill the DNS daemon, 'diagnose system process kill -9 <pid>Example: 'diagnose system process kill -9 29007'.

 

  1. Check if FortiManager/FortiAnalyzer is listening to the DNS port TCP 53

 

Wira-kvm20 # diagnose system print netstat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 29007/dns
tcp 0 0 127.0.0.1:7080 0.0.0.0:* LISTEN 1442/sdnproxy
tcp 0 0 127.0.0.1:31723 0.0.0.0:* LISTEN 2247/httpd
tcp 0 0 127.0.0.1:6386 0.0.0.0:* LISTEN 1459/redis-server 1

........

......

 

  1. Perform a debug to understand what happened on the backend

 

diagnose debug application dns 255

diagnose debug enable

 

Wira-kvm20 # execute ping google.com
got query 0f66: len=28 google.com A
forward query 0f66 to 8.8.8.8
got query 05fc: len=28 google.com AAAA
forward query 05fc to 8.8.8.8
forward query 0f66 to 1.1.1.1
forward query 05fc to 1.1.1.1
got query 0f66: len=28 google.com A
use unique id: 0f66 -> 0f67
forward query 0f66 to 8.8.8.8
got query 05fc: len=28 google.com AAAA
use unique id: 05fc -> 05fd
forward query 05fc to 8.8.8.8
cancelled query 0f66
cancelled query 05fc
forward query 0f66 to 1.1.1.1
forward query 05fc to 1.1.1.1
ping: bad address 'google.com'

cancelled query 0f66  <-----  Failed response, something is blocking from FortiManager/FortiAnalyzer.
cancelled query 05fc  <----- Failed response, something is blocking from FortiManager/FortiAnalyzer.

 

FMG-VM64-KVM # execute ping google.com
got query 404a: len=28 google.com A
connected 12.33.11.1
forward query 404a to 12.33.11.1
got query 46ad: len=28 google.com AAAA
forward query 46ad to 12.33.11.1 <----- No response from Primary DNS server.
connected 8.8.8.8 <----- Query to Secondary DNS server.
forward query 404a to 8.8.8.8
forward query 46ad to 8.8.8.8
got reply 404a from 8.8.8.8: len=44 err=0 google.com A
answer query 404a <----- Successful response, connected via Secondary DNS server.
got reply 46ad from 8.8.8.8: len=56 err=0 google.com AAAA
answer query 46ad <----- Successful response, connected via Secondary DNS server.
PING google.com (172.217.26.78): 56 data bytes
64 bytes from 172.217.26.78: seq=0 ttl=116 time=3.197 ms
64 bytes from 172.217.26.78: seq=1 ttl=116 time=2.631 ms
64 bytes from 172.217.26.78: seq=2 ttl=116 time=3.573 ms
64 bytes from 172.217.26.78: seq=3 ttl=116 time=2.942 ms

--- google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 2.631/3.085/3.573 ms

 

   5. Check in the configuration if any 'local-in-policy' is configured:

 

Wira-kvm20 # show system local-in-policy
    config system local-in-policy
        edit 1
            set action accept
            set dport 443
        next
            edit 2
                set action accept
                set dport 22
            next
                edit 3
                    set intf "port1"
                next
            end

 

This configuration will block all TCP/UDP port traffic from port1 besides ports 443 and 22. 

 

Related article:

Technical Tip: How to create a FortiManager local-in policy via CLI