Configuring DNS activity - BlueCat Integrity - 26.1.0

The following section outlines the steps to configure DNS activity.

1. Select the Servers tab in the sidebar, then select Servers.
2. Select the name of a server.
3. Select the Services tab.
4. Under Monitoring and analytics, locate the DNS activity service panel and select Edit service.
5. Under General, set the following parameters:
   • Enabled—select this check box to enable DNS Activity service; deselect this check box to disable DNS activity service.
     Note: When you enabled DNS activity, the firewall rules on the DNS/DHCP Server are modified to allow egress to the specified URI endpoint. Outbound traffic is allowed for the specified IP address.
     Attention: Enabling the DNS activity service can be resource intensive and might affect the performance of the DNS/DHCP Server.
   • Max buffered events—enter the maximum number of DNS events to be stored in the memory buffer. The maximum value is 64,000,000 events.
     Note: You can enter a value for this field based on the highest possible queries per second (QPS) that can be sent to the DNS/DHCP Server and how quickly the endpoint processes events. For example, if the highest possible QPS for your environment is 20,000 QPS, the value of this field can be set to 200,000 to ensure that 10 seconds of events are stored in the DNS Activity buffer in the event that the endpoint processes queries slowly.
6. On the Filters tab, set the following parameters (optional):
   Note: You can configure a maximum of 10 exclusion filters.

   • Category—select the categories of DNS events to exclude from logging. You can exclude DNS events based on Domain name, Query, Response, or Source address.
     Note:

     • You cannot configure the Query exclusion category with a value set to All and the Response exclusion category with a value set to All in the same DNS activity configuration.
     • When filtering content using the Query or Response categories, there are certain scenarios where event messages are not generated. For more information, refer to Scenarios: DNS activity event messages are not generated.
   • Value—if you have selected Query or Response as the exclusion Category, select the DNS message types that are to be excluded from being logged.
     The DNS message types that can be configured to be excluded are as follows:

     • All—excludes all queries or responses, regardless of message type.
     • Client—excludes client queries or responses.
     • Auth—excludes authoritative queries or responses.
     • Resolver—excludes resolver queries or responses.
     • Forwarder—excludes forwarder queries or responses.
     • Update—excludes update queries or responses.

     For more information on DNS message types, refer to Reference: DNS activity event message examples.

     If you have selected Domain name as the exclusion Category, enter domain names that are to be excluded from being logged.

     Note: Domain names only support wildcard characters at the left-most position. For example, *.example.com or *-host.example.com.

     If you have selected Source address as the exclusion Category, enter the IPv4 or IPv6 block in CIDR notation to be excluded from being logged.

   Attention:

   • Filter exclusions are enacted based on the order that they appear in. BlueCat recommends excluding content from a granular to a broad scope. For example, exclusions of queries should appear higher on the list before exclusions of top-level domains and sub-domains.
   • Filter exclusions of the same exclusion Category are grouped together when they are applied based on the first occurrence of the exclusion category. For example, if the following filters are added in the Filters section:
     • Source Address 10.10.10.0/24
     • Queries Client
     • Domain Name example.com
     • Source Address 10.10.11.0/24
     The filters are applied as follows:
     • Source Address 10.10.10.0/24, 10.10.11.0/24
     • Queries Client
     • Domain Name example.com
7. On the Destination tab, set the following parameters:
   • Sink type—select where the DNS activity data will be logged. You can log data to an HTTP endpoint, Splunk server, Kafka cluster, or Elasticsearch server.
     If you select HTTP, the following fields appear:

     • Healthcheck—select this check box to enable health check service; deselect this check box to disable health check service. Upon initialization, the healthcheck ensure that the downstream service is accessible and can accept the DNS query data.
     • Healthcheck URI—enter the URI of the HTTP endpoint that will be consuming the health check information.
       Note: The URI for the Healthcheck URI field must follow the format outlined in RFC2396.
     • Output URI—enter the URI of the HTTP endpoint that will be consuming the DNS query and response information.
       Note:

       • BlueCat recommends entering the IP address of the endpoint in this field. If you are entering a hostname, you must use a different DNS server as the resolver for that host. The DNS/DHCP server you are configuring DNS activity on can still be used as a resolver for clients, but cannot be used as a resolver for its own OS related lookups.
       • If the domain name is used in the URI, you must ensure that the domain name can be resolved on the DNS/DHCP Server.
       • The URI for the Output URI field must follow the format outlined in RFC2396.
     • Token—enter the bearer token used to authenticate with the HTTP endpoint.
     If you select Splunk, the following fields appear:

     • Healthcheck—select this check box to enable health check service; deselect this check box to disable health check service. Upon initialization, the healthcheck ensures that the downstream service is accessible and can accept the DNS query data.
       Note: When selecting this check box, the DNS/DHCP Server uses the default Splunk healthcheck endpoint at /services/collector/health/1.0.
     • Host—enter the URI of the Splunk HEC host. The standard format of the HEC URI in Splunk Enterprise is as follows:

       <protocol>://<FQDN or IP address of the host only>:<port>

       Note:

       • BlueCat recommends entering the IP address of the endpoint in this field. If you are entering a hostname, you must use a different DNS server as the resolver for that host. The DNS/DHCP server you are configuring DNS activity on can still be used as a resolver for clients, but cannot be used as a resolver for its own OS related lookups.
       • If the domain name is used in the URI, you must ensure that the domain name can be resolved on the DNS/DHCP Server.
       • Ensure that the HEC URI format is followed exactly as described above without adding or omitting any pieces. The port is required, even if default. Do not include extra slashes or folders in the URI.
       • The URI for the Host field must follow the format outlined in RFC2396.
     • Token—enter the Splunk HEC token.
     If you select Kafka, the following fields appear:

     • Healthcheck—select this check box to enable health check service; deselect this check box to disable health check service. Upon initialization, the healthcheck ensures that the downstream service is accessible and can accept the DNS query data.
       Note: The health check URI is configured based on the Kafka Broker address.
     • Topic—enter the name of the Kafka topic to write events to.
     • Key field—enter the log field name or tags key to use for the topic key. If the field does not exist in the log or in tags, a blank value will be used. If unspecified, the key is not sent. Kafka uses a hash of the key to choose the partition or uses round-robin if the record has no key.
     • Bootstrap servers—enter a host and port pair that is the address of the Kafka broker in a “bootstrap” Kafka cluster. This is the address that a Kafka client connects to initially to bootstrap itself. This field supports IPv4, IPv6, and FQDN values.

       Example: 10.14.22.123:9092

       Click + to add the host and port pair to the list of Bootstrap servers.

       Note:

       • BlueCat recommends using IP addresses in this field. If you are entering a hostname, you must use a different DNS server as the resolver for that host. The DNS/DHCP server you are configuring DNS activity on can still be used as a resolver for clients, but cannot be used as a resolver for its own OS related lookups.
       • Do not include http or https in the addresses of the Kafka brokers.
       • If a domain name is used, you must ensure that the domain name can be resolved on the DNS/DHCP Server.
     If you select Elasticsearch, the following fields appear:

     • Healthcheck—select this check box to enable health check service; deselect this check box to disable health check service. Upon initialization, the healthcheck ensures that the downstream service is accessible and can accept the DNS query data.
       Note: The health check URI is configured based on the Elasticsearch instance.
     • Endpoint—enter the Elasticsearch endpoint to send logs to. This field supports IPv4, IPv6, and FQDN values.

       Example: http://10.24.32.122:9000

       Example: https://example.com

       Example: https://user:password@example.com

       Note:

       • BlueCat recommends using the IP address of the endpoint in this field. If you are entering a hostname, you must use a different DNS server as the resolver for that host. The DNS/DHCP server you are configuring DNS activity on can still be used as a resolver for clients, but cannot be used as a resolver for its own OS related lookups.
       • If the domain name is used, you must ensure that the domain name can be resolved on the DNS/DHCP Server.
     • Index—enter Elasticsearch index name to write events to.
     • Username—enter the basic authentication user name.
     • Password—enter the basic authentication password.
8. On the Certificate tab, configure TLS information if necessary:
   Attention: If you enter a HTTPS endpoint in the Output URI, Healthcheck URI, Host, Bootstrap servers, or Endpoint field when configuring output, you must configure TLS information.

   • Select the Verify certificate check box to attempt a TLS handshake using the uploaded CA certificate with the remote host's TLS server certificate.
     Note: Verify certificate does not verify the authenticity of the uploaded certificate. Verify certificate in this context only checks if the CA certificate matches correctly with the TLS server certificate to create a successful handshake.
     Note: If encountering errors with Verify certificate, the CA/chain-CA certificates may have to be installed manually on the DNS/DHCP Server. Refer to KB-17944 on the BlueCat Customer Care portal for manual installation instructions.
   • Select the Verify hostname check box to validate the hostname part of the URI against the CN (Common Name) or SAN (Subject Alternative Name) of the server certificate during the TLS handshake.
     Note: If using self-signed certificates, users are advised to add a subject alternative name with the IP address (see RFC 5280 4.2.1.6), or disable the Verify hostname check.

   • Under CA certificate upload, drag and drop or select the CA certificate (trusted third party or self-signed) that will be used to authenticate the CA signature on the TLS server certificate of the remote host.
     Note: The file containing the CA certificate or certificate bundle must be in .pem, .cer, .cert, or .crt format. To ensure a successful TLS handshake, the CA certificate uploaded to the client (BDDS) should be the same CA certificate (and intermediate certificates if applicable) used by the server to authenticate the CA signature of its TLS server certificate. The CA certificate can be acquired via browser export or other trusted source, and converted to PEM format.
9. Select Save.
   If you do not have DNS service deployed to the DNS/DHCP Server, after you select Save, you must perform a DNS deployment on the DNS/DHCP Server for DNS activity events to be generated. If DNS service is already configured on the DNS/DHCP Server, the DNS activity service is enabled upon selecting Save.

   The service batches data that is sent to the configured destination. Batches are flushed from the system and sent to the configured destination when the age of the batch reaches 1 second, or when the size of the batch reaches 1049000 bytes.

   If the service receives an HTTP response status code of 429 or greater than 500 except for 501, the service attempts to retry sending the failed request 5 times. If the service still cannot send the failed request after 5 attempts, the event message is dropped and an error message is logged.