Avi DNS Architecture and Features


The Avi DNS virtual service is a generic DNS infrastructure that can implement the following functionality. The hyperlinks lead to four sections within this article.

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


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:

2. Virtual Service IP Address DNS Hosting

Avi DNS can host the names and IP addresses of the virtual services configured in Avi Vantage itself (i.e., Avi is the DNS provider for the virtual services hosted on Avi Vantage).

Details of configuring this can be found in Service Discovery Using IPAM and DNS.

SRV records in a container ecosystem (e.g., Mesos, Kubernetes, others) can also be hosted on the DNS service. For more information, please refer to DNS-based Service Discovery for Mesos and Installing Avi Vantage in OpenShift/Kubernetes.

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, CNAME, or NS 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).

DNS virtual service supports elastic HA (active/active and M+N). Legacy HA is not supported.

Avi Vantage can be configured with more than one DNS virtual service.

Avi DNS service runs on SE as well as back-end servers
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.

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 ( 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.

Avi DNS as authoritative name server for a zone

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.

Avi DNS as primary name server - pass-through to corporate 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.

basic DNS load balancing


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.

Screen Shot 2016-12-31 at 8.30.19 PM

Seven tabs (Analytics, Logs, Health, Security, Events, Alerts, and DNS Records) are revealed, as shown in the below figure.

Per usual, the Analytics tab of the DNS virtual service page offers metrics of interest (as seen in the red box of metrics tiles). 

Screen Shot 2017-01-26 at 2.43.24 PM

The Logs tab (shown below) provides detailed information about DNS queries from clients, including FQDN, query-type, significant errors, responses (IP-addresses, CNAME, SRV, etc.).

Screen Shot 2016-12-31 at 8.49.05 PM

A Note on Log Settings

  • Non-significant logs should be enabled with caution, since a large number of DNS queries typically hit a DNS service, and this would result in too many logs entries.
  • Categorization of non-significant logs is also very important. If certain errors are typical in the deployment, these errors should be excluded from significant logs.
  • Refer to Exclude DNS Error for more details on the exclude DNS errors section.

Pop-ups appear by clicking one of 12 options in the Log Analytics selector (see red box above). Some examples follow.

1. DNS-Logs-with-Top-FQDNs


2. DNS-Logs-with-Top-IP-Address


3. DNS-Logs-with-Top-Query-Types


4. DNS-Logs-with-Response-Lengths


In the above,

  • Detailed analytics is not available for TCP. This is planned for a future release.
  • DNS requests can be filtered by sub-domain name. Support for additional filtering (e.g., request-type) is planned for a future release.
  • NO-DATA may occasionally appear when a metric tile is selected. This typically implies “Not Applicable.” For example a GSLB service name may not be applicable for the DNS proxy or a static entry.

The DNS Records tab is unique to this kind of virtual service.

Screen Shot 2016-12-31 at 9.40.34 PM

DNS Health Monitoring

DNS health monitors can be configured to monitor the health of DNS servers that are configured as DNS service pool members.

Refer to the DNS Health Monitor article for more details.

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).

Advanced VS wizard.settings

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.

DNS Application Profile

Basic Settings

  • 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).

DNS Request Rate Limiter Settings (Rate Limit Connections from a Client)

  • 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.


  1. A complete discussion of all settings relevant to configuration of a DNS service can be found in the DNS Profile section of the Application Profile article.
  2. 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.

Screen Shot 2017-01-27 at 4.13.27 PM

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.

Screen Shot 2016-12-31 at 3.41.52 PM

For more information on configuration steps for DNS virtual services, please refer to the configure local DNS virtual service on all active sites that host DNS section of Avi GSLB Site Configuration and Operations.


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.

Screen Shot 2017-01-26 at 3.58.46 PM

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.

GSLB site editor

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.

Screen Shot 2017-01-26 at 4.59.50 PM

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.

select an existing DNS for the GSLB site

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:

  1. Have at least two geographically separated active GSLB sites, and for each configure a DNS onto a scalable SE group.
  2. 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.