|
Even after the Secondary FortiGate is rebooted and completes synchronization with the Primary FortiGate, the resolved IP address of the 'wildcard FQDNs' may not be synchronized.
In contrast, regular (non-wildcard) FQDNs are properly synchronized between the Primary and Secondary FortiGate.
Additionally, when the Primary FortiGate resolves a new IP address for a previously unsynchronized wildcard FQDN, that FQDN will subsequently be included in the synchronization process.
To confirm whether synchronization is taking place, run the following command via the CLI and compare the results between the Primary and Secondary FortiGate:
diagnose test application dnsproxy 6
The following shows the FQDN synchronization status after the Secondary FortiGate has been rebooted and HA synchronization has completed.
Primary:
FG2600F-Primary (global) # diagnose test application dnsproxy 6
worker idx: 0
(snip)
vfid=1 name=*.as2.local ver=IPv4 wait_list=0 timer=0 min_ttl=120 cache_ttl=0 slot=-1 num=1 wildcard=1
192.168.232.1 (ttl=120:65:65)
vfid=1 name=*.as1.local ver=IPv4 wait_list=0 timer=0 min_ttl=0 cache_ttl=0 slot=-1 num=0 wildcard=1
(snip)
FQDN num=33
Secondary:
FG2600F-Secondary (global) # diagnose test application dnsproxy 6
worker idx: 0
(snip)
vfid=1 name=*.as2.local ver=IPv4 wait_list=0 timer=0 min_ttl=0 cache_ttl=0 slot=-1 num=0 wildcard=1
vfid=1 name=*.as1.local ver=IPv4 wait_list=0 timer=0 min_ttl=0 cache_ttl=0 slot=-1 num=0 wildcard=1
(snip)
FQDN num=33
Related documents:
FQDN addresses
diagnose test application dnsproxy
Technical Tip: FortiGate Troubleshooting DNS commands
|
