The DNS forwarding proxy is a DNS forwarder that sends DNS queries to BloxOne Threat Defense Cloud or to a local DNS server. When you enable the DNS Forwarding Proxy service on a host, the DNS forwarding proxy continually monitors connectivity to BloxOne Threat Defense Cloud. If you have purchased BloxOne Threat Defense Business Cloud or BloxOne Threat Defense Advanced, you can configure the host to run the DNS Forwarding Proxy service, so if the host cannot reach BloxOne Threat Defense Cloud, it can send DNS requests to a local DNS server. Infoblox require the configuration of a fallback DNS service for the unlikely scenario where communications to the Infoblox network are disrupted.
DNS Forwarding Proxy Health Check
- The DNS Forwarding Proxy starts up with an unhealthy status before it performs a health check. This initial unhealthy status sends the following status message to the Cloud Services Portal: “DNS Service is not ready.” If BloxOne Threat Defense Cloud DNS endpoints or Anycast are available, up to one minute might pass before the status changes to healthy.
- If BloxOne Threat Defense Cloud successfully responds to DNS messages from the clients, the DNS forwarding proxy does not perform additional health checks.
- If clients do not send DNS queries, the DNS forwarding proxy sends its own probe queries to the cloud to check whether it is available. The time interval between each query is approximately 10 seconds.
- Resolution of DNS queries might take up to 20 seconds. If a query fails, that is, if the response is not received within 20 seconds, then the DNS forwarding proxy starts sending probe queries to the failed BloxOne Threat Defense Cloud endpoint. An additional 10 seconds might elapse before the unavailable endpoint is considered unhealthy.
- Typically, the DNS forwarding proxy is configured with several BloxOne Threat Defense Cloud endpoints. The following happens to multliple endpoints:
- If the first endpoint on the list is unhealthy, the DNS forwarding proxy sends client queries to the next endpoint.
- If all endpoints are unavailable, the DNS forwarding proxy reports the status to the Cloud Services Portal, such as the following: “DNS Service is not able to resolve domains. endpoint 52.119.40.100:443 is unreachable.
- Further behavior of the DNS forwarding proxy depends on the configuration of the DNS fallback resolver
- DNS forwarding proxy continues to send probe queries to the BloxOne Threat Defense Cloud endpoints. When it detects that a BloxOne Threat Defense Cloud endpoint is available, it starts sending DNS traffic to the cloud again. Up to one minute might elapse before the cloud endpoints become available and the DNS traffic is routed to the cloud.
| Note | ||
|---|---|---|
| ||
The health check tests for the availability of BloxOne Threat Defense Cloud resolvers. It does not test availability of local resolvers intended for resolving internal domains. The following root domain is used when performing a health check on DNS forwarding proxy: dig.ns. |
DNS Fallback
If DNS Fallback is enabled and when the BloxOne Threat Defense Cloud becomes unhealthy, the DNS forwarding proxy will fall back to the local DNS server.
- The DNS forwarding proxy does not consider a BloxOne Threat Defense Cloud endpoint unhealthy immediately after the client query fails. In this case, the DNS forwarding proxy starts sending probe DNS queries to this endpoint. Only after getting three failed probe queries in a row will DNS forwarding proxy consider the endpoint unhealthy and stop sending probe queries to the clients. It might take up to 10 seconds before the DNS forwarding proxy considers the endpoint unhealthy. Normally, the DNS forwarding proxy is configured with several BloxOne Threat Defense Cloud endpoints, such as 52.119.40.100:443 and 103.80.5.100:443. Thus, the client query is sent to the next healthy upstream endpoint. After all BloxOne Threat Defense Cloud endpoints are considered unhealthy, the client query is sent to the fallback resolver.
- If the DNS forwarding proxy is configured to fall back to NIOS resolution (Image 1), NIOS forwards the queries to the root servers (Image 2) for configuring root servers on NIOS. To enable recursion on NIOS, see Image 3. There are other ways of configuring DNS resolution on NIOS if desired, but this is the easiest approach: If a fallback is configured on NIOS, and if the DNS forwarding proxy is unhealthy due to unreachability of the BloxOne Threat Defense Cloud, then NIOS will resolve queries recursively.
| Note | ||
|---|---|---|
| ||
| In NIOS, when "Fallback to the default resolution process if BloxOne Threat Defense cloud does not respond" is selected, the BIND/NAMED configuration will have a "forward first" statement which means that it will fall back to root hints if BloxOne Cloud is not reachable or not responding. When you deselect this option in NIOS, the BIND statement will have "forward only," which means that it will always send queries to BloxOne cloudCloud. |
Image 1: DNS forwarding proxy fallback to default resolution
Image 2: NIOS root name servers configuration
Image 3: Enabling recursion on NIOS
While there are other ways of configuring DNS resolution on NIOS, this is the easiest approach. If a fallback is configured on NIOS, and DNS forwarding proxy is unhealthy due to being unreachable, NIOS will resolve queries recursively.
Maximum Number of Concurrent DNS Queries
DNS forwarding proxy can process up to 10,000 concurrent DNS queries. If this limit is exceeded, the client will receive a DNS response with the response code SERVFAIL.
Maximum Number of TCP Connections
DNS forwarding proxy can serve multiple DNS queries through a single TCP connection sequentially: that is, by handling one DNS query at a time. However, if a client sends multiple queries simultaneously, the DNS forwarding proxy can establish more than one connection. The maximum number of TCP connections is tied to the maximum allowed number of concurrent DNS queries: 10,000.