F5 gtm last resort pool DNS Record problem

Using a loopback IP with F5 BIG-IP DNS (GTM) can be a valid design, but it depends heavily on what you’re trying to achieve. It’s not “good” or “bad” universally—it's about correct use case vs risk.

In Context of Your Problem (NXDOMAIN issue)

Using loopback in GTM pools could:

Make GTM think service is always UP

Cause inconsistent DNS answers

Contribute to empty / invalid responses

Which aligns with your intermittent DNS issue via Microsoft DNS

In My opinion

Yes, loopback IP is useful—but ONLY for control-plane (iQuery/server definition)

but No, it should NOT be used for data-plane (DNS answers / pool members)

Using a loopback IP address in the context of F5 BIG-IP DNS (GTM) is a design choice that can either improve stability or introduce serious functional issues depending on where and how it is used, so it is important to clearly distinguish between control-plane use cases (internal communication and identification) and data-plane use cases (actual traffic steering and DNS responses).

In general, a loopback IP is a logical interface that is always up as long as the system is running, independent of any physical interface state, which makes it attractive for scenarios where you want a stable, non-flapping endpoint; for example, when defining a GTM server object that represents an LTM device, using a loopback or a stable self-IP for iQuery communication can be beneficial because it ensures that GTM can consistently reach the LTM regardless of which physical interface is active, how routing changes, or whether a specific VLAN goes down, thereby improving resilience of the control-plane communication between GTM and LTM and reducing false negatives in device health or synchronization.

This is particularly useful in complex environments with multiple interfaces, floating self-IPs, or dynamic routing, where tying GTM’s perception of a server to a specific physical interface could create unnecessary fragility; in such cases, a loopback-backed address provides a stable anchor point and simplifies design. However, the advantages of loopback IPs stop there, and significant problems arise when they are misused in the data plane, especially as GTM pool members or in last resort pools, which appears closely related to the intermittent DNS/NXDOMAIN behavior you described earlier.

When a loopback IP is used as a pool member, GTM health monitors often see it as perpetually available because the loopback interface itself is always up, even if the actual application or virtual server behind it is down; unless very carefully configured with application-level monitoring that truly validates end-to-end service health, this can result in GTM marking a resource as “UP” when it is effectively unusable from a client perspective, causing DNS to return an IP that does not serve traffic.

This becomes even more problematic in last resort pool configurations, where the expectation is that GTM should only return those members when all primary options are exhausted; if the last resort member is a loopback IP that is always considered up, GTM may consistently return it or may behave unpredictably when other members fluctuate, undermining the purpose of failover logic and potentially contributing to inconsistent DNS responses such as empty answers or fallback behaviors that upstream resolvers like Microsoft DNS interpret as negative responses and cache as NXDOMAIN.

Another critical issue is that loopback IPs are not routable outside the local system; if such an IP is ever returned in a DNS response to an external client, it will lead to immediate connection failures because clients cannot reach that address, effectively creating an outage scenario. Even in internal environments, unless there is very specific routing or NAT logic, loopback-based answers are generally unusable for clients.

In the context of GTM, which is fundamentally responsible for directing clients to reachable service endpoints across data centers, this violates the core requirement that every DNS answer must correspond to a valid, reachable, and healthy service instance.

Therefore, best practice in production environments is to strictly separate responsibilities: use loopback or stable self-IPs only for GTM server definitions and iQuery endpoints where you need consistent device-to-device communication, but always use real, routable virtual server IPs (VIPs) or floating self-IPs as GTM pool members so that DNS responses point to actual services that can handle traffic.

Additionally, ensure that robust health monitors are attached to those pool members so GTM can accurately determine service availability based on application-level checks rather than simple reachability, which further reduces the risk of false positives.

From an architectural standpoint, this aligns with the principle that control-plane stability (how devices talk to each other) should not compromise data-plane correctness (how clients reach services).

In your specific scenario involving intermittent NXDOMAIN responses when queries pass through Microsoft DNS, the misuse of loopback IPs could exacerbate or even trigger inconsistent GTM behavior, especially if GTM sometimes returns answers based on members that are logically up but practically unusable, or if fallback logic produces responses that differ in structure (e.g., empty vs populated answers), leading recursive resolvers to cache negative results; ensuring that all GTM responses are consistent, valid, and based on truly healthy, routable endpoints is key to eliminating such issues.

In summary, loopback IPs are a powerful tool for improving reliability of internal GTM-LTM communication and should be used there thoughtfully, but they are unsuitable and risky for representing actual application endpoints in GTM pools or DNS answers; adhering to this distinction will help maintain both stability and correctness in your global traffic management design, prevent misleading health states, and avoid DNS anomalies like the intermittent failures you are troubleshooting.

Thanks a lot, Falback IP looks good.

Do you think is a good idea to use a loop back IP? 

GS

Hi GrazianoSommariva​ ,

The issue occurs because F5 BIG-IP DNS (GTM) sometimes returns an empty or inconsistent DNS response when using a last resort pool (e.g., NOERROR with no A record).

When this response goes through Microsoft DNS Server, it may be interpreted as a negative response and cached as NXDOMAIN (per RFC 2308 behavior).

Because GTM responses are not always consistent (sometimes valid IP, sometimes empty), Microsoft DNS alternates between caching valid and negative results—causing the intermittent “1 in 3 NXDOMAIN” issue.

Direct queries to GTM work fine because there’s no intermediate caching or reinterpretation.

Make GTM responses consistent (always return an IP).

That eliminates Microsoft DNS misinterpretation and stops intermittent NXDOMAIN completely.

I always Ensure GTM always returns an IP (best fix)

Avoid empty answers by forcing fallback behavior.

tmsh modify gtm pool <pool_name> fallback-mode fallback-ip

Try to Test the following quick checks to Confirm what is causing the issue

Run from a client machine:

1. Query Microsoft DNS

nslookup yourdomain.com <MS-DNS-IP>

2. Query F5 directly

nslookup yourdomain.com <GTM-IP>

Compare:

Answer section

Authority section (SOA?)

Response code (NOERROR vs NXDOMAIN)

3. Check if GTM ever returns empty answers

dig @<GTM-IP> yourdomain.com +noall +answer +authority

If you sometimes see:

No A record

Only SOA

That’s the trigger.

Please let me know for more discussion.