Avi DNS Policy

Overview

A DNS policy consists of rules which in turn consist of match targets and actions. The match targets are the various attributes of a DNS request, such as query type, query domain name, DNS transport protocol used, client IP originating the request, etc. The rule actions can vary from security actions, such as closing the connection, to response actions, such as generating an empty response, etc.

A DNS policy can be referenced by a Layer-4 DNS virtual service (L4 DNS VS) i.e., a virtual service which has an application profile of type DNS. As shown below, a single DNS VS can refer to a single DNS policy.

multiple DNS VS per policy and conversely

The DNS rule engine is executed for a DNS request only when a DNS request has been received and parsed successfully.

A DNS policy rule is said to be a hit for a DNS request if all the match targets of the rule evaluate to TRUE. If any match target of the rule does not evaluate to TRUE, then the rule is not considered a hit and the subsequent rule of the current policy (or, if there are no more rules in current policy, then the first rule of the next policy) is evaluated.

Note: For a DNS query, the DNS policy rules are applied first, before lookups into the database for GSLB and static DNS entries.

Rule matching in the DNS policy consists of the following match targets and actions.

Matches

1. Client IP

This 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 simply configuring a client IP rule match using the IP addresses associated with the particular geographical area, and a rule action of drop (see below).

a client IP match

2. 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 as well 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 not served by the DNS VS. This is achieved by simply configuring a rule with query domain name match using the desired unavailable domain names, and a rule action of drop (see below).

a client IP match

3. Query Type

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

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

b. 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 VS. This is achieved by simply configuring a rule query type match using the desired available query types, and a rule action of drop (see below). Thus, any query type not in the configured set will be dropped.

a client IP match

4. 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 to instead come over TCP. This is achieved by simply configuring a rule with transport protocol match using the UDP protocol as match, and a rule action of Empty Response with truncation TC bit set (see below). Thus, any query over UDP will receive an empty response with truncation TC bit set, leading the client to retransmit the query over TCP.

a client IP match

5. Rate Limiting (18.2.6+)

Via the REST API or UI, it is possible to specify a match which specifies the maximum number of DNS requests allowed in a period of time.

Actions

1. Access Control

This rule action allows a UDP DNS query to be processed or dropped. If the query arrives over TCP, it will be allowed or dropped, with the 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, the drop action is used in the rule.

2. Custom Response

This action allows a custom response to be 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.

Via the REST API and CLI, resource record sets are supported, permitting custom data to be inserted into the Answer, Authority, and Additional sections of the DNS response body. For details on RRsets, refer to RFC 1034, Domain Names — Concepts and Facilities.

Use cases

If the DNS entries in the DNS VS do not support AAAA records for IPv6 address and would like to hint that the client ask for A records, then a rule match is configured to catch AAAA DNS queries, and the response action is used in the rule action to generate an empty NOERROR response, causing the client to reissue the query for an A record.

Custom A, CNAME, NS and/or AAAA record types may be returned.

3. GSLB Site Selection

The DNS VS’s policy is configured so that a rule match may 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 may be identified as an alternative. If none of the fallback sites are healthy, and the is_preferred_site Boolean is True, the DNS VS picks a site based on the configured GSLB algorithm. Read more.

Use case

Imagine three GSLB sites, one in Paris, one in Lyons, and one in Antwerp. With Avi’s geolocation algorithm in play, a client situated in France, close to the French-Belgian border would normally be directed to Antwerp. However, since the client is in France, the GSLB-site-selection action instead returns the VIP of a site having the site name “FRANCE.”

4. Pool and Pool Group Selection

An Avi DNS virtual service may be configured with back-end DNS servers. Routing of requests to back-end DNS servers not members of the default pool requires definition of a pool or pool-group selection action. This feature is supported in the Avi REST API, CLI and UI.

Note: Pool selection is often referred to as pool switching.

Use case

It may be necessary to resolve a subset of DNS queries using DNS infrastructure residing in a remote cloud. Avi DNS VS can conditionally load balance such queries to one of the DNS servers in that remote cloud.

5. Rate Limiting (18.2.6+)

An Avi DNS virtual service may be configured to limit the rate at which DNS requests are accepted. User can specify the number of requests that can be allowed in a given time period. The action can be configured as either DROP or Report Only. If DROP is configured, the traffic exceeding the rate limit is dropped by the virtual service. If Report Only is configured, such traffic is passed through but marked as significant logs in the application logs.

Note: At the time of this writing, rate limiting is configured from the Avi REST API or CLI, not the UI.

Use Cases

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

Rule Configuration via the Avi UI

The configuration process is outlined below.

  1. Edit the DNS virtual service for which policy rules are to apply.

    Edit the DNS VS

  2. Clicking on the green button depicted above results in the following display. Avi Vantage gives the rule a default name, which can be changed to your liking.

    After clicking on the green plus icon, this screen appears

  3. To add the first of potentially several match conditions for the rule, click on the downward-pointing icon inside the field to reveal the choices:

    The matches drop-down menu

  4. To add the action for the rule, click on the downward-pointing icon inside the field to reveal the choices:

    The actions drop-down menu

  5. When done, click on Submit.

Avi CLI Commands and Data Structures

Note: The below 18.1.2 schema includes the type DNS_RECORD_AAAA, which is not supported in 17.2.12, as mentioned above.


 [admin:10-10-23-1]: dnspolicy:rule:action> new
 allow:
   allow: '(true | false) # Field Type: Optional'
   reset_conn: '(true | false) # Field Type: Optional'
 gslb_site_selection:
   fallback_site_names: <string>
   is_site_preferred: '(true | false) # Field Type: Optional'
   site_name: '<string> # Field Type: Optional'
 pool_switching:
   pool_group_uuid: '<string> # Field Type: Optional'
   pool_uuid: '<string> # Field Type: Optional'
 response:
   authoritative: '(true | false) # Field Type: Optional'
   rcode: '<choices: DNS_RCODE_NOERROR | DNS_RCODE_NXDOMAIN | NS_RCODE_YXDOMAIN |
     DNS_RCODE_REFUSED | DNS_RCODE_FORMERR | DNS_RCODE_YXRRSET | DNS_RCODE_NOTIMP |
     DNS_RCODE_NOTZONE | DNS_RCODE_SERVFAIL | DNS_RCODE_NXRRSET | DNS_RCODE_NOTAUTH>
     # Field Type: Optional'
   resource_record_sets:
   - resource_record_set:
       cname:
         cname: '<string> # Field Type: Required'
       fqdn: '<string> # Field Type: Optional'
       ip_addresses:
       - ip_address:
           addr: '<string> # Field Type: Required'
           type: '<choices: V4 | V6 | DNS> # Field Type: Required'
       nses:
       - ip_address:
           addr: '<string> # Field Type: Required'
           type: '<choices: V4 | V6 | DNS> # Field Type: Required'
         nsname: '<string> # Field Type: Required'
       ttl: '<integer> # Field Type: Optional'
       type: '<choices: DNS_RECORD_DNSKEY | DNS_RECORD_AAAA | DNS_RECORD_A | DNS_RECORD_OTHER
         | DNS_RECORD_AXFR | DNS_RECORD_SOA | DNS_RECORD_MX | DNS_RECORD_SRV | DNS_RECORD_HINFO
         | DNS_RECORD_RRSIG | DNS_RECORD_OPT | DNS_RECORD_ANY | DNS_RECORD_PTR | DNS_RECORD_RP
         | DNS_RECORD_TXT | DNS_RECORD_CNAME | DNS_RECORD_NS> 
          Field Type: Optional'
     section: '<choices: DNS_MESSAGE_SECTION_QUESTION | DNS_MESSAGE_SECTION_ADDITIONAL
       | DNS_MESSAGE_SECTION_AUTHORITY | DNS_MESSAGE_SECTION_ANSWER> 
       Field Type: Optional'
   truncation: '(true | false) # Field Type: Optional'
 [admin:10-10-23-1]: dnspolicy:rule:action> cancel
 Exited out of the submode without saving the result.

Processing of DNS Request both on SE and Backend Server

A DNS policy needs to be set based on any of the existing match criteria types with match action as either pool or pool group switching so that when a match is found, query will be sent to backend server for response

For instance, if there is a static record of type A for “foo.com” on SE, and if a DNS policy is configured stating if query matches “foo.com” action will be pool or pool group switching. In that case you will get response from pool or pool group switched server rather than record present on SE.

Another use case will be supporting record types of TXT, NS, and on, on a server which are not yet supported in GSLB services and redirect those queries to that backend server based on DNS policies.

Document Revision History

Date Change Summary
December 20, 2021 Added Processing of DNS Request both on SE and Backend Server section for 21.1.3