Matches

This section explains about rule matching in the DNS policy with match targets and actions.

Client IP

The match target matches the client IP address of the DNS query against a configured set of IP addresses. The IP address match can be against an implicit set of IP addresses, IP address ranges and IP prefixes, and/or a set of IP address group objects.

The client IP match operation supports the following match operations:

IS IN: evaluates to TRUE, if the client IP of the current DNS request is in the configured set of IP addresses.
IS NOT IN: evaluates to TRUE, if the client IP of the current DNS request is not in the configured set of IP addresses.

Use Case

A client IP match target can be used to block DNS queries emanating from a particular geographical area hosting a bad bot. This is achieved by configuring a rule client IP match using the IP addresses associated with the particular geographical area, and a rule action of drop.

Query Domain Name

This match target matches the query domain name in the DNS query request against the configured set of strings. The query domain name match target supports an implicit set of domain names as match targets and a set of string group objects.

The query name match operation supports the following match operations:

Begins With: evaluates to TRUE, if the query domain name of the current DNS request begins with any of the strings in the configured set of strings.
Does Not Begin With: evaluates to TRUE, if the query domain name of the current DNS request does not begin with any of the strings in the configured set of strings.
Contains: evaluates to TRUE, if the query domain name of the current DNS request contains any of the strings in the configured set of strings.
Does Not Contain: evaluates to TRUE, if the query domain name of the current DNS request contains none of the strings in the configured set of strings.
Ends: evaluates to TRUE, if the query domain name of the current DNS request ends with any of the strings in the configured set of strings.
Does Not End With: evaluates to TRUE, if the query domain name of the current DNS request does not end with any of the strings in the configured set of strings.
Equals: evaluates to TRUE, if the query domain name of the current DNS request equals any of the strings in the configured set of strings.
Does Not Equal: evaluates to TRUE, if the query domain name of the current DNS request equals none of the strings in the configured set of strings.

Use case

A query domain name match target can be used to block DNS queries for certain domains that are not served by the DNS virtual service. This is achieved by configuring a rule query domain name match using the desired unavailable domain names, and a rule action of drop.

Query Type

This match target matches the type of the DNS query against a configured set of query types (record types A, AAAA, CNAME, and so on). The query type match operation supports the following match operations:

Is In: evaluates to TRUE if the query type of the current DNS request is in the configured set of query types.
Is Not In: evaluates to TRUE if the query type of the current DNS request is not in the configured set of query types.

Use case

A query type match target can be used to block DNS queries not served by the DNS virtual service. This is achieved by configuring a rule query type match using the desired available query types, and a rule action of drop. Thus, any query type not in the configured set will be dropped.

DNS Transport Protocol

This match target matches the transport protocol carrying DNS query against configured set of transport protocols. The query type match operation supports the following match operations:

Is In: evaluates to TRUE, if the transport of the current DNS request is in the configured set of transport protocols.
Is Not In: evaluates to TRUE, if the transport of the current DNS request is not in the configured set of transport protocols.

Use Case

A query transport protocol match target can be used to redirect DNS queries over UDP instead of the TCP. This is achieved by configuring a rule transport protocol match using the UDP protocol as match, and rule action of Empty Response with truncation TC bit set. Thus, any query over UDP will receive an empty response with truncation TC bit set which allows the client to retransmit the query over TCP.

Rate Limiting

It is possible to identify a match which specifies the maximum number of DNS requests allowed in a period of time through the REST API or UI.

Actions

Access Control:: This rule action allows a UDP DNS query to be processed or dropped. If the query arrives over TCP then, it will be allowed or dropped with additional option of resetting the connection.

Use Case: If a rule match is configured to block DNS queries of types other than A, AAAA, CNAME, and SRV then, the drop action is used in the rule.

Custom Response:: This action allows a custom response that is sent for a DNS query request. The response can be controlled to set the response code RCODE, the Authority AA, and Truncation TC bit in the response. Through REST API and CLI, the resource record sets are supported, permits custom data to be inserted into the Answer, Authority, and additional sections of the DNS response body. For details on RRsets, see RFC 1034, Domain Names — Concepts and Facilities.

Use Cases: If the DNS entries in the DNS virtual service does not support AAAA records for IPv6 address and hints the client to request for A records then, a rule match is configured to catch the AAAA DNS queries and the response action is used in the rule action to generate an empty NOERROR response. This causes the client to reissue the query for an A record. The Custom A, CNAME, NS and/ or AAAA record types can be returned.

GSLB Site Selection:: The policy of the DNS virtual service is configured so that a rule match can override the usual GSLB-algorithm-based response. As a result of a match, one site is chosen from a set of IP addresses (each homed at a different GSLB site) that share a common site_name tag. If none of these are available, up to 16 fallback sites can be identified as an alternative. If none of the fallback sites are healthy and the is_preferred_site Boolean is TRUE, the DNS virtual service picks a site based on the configured GSLB algorithm. For more information, see GSLB Site Selection with Fallback and Preferred-Site Options topic in NSX Advanced Load BalancerGSLB guide.

Use case: Assume three GSLB sites, one each in Paris, Lyons, and Antwerp. With the geolocation algorithm of NSX Advanced Load Balancer, a client situated in France, close to the French-Belgian border is directed to Antwerp. However, since the client is in France, the GSLB-site-selection action returns the VIP of a site having the site name “FRANCE”.

Pool and Pool Group Selection:: An NSX Advanced Load Balancer DNS virtual service will be configured with backend DNS servers. Routing of requests to backend DNS servers but not the members of the default pool requires definition of a pool or pool-group selection action. This feature is supported in the NSX Advanced Load Balancer REST API, CLI and UI.

Note:

Pool selection is also referred to as pool switching.

Use Case: It might be necessary to resolve a subset of DNS queries using DNS infrastructure residing in a remote cloud. NSX Advanced Load Balancer DNS virtual service can conditionally load balance such queries to one of the DNS servers in the remote cloud.

GSLB Pool Selection: Starting with version 22.1.1, NSX Advanced Load Balancer has added a new action to select the GSLB pool using DNS policies.

It can be configured using CLI only. Below are the steps to select the GSLB pool as action in DNS policy:

[admin:ctrl]: > configure dnspolicy Demo 
Updating an existing object. Currently, the object is: 
+------------+------------------------------------------------+ 
| Field      | Value                                          | 
+------------+------------------------------------------------+ 
| uuid       | dnspolicy-e3aae711-7617-439f-912a-dea3945d39e1 | 
| name       | Demo                        | 
| tenant_ref | admin                                          | 
+------------+------------------------------------------------+ 
[admin:ctrl]: dnspolicy> rule 

New object being created 

[admin:ctrl]: dnspolicy:rule>  name "Rule 1" 

[admin:ctrl]: dnspolicy:rule>  index 1 

[admin:ctrl]: dnspolicy:rule> match 

[admin:ctrl]: dnspolicy:rule:match> geo_location 

[admin:ctrl]: dnspolicy:rule:match:geo_location> match_criteria IS_IN 

[admin:ctrl]: dnspolicy:rule:match:geo_location> geolocation_tag "East Coast" 

[admin:ctrl]: dnspolicy:rule:match:geo_location> save 

[admin:ctrl]: dnspolicy:rule:match> save 

[admin:ctrl]: dnspolicy:rule> action 

[admin:ctrl]: dnspolicy:rule:action> gs_group_selection 

[admin:ctrl]: dnspolicy:rule:action:gs_group_selection> group_name "GS-1-pool-2" 

[admin:ctrl]: dnspolicy:rule:action:gs_group_selection> save 

[admin:ctrl]: dnspolicy:rule:action> save 

[admin:ctrl]: dnspolicy:rule> save 

[admin:ctrl]: dnspolicy> save

Rate Limiting: A NSX Advanced Load Balancer DNS virtual service can be configured to limit the rate at which DNS requests are accepted. You can specify the number of requests that are allowed in a given time period. The action can be configured as either DROP or Report Only. If DROP is configured then, the traffic exceeding the rate limit is dropped by the virtual service. If Report Only is configured then, such traffic is passed through but marked as significant logs in the application logs.

Note:

The rate limiting is configured from the NSX Advanced Load Balancer REST API or CLI and not the UI.

Use Cases: DNS request rate limiting can be used to ensure quality of service and improved security.