Service providers such as Google, Infoblox, etc, will only forward ECS data to an authoratative DNS server if that domain being queried is in the list of ECS zones.

• For Infoblox, this list is mostly services Google, YouTube, SalesForce, Netskope, etc.
• Microsoft doesn't support ECS.
• Infoblox forwards the /24 when forwarding ECS data.
• When using an Infoblox Endpoint, the public IP is the one that Infoblox Cloud sees as the source IP. i.e. the public IP that the Infoblox Endpoint is source NAT'd behind.
• When using an External Network, the public IP is the External Network being used.
• When using NIOS-XaaS with DFP, it is the public IP of the NIOS-XaaS POP being used.
• When using a DFP, the public IP used is the public IP that Infoblox has associated with that DFP (called “NAT IP Address” when looking at the Server details in the Infoblox Portal). i.e. the public IP that the DFP is source NAT'd behind.

You can check what IP the service sees by testing against Google.

dig @<IP OF DFP or local DNS server>+short TXT o-o.myaddr.l.google.com

Geolocation support uses the EDNS0 ECS (ENDS client subnet) option to pass the public /24 subnet of your IP address to a third-party DNS server. This allows ECS enabled third-party DNS servers to provide appropriate answers based on the geolocation of the source user and direct users to the closest instance of the DNS record being queried.

Infoblox Threat Defense provides the option of enabling or disabling geolocation on a per-policy basis, which means the geolocation configuration affects the entire network scope configured for a specific policy. Enabling geolocation for a security policy exposes the public /24 subnet of a DFP, External Network or Infoblox Endpoint to the authoritative DNS server. If you do not want to expose the public /24 subnet to external DNS name servers, do not enable geolocation when you configure a security policy. Geolocation is disabled by default, and new policies will inherit the geolocation configuration of the default policy.

Note: Infoblox maintains a list of domains that support geolocation-based responses. Infoblox Threat Defense will only forward public /24 subnet ECS data to domains that are on this list. Queries for domains that are not on this list will not have ECS data forwarded regardless of whether geolocation is enabled or not. If you encounter issues while configuring geolocation, contact Infoblox Technical Support.

Google's page on ECS

Most of the domains don’t support ECS (i.e. No ECS supported by the domain auth server). From security perspective, it is not a good idea to share ECS with everyone, including malicious actors.

There is a performance impact on the cache layer due to the overload of the domains in the ECS list. End users shouldn’t really care/know about that.

When using NIOS-XaaS, if you have DNS and DFP and enable Geolocation, the target will get the source IP of the DFP POP and the EDNS0 subnet of the XaaS POP.

This is because when you query the XaaS DNS server, it then forwards to the Threat Defense POP.

• google.com
• 3dzip.org
• youtube.com
• outlook.office365.com
• infoblox.lightning.force.com
• outlook.office365.com

To show Google sees EDNS0 data, run the following:

dig +short @8.8.8.8 +subnet=41.33.12.0/24 TXT o-o.myaddr.l.google.com

Results

C:\Users\owner>dig +short @8.8.8.8 +subnet=41.33.12.0/24 TXT o-o.myaddr.l.google.com
"54.56.57.58"
"edns0-client-subnet 41.33.12.0/24"

The run again via Infoblox Threat Defense. If Threat Defense has Geolocation enabled, you should get your public subnet in the response.

dig +short @<DNS_server_IP> TXT o-o.myaddr.l.google.com

Results

C:\Users\owner>dig +short @127.0.0.1 TXT o-o.myaddr.l.google.com
"edns0-client-subnet 54.56.57.0/24"
"13.42.84.27"

In the example above,13.42.84.27 is the IP of Infoblox Threat Defense egress IP from its London POP in 2025 and 54.56.57.0/24 is an example of the public IP of the next that the test was actually run on. This shows that Infoblox Threat Defense took the public subnet and included it in the query to Google.

However, if you disable geo-location but then add subnet data to your query (e.g. +subnet=10.10.10.0/24 when using the dig command), then the subnet is copied when querying domains on the GeoLocation list (albeit that the /24 is converted to a /32. e.g. 10.10.10.0/32). Difficult to determine if this is true for other domains as well.

If geolocation is enabled and you use +subnet, then you value is copied and Threat Defense will not add your actual public IP.