Last Modified: Oct 15, 2025
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 16.1.5, 16.1.5.1, 16.1.5.2, 16.1.6, 17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2, 17.1.1.3, 17.1.1.4, 17.1.2, 17.1.2.1, 17.1.2.2, 17.1.3, 17.5.0, 17.5.1, 17.5.1.2, 17.5.1.3
Opened: Aug 25, 2025 Severity: 4-Minor
The node’s availability changes to unknown, even though the DNS server is reachable and should have valid resolution data. The FQDN resolver does not immediately send a DNS query upon receiving the sync, which delays recovery of the node status. Node status returns to fqdn-up only after the next scheduled DNS query interval (For example, 240 seconds).
Temporary service visibility issue: FQDN nodes incorrectly display 'fqdn-checking' or 'availability unknown' until the next DNS resolution cycle. This can exist till the next FQDN interval configuration (For example, 4 minutes). May confuse administrators monitoring node status.
-- BIG-IP devices configured with FQDN template nodes. -- Performing config sync with the force-full-load-push option. The issue occurs on the sync receiver only. It does not reproduce without force-full-load-push.
To work around this issue, either: -- After initiating the config sync force-full-load-push, initiate on the standby/sync receiver: bigstart restart dynconfd or: -- Configure the FQDN template node with a shorter 'interval' value, so that the next DNS query occurs more quickly after the full config sync operation.
None