--- title: "Forwarding DNS Traffic to Infoblox Platform" canonical: "https://docs.infoblox.com/space/BloxOneThreatDefense/35408116/Forwarding%20DNS%20Traffic%20to%20Infoblox%20Platform" format: markdown --- To access Infoblox Platform DNS service, you must forward your DNS traffic (except for internal domain resolution) to the Infoblox Platform name server. In essence, a DNS forwarder is a name server to which all other name servers first send queries that they cannot resolve locally. The forwarder then sends these queries to DNS servers external to the network, and this saves the other name servers in your network from having to send queries off site. A forwarder eventually builds up a cache of information and uses it to resolve queries. This reduces Internet traffic over the network and decreases the time taken to respond to DNS clients. Depending on your network configuration, you can forward DNS traffic while configuring the following network scopes for protection: - *[External Networks](https://infoblox-docs.atlassian.net/wiki/spaces/BloxOneThreatDefense/pages/35473665)* - *[DFP (DNS Forwarding Proxy)](https://infoblox-docs.atlassian.net/wiki/spaces/BloxOneThreatDefense/pages/35436408)* (either standalone or running on NIOS) - *[Configuring DNS Forwarding Proxy Settings](https://infoblox-docs.atlassian.net/wiki/spaces/BloxOneInfrastructure/pages/166134245)* - *[The Infoblox DNS over HTTPS (DoH) Solution](https://infoblox-docs.atlassian.net/wiki/spaces/BloxOneThreatDefense/pages/35403640)* - *[Implementation Recommendations for DoT](https://docs.infoblox.com/space/BloxOneThreatDefense/1308000818/Implementation+Recommendations+for+DoT)* - *[Infoblox Endpoint](https://infoblox-docs.atlassian.net/wiki/spaces/BloxOneThreatDefense/pages/35374260)* or *[Infoblox Mobile Endpoint](https://infoblox-docs.atlassian.net/wiki/spaces/BloxOneThreatDefense/pages/35470955)* The manner in which you configure your DNS forwarders to use the Infoblox Threat Defense name server depends on your network configuration: - If you have an on-prem Infoblox Grid, configure your Grid members (which act as DNS forwarders) to use the Infoblox Threat Defense name server. - If you are using Unbound, BIND, or any other third-party DNS server as your DNS resolver, then, in your DNS configuration file, configure your DNS forwarders to use the Infoblox Threat Defense name server IP. - You can also configure Microsoft servers to use DNS forwarders. - In corporate mode, Infoblox Endpoint supports transfer of metadata to Infoblox Platform when queries are resolved by DFP. If you are forwarding DNS traffic to the Infoblox Threat Defense name servers using the External Networks configuration, without Infoblox Endpoint or DFP, you should provision the following DNS anycast addresses: **52.119.41.100** and **103.80.6.100**. Do note that the following IP addresses, **52.119.40.100** and **103.80.5.100**, are considered legacy/back up with limited availability on a regional level (PoPs). - While all Anycast IP addresses are valid and provide redundancy for our customers, Infoblox recommends using the **52.119.41.100** and **103.80.6.100** addresses. The** 52.119.40.100** and **103.80.5.100** addresses are considered legacy. - The **52.119.41.100** and **103.80.6.100** addresses are provisioned under Anycast, so a DNS client can connect to the nearest entry location. Once a connection is established, the client is routed via to the nearest PoP (Point of Presence). If the nearest PoP is not reachable, the client is forwarded to another PoP based on the rules described in the bullet point described below: - By default, the DFP has provisioned the following four IPv4 global addresses. The DFP monitors the health status of these addresses and sends DNS requests to the first available and healthy address in the following order. In other words, if the first IP address (**103.80.6.100**) is available but has an unhealthy status, it moves on to the second IP address (**103.80.5.100**) to establish a connection with Infoblox Platform provided that the address is reachable and has a healthy status. Note that the DFP performs periodic health checks on these addresses. - The **52.119.40.100** and **103.80.5.100** addresses are routed using Anycast only, and they use a different architecture so the traffic is routed via third-party networks to a PoP. - IPv6 DNS anycast addresses **2400:4840::100** and **2620:129:6000::100**. For best practices when configuring DNS forwarding, see the following topics: - *[Connectivity Rules for DNS Forwarding Proxy](https://infoblox-docs.atlassian.net/wiki/spaces/BloxOneThreatDefense/pages/257754727)* - *[DNS Forwarding Proxy Fallback to Local DNS Server](https://infoblox-docs.atlassian.net/wiki/pages/createpage.action?spaceKey=BloxOneThreatDefense&title=DNS%20Forwarding%20Proxy%20Fallback%20to%20Local%20DNS%20Server)* # Infoblox Geo-Based Anycast IPs for POPs Infoblox-provided anycast addresses (listed above) will route your DNS traffic to the appropriate PoPs. > ℹ️ - Infoblox recommends updating network firewall access lists to allow access to the Anycast addresses (52.119.41.100, 103.80.6.100 and regional addresses). Additionally, those using NIOS or third-party DNS servers should update their configurations to forward traffic to these new addresses. > ℹ️ - The Hong Kong PoP is available only via regional IP addresses or manual DFP and Endpoint Group settings. It is not part of the Global Anycast IP addresses. ![The geographic locations of Infoblox PoP servers.](media://0783c163-c7d1-48b5-b2ae-d10be2462d4f) If you want to direct DNS traffic to a specific location, you can use the geo-based anycast IPs listed in the following table. | ## **Infoblox Geo-based Anycast IPs for POPs  ** | | --- | | ### Location | ### IPv4 Address | ### Secondary IPv4 Address | ### FQDN or DoT/DoH FQDN | | California (USA) | 52.119.41.51 | 103.80.6.51 | us-west-1-geo.threatdefense.infoblox.com | | Virginia (USA) | 52.119.41.52 | 103.80.6.52 | us-east-1-geo.threatdefense.infoblox.com | | London (England) | 52.119.41.53 | 103.80.6.53 | eu-west-2-geo.threatdefense.infoblox.com | | Frankfurt (Germany) | 52.119.41.54 | 103.80.6.54 | eu-central-1-geo.threatdefense.infoblox.com | | Mumbai (India) | 52.119.41.55 | 103.80.6.55 | ap-south-1-geo.threatdefense.infoblox.com | | Tokyo (Japan) | 52.119.41.56 | 103.80.6.56 | ap-northeast-1-geo.threatdefense.infoblox.com | | Singapore | 52.119.41.57 | 103.80.6.57 | ap-southeast-1-geo.threatdefense.infoblox.com | | Toronto (Canada) | 52.119.41.58 | 103.80.6.58 | ca-central-1-geo.threatdefense.infoblox.com | | Sydney (Australia) | 52.119.41.59 | 103.80.6.59 | ap-southeast-2-geo.threatdefense.infoblox.com | | São Paulo (Brazil) | 52.119.41.60 | 103.80.6.60 | sa-east-1-geo.threatdefense.infoblox.com | | Bahrain | 52.119.41.61 | 103.80.6.61 | me-south-1-geo.threatdefense.infoblox.com | | Cape Town (South Africa) | 52.119.41.62 | 103.80.6.62 | af-south-1-geo.threatdefense.infoblox.com | | Ohio (USA) | 52.119.41.63 | 103.80.6.63 | us-east-2-geo.threatdefense.infoblox.com | | Hyderabad, India | 52.119.41.64 | 103.80.6.64 | ap-south-1-geo.threatdefense.infoblox.com | | Hong Kong | 52.119.41.65 | 103.80.6.65 | ap-east-1-geo.threatdefense.infoblox.com | > ❌ **Warning** > ❌ Before pointing your DNS to the Infoblox Threat Defense name server, ensure that your network and DNS server are properly configured to send DNS queries and receive responses. For more information, see *[Testing Network Configuration](https://infoblox-docs.atlassian.net/wiki/spaces/BloxOneThreatDefense/pages/35469886)*. # Local DNS Request Processing Optimization To reduce the number of requests forwarded to the cloud and to avoid misconfiguration, DFP and Infoblox Endpoint will automatically forward all PTR requests for any private subnets (e.g. 10.0.0.0/8, 192.168.0.0/16, etc.) to local DNS servers. You do not need to list such subnets in the internal domain lists or custom allow lists. The Endpoint agent considers all domains in the DNS Suffix search list configured on a device's network interfaces as internal domains. Queries for these domains will not be forwarded to Infoblox Threat Defense and are resolved using the local DNS resolver. These events will not reflect in DNS or Security Activity reports. ### Domains Excluded by Default The following domains are excluded by default. | ### Domains Excluded by Default | | | --- | --- | | local ipv4only.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa | 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa 254.169.in-addr.arpa c.f.ip6.arpa d.f.ip6.arpa 8.e.f.ip6.arpa 9.e.f.ip6.arpa a.e.f.ip6.arpa b.e.f.ip6.arpa | List of excluded domains (downloadable text file): > ⚠️ ### Note > ⚠️ > ⚠️ DFP will forward all private requests to a local DNS server by default when a local DNS server is provisioned on the DFP.