pjhtech Tools
FortiGate · FortiOS 7.4

FortiGate DNS cache and NTP diagnostic commands

Quick answer #

Check what FortiGate currently knows about the hostname and whether its clock is actually synchronized. A configured DNS server or enabled NTP setting is only an intention; cached resolution and synchronization status show the observed state.

Scope: FortiOS 7.4-family diagnostics. FQDN inspection is VDOM-sensitive; system NTP and global DNS settings need the appropriate administrative scope.

Read system time and NTP state #

Read system time and NTP state
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only
get system status
Read-only
diagnose sys ntp status

Record the displayed time, timezone context, synchronization result and selected server. Compare clock offset and reachability with a second reading rather than treating any non-zero offset as a fault. A timezone display mismatch is different from an incorrect absolute clock, and changing one does not fix the other.

An NTP server configured by hostname also depends on successful DNS resolution. If the status identifies that server as unresolved, investigate name resolution before modifying synchronization intervals. If the server resolves but does not answer, examine the routed path and the configured source/interface context.

Inspect the FQDN object view #

In the VDOM containing the affected address object:

Inspect the FQDN object view
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Read-only
diagnose test application dnsproxy 6

Find the object or hostname and note whether addresses are present, how many are retained and the available TTL information. This diagnostic is used for FQDN entries; it is not proof of what a particular endpoint received from its own resolver. Administrator profiles may restrict access even though the requested operation is diagnostic.

Compare like with like #

Record the client's resolved address at the same time as the FortiGate entry. A hostname served through different resolvers or a CDN can yield different answers. An FQDN policy problem therefore needs the actual connection destination alongside the cached object, not just confirmation that both systems can resolve the name to something.

Observe an NTP exchange when needed #

For a known configured server, use a bounded capture:

Observe an NTP exchange when needed
FortiOS 7.4 · Traffic VDOM; administrative scope as described below

Diagnostic state

Replace these example values: 192.0.2.123, 123.

diagnose sniffer packet any 'host 192.0.2.123 and udp port 123' 4 30 l

Press Ctrl+C when finished; a packet-count limit is not a time limit.

Output may contain sensitive operational data.

The address is illustrative. Wait for a normal poll or stop with Ctrl+C; an idle capture does not terminate solely because a packet limit was supplied. A request and reply establish network visibility, but the NTP status still determines whether the server was selected and synchronization succeeded.

Keep changes separate #

Do not clear DNS caches or force a time jump during initial collection. First preserve the current state and determine whether the fault is resolution, reachability, selection or display. Correct timestamps make authentication and VPN logs much easier to correlate across systems.

Sources

Documentation reviewed: 8 October 2026