This article covers that functionality, typical deployment scenarios, features, and configuration. A reference is provided that covers DNS configuration via the UI.

Functionality

1. Hosting GSLB Service DNS Entries

The Avi DNS virtual service can host GSLB service DNS entries, and automatically update its responses based on factors such as application service health, service load and proximity of clients to sites implementing the application service. Avi GSLB automatically populates these DNS entries. Details of Avi GSLB are available in these articles:

3. Hosting Manual or Static DNS Entries

Avi DNS can host manual static DNS entries. For a given FQDN, the user can configure an A, SRV, or CNAME record to be returned.

4. DNS Load Balancing

In this scenario, Avi SEs proxy DNS requests to a back-end pool of DNS servers. A virtual service with a System-DNS (or similar) application profile is defined per usual. For it, a pool of back-end servers must be assigned, loaded with any one of many available DNS server software packages.

Avi DNS as a Virtual Service

Avi DNS runs a virtual service with the application profile type of System-DNS and a network profile using per-packet load balancing.

Referring to the diagram below, a DNS service — shown in green— is hosted on the leftmost SE. The DNS VS responds to DNS queries if there is a matching entry. If a matching entry is not found and if pool members are configured, the DNS VS forwards the request to the back-end DNS pool servers (shown in blue).

Restriction: In release 16.3, once an SE-local DNS service is run/placed on an SE, no other virtual service placements on that SE — or its group — are permitted.

An Avi DNS virtual service can act as an authoritative DNS server for one or more subdomains (zones). As with any other Avi virtual services, analytics and client logs are supported.

Prior to the 16.3 release, Avi supported the addition of virtual service domain entries and service discovery entries on a DNS server hosted on the Avi Controller. This is deprecated in 16.3 and will be unsupported starting in the 17.1 release, With 17.1, existing Avi-Controller-resident entries are migrated to Service Engines.

Typical Avi DNS Deployment Scenarios

1. Avi DNS Service as Authoritative Name Server for a Subdomain (Zone)

In this scenario, the corporate name server delegates one or more subdomains (avi.acme.com and gslb.acme.com in the below-pictured case) to the Avi DNS service, which in turn acts as an authoritative DNS server for them. Typically, the corporate name server will have an NS record pointing to the Avi DNS service (10.100.10.50). Client queries for these subdomains are sent directly to Avi Vantage, whereas all DNS requests outside of acme.com are instead sent to the external “.com” name server.

2. Avi DNS Service as Primary Name Server for a Domain, with Pass-through to Corporate Name Server

In this scenario, Avi DNS is the first in line; it responds to any zones it has been configured to support. DNS queries that don’t match Avi DNS records pass through (proxy) to corporate DNS servers via a virtual service pool created for that purpose. If members of that pool receive DNS requests outside the corporate domain (acme.com in this case), they send them to their external “.com” name server.

3. Avi DNS Load Balancing

In this very basic, traditional scenario, the corporate DNS servers are pooled together and exposed by an Avi SE group as a single, scaled DNS service. Like any other VS, analytics and logs are available.

Features

Visibility and Analytics

After navigating to the Applications-> Virtual Services, one can click on the name of a virtual service configured for DNS, DNS-Site-US-East in the screenshot immediately below.

DNS Health Monitoring

Additional Features

Domain filtering drops requests for any domains that are not explicitly configured on the DNS service (the default setting is to allow all domains).

The time-to-live (TTL) can be customized (default is 30 seconds).

Network security policy can be based on client (source) IP and port.

With a full TCP proxy, client spoofing is prevented for TCP DNS queries. SYN flood attacks are mitigated.

One can opt to respond to failed DNS requests by returning a DNS error code or dropping the packets.

DNS Configuration

Regardless of use case, DNS virtual service configuration begins with the Advanced Wizard. The operative field below is Application Profile, which needs to be set to System-DNS (or some alternative DNS-oriented profile the user defines).

Illustrated below is the application profile editor. Setting the Type field to DNS brings up basic and request rate limiter settings by which to customize the behavior of Avi DNS when other than default behavior is desired.

Basic Settiings

Preserve Client IP Address is off by default. Setting it causes the client’s IP to be used for the connection to the back-end server pool, a behavior which is incompatible with connection multiplexing.

Valid subdomains are those domains this DNS is prepared to resolve into IP addresses. These are configured with Ends-With semantics.

Error Response is “None, i.e., off by default (no response is sent back and client request will be timed out). If set to “Error,” then if the DNS service encounters an error when processing the query, it returns that error to the requesting client.

Number of IPs returned by DNS server defaults to 1, but can be set as high as 20. If set to 0, this DNS will return all available IPs (A records) to the requesting client. On a per-GSLB-service, this general value may be overridden (see Avi GSLB Service Health Monitors).

TTL is the time-to-live in seconds (1 to 86400) for records served by this DNS. On a per-GSLB-service, this general value may be overridden (see Avi GSLB Service Health Monitors).

Threshold is the maximum number (10 to 2500) of DNS requests any single client IP address may make during a specified contiguous span of time before rate limiting will begin.

Time Period is the contiguous span of time, a moving time window (number of seconds, field value can range from 1 to 300) over which Avi Vantage looks for the threshold to be exceeded. Put another way, Avi will calculate and take a specified action if the inbound request rate is exceeded. That rate is the ratio max-number / time-span.

Action is one of three to be taken when rate limiting must begin:

Only report that the threshold has been exceeded.

Drop SYN packets to limit the inbound rate (only if this DNS VS is configured to listen to on TCP).

Send TCP RST to limit the inbound rate (only if this DNS VS is configured to listen to on TCP).

With or without a back-end pool of DNS servers selected in the Advanced VS wizard, configuration proceeds as normal with options to define policies, analytics, and advanced settings. These are the typical ones would expect when configuring any virtual service.

Note: In the Advanced tab, one can identify the SE group on which the DNS VS will be placed. It is recommended that no other virtual services be placed on such a group.

DNS for Avi-hosted Virtual Services

Avi-SE-hosted DNS virtual services translate the FQDNs of Avi-Vantage-hosted virtual services into IP addresses. No pool need be assigned; the translation is done completely within the SE VMs. Navigate to the Administration -> Settings -> DNS Service tab to choose from among the defined DNS virtual services. In the below screenshot, the user has chosen to select “Create Virtual Service,” rather than select the pre-existing DNS-Site-US-East.

DNS for GSLB

A DNS as defined above is suitable for GSLB as well. Note: A given DNS’s participation in a GSLB configuration is not a property of the DNS virtual service object itself. Rather, it is a property of the Avi GSLB site object. As part of the GSLB site configuration, some pre-existing DNS service(s) is(are) designated to serve in the role. This is illustrated in the following GUI screenshots. See also Avi GSLB Site Configuration and Operations.

Step 1: Navigate to Infrastructure -> GSLB and click the Add New Site button in the Site Configuration tab.

Step 2: When the New GSLB Site editor appears, complete all fields. You must click the Active Member option to enable the Save and Set DNS Virtual Service button. Click on it.

Step 3: Select from one or more DNS virtual services in the pulldown and click Save to identify it as a participant in the GSLB configuration.

This below screenshot illustrates the case where there are no DNS virtual services from which to choose. An active GSLB site does not require a DNS, though it may be preferred, as described in the next section.

High Availability Recommendations

As with any other virtual service, the first step toward achieving HA is to configure DNS for GSLB on an SE group that is scalable to two or more SEs. In addition, to protect against whole-site failures, Avi recommends running DNS for GSLB in more than one location. This can be achieved two ways:

Have at least two geographically separated active GSLB sites, and for each configure a DNS onto a scalable SE group.

If only one active site is defined, for it define at least one geographically remote cloud (e.g., AWS). On that remote cloud, configure DNS for GSLB on a scalable SE group. Also define all application virtual services to support the mission-critical apps running on the origin location.