The GSLB pool is providing an incorrect IP to end users

That is an interesting issue.  Have you verified there is not another device upstream causing the issue.  Maybe a firewall doing a NAT or another DNS device (Infoblox) with the record?

Hi ,

Is there any DNS caching enabled or your local DNS server already have an entry for this hostname ?

BR
Aswin

Hello SureshP​ 

I see we have a few questions from members of our community. I would like to encourage you to respond to these members or provide an update to your post if you have gotten a solution outside of DevCentral. Updating post is helpful to you and other members of the community who may run into this instance in the future. 

Thank you for being a part of our community! 

-Melissa 

If all GSLB pool members are unavailable, maybe the query is falling through to the local (within BIG-IP) BIND instance. You can check for the offending A-record via the ZoneRunner interface.

If there’s no upstream DNS or NAT device, then the behavior is almost certainly coming from the GSLB logic itself. In many setups, disabling a pool member does not immediately remove it from DNS responses if the service still considers the pool available. Cached responses are a big factor here, especially with long TTLs on wide IPs.

Another thing to check is whether the pool has fallback enabled. If all members are down or disabled, the system may return the GSLB or wide IP by design. Also verify monitor status, not just the enabled flag. If the monitor still shows green, the pool can be treated as healthy.

I’d suggest reviewing the wide IP configuration, fallback settings, and forcing the member offline. Then test with fresh DNS queries to avoid cached answers.