Page tree

Contents

DNS Forwarding Proxy (DFP), which can be run on the on-prem host, is a DNS forwarder that sends DNS queries to BloxOne Threat Defense Cloud or to a local DNS server. DFP continually monitors connectivity to BloxOne Threat Defense Cloud. For customers of BloxOne Threat Defense who purchased BloxOne Threat Defense Business Cloud or BloxOne Threat Defense Advanced, if the on-prem host cannot reach the BloxOne Threat Defense Cloud Anycast DNS server, it will send requests to a local DNS server. 


DNS Forwarding Proxy (DFP) Health Check

  1. Before a health check is performed, the DNS Forwarding Proxy (DFP) starts up with an unhealthy status . This initial unhealthy status sets the following status message to the Cloud Services Platform: “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.
  2. In the normal flow, if the cloud successfully responds to DNS messages from clients, the DFP does not perform any additional health check.
  3. If clients do not send DNS queries, the DFP 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 the client query might take up to 20 seconds. If the query fails, that is, if the response is not received within 20 seconds then DFP starts sending probe queries to the failed BloxOne Threat Defense Cloud endpoint. Additional 10 seconds might elapse before the unavailable endpoint is considered unhealthy.
  5. Usually, the DFP is configured with several BloxOne Threat Defense Cloud endpoints: 
    1. If the first endpoint in the list of endpoints is unhealthy, the DFP sends client queries to the next endpoint.
    2. If all BloxOne Threat Defense Cloud  endpoints are unavailable, the DFP reports the status to CSP, such as the following: “DNS Service is not able to resolve domains. ATC endpoint 52.119.40.100:443 is unreachable.” 

         Further behavior of the DFP depends on the configuration of the DNS fallback resolver. 

    1. If the first endpoint in the list of endpoints is unhealthy, the DFP sends client queries to the next endpoint.
    2. If all BloxOne Threat Defense Cloud  endpoints are unavailable, the DFP reports the status to CSP, such as the following: “DNS Service is not able to resolve domains. ATC endpoint 52.119.40.100:443 is unreachable.”

      6. DFP continues sending 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 DFP: dig.ns.

Fallback Workflow

If the Fallback DNS is configured, when the BloxOne Threat Defense Cloud becomes unhealthy, the DFP will fall back to the Fallback DNS server.

  1. The DFP does not consider a BloxOneThreat Defense Cloud endpoint unhealthy immediately after the client query fails. In this case, the DFP starts sending probe DNS queries to this endpoint. Only after getting three failed probe queries in a row will DFP consider the endpoint unhealthy and stop sending probe queries to the clients. It might take up to 10 seconds before the DFP considers the endpoint unhealthy. Normally, the DFP 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.2. If the DFP is configured to fall back to NIOS resolution.
  2. If the Fallback DNS 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 3There 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 DFP is unhealthy due to unreachability of the BloxOne Threat Defense Cloud, then NIOS will resolve queries recursively.

Note

When "Fallback to the default resolution process if BloxOne Threat Defense cloud does not respond" for DFP on NIOS 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 we uncheck this option on NIOS, the BIND statement will have "forward only" which means that it will always send queries to BloxOne cloud.


Image 1DFP 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 DFP is unhealthy due to being unreachable, NIOS will resolve queries recursively.

Maximum Number of Concurrent DNS Queries

DFP 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

DFP 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 DFP 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

This page has no comments.