Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

The DNS forwarding proxy is a DNS forwarder that sends DNS queries to BloxOne Threat Defense 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. 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, 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

  1. 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 Cloud DNS endpoints or Anycast are available, up to one minute might pass before the status changes to healthy.
  2. If BloxOne Threat Defense successfully responds to DNS messages from the clients, the DNS forwarding proxy does not perform additional health checks.
  3. 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.
  4. 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 endpoint. An additional 10 seconds might elapse before the unavailable endpoint is considered unhealthy.
  5. Typically, the DNS forwarding proxy is configured with several BloxOne endpoints. The following happens to multliple endpoints: 
    1. If the first endpoint on the list is unhealthy, the DNS forwarding proxy sends client queries to the next endpoint.
    2. 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.
    3. Further behavior of the DNS forwarding proxy depends on the configuration of the DNS fallback resolver
  6. DNS forwarding proxy continues to send probe queries to the BloxOne Cloud endpoints. When it detects that a BloxOne Threat Defense 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 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 becomes unhealthy, the DNS forwarding proxy will fall back to the local DNS server.

  1. The DNS forwarding proxy does not consider a BloxOne 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 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 endpoints are considered unhealthy, the client query is sent to the fallback resolver.
  2. 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, then NIOS will resolve queries recursively.

Note

In NIOS, when "Fallback to the default resolution process if BloxOne Threat Defense 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 Cloud.


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.






  • No labels