Avi DNS Architecture and Features

Overview

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.

On Avi Vantage, DNS virtual service primarily implements the following functionality:

Notes:

Starting with Avi Vantage release 18.1.2, static and virtual service AAAA records and pass-through/load-balancing of IPv6 queries are supported.
Starting with Avi Vantage release 20.1.1, Avi Vantage supports DNS TXT (text) record and MX (mail exchanger) record.

DNS Load Balancing

Avi Service Engines proxy DNS requests to a back-end pool of DNS servers. A virtual service with a System-DNS (or similar) application profile is defined as usual. For this, a pool of back-end servers loaded with DNS software packages must be assigned.

Hosting Manual or Static DNS Entries

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

Starting with Avi Vantage release 20.1.1, Avi Vantage supports text record (TXT) record and mail exchanger (MX) record.

TXT record: This is used to store text-based information for the configured domain.
MX record: This is used in mail delivery based on the configured domain.

Virtual Service IP Address DNS Hosting

Avi DNS can host the names and IP addresses of the virtual services configured in Avi Vantage. Avi Vantage serves as DNS provider for the hosted virtual services. For complete configuration details, refer to DNS Provider (Avi Vantage).

Hosting GSLB Service DNS Entries

The Avi DNS virtual service can host GSLB service DNS entries, and automatically update its responses based on the application service health, service load and proximity of clients to sites implementing the application service. Avi GSLB automatically populates these DNS entries. For more information on Avi GSLB, refer to:

Avi DNS as a Virtual Service

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

Referring to the diagram below, a DNS service — represented in green— is hosted on the leftmost Service Engine. The DNS virtual service 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 virtual service forwards the request to the back-end DNS pool servers (represented in blue).

DNS virtual service supports A/A, A/S and N+M with health monitoring support being added for DNS VS configured in active/standby mode in Avi Vantage release 18.2.5.

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

An Avi DNS virtual service can act as an authoritative DNS server for one or more subdomains (zones) and all analytics and client logs are supported.

Deployment Scenarios

This section discusses a few scenarios for deploying Avi DNS service.

Authoritative Name Server for a Subdomain (Zone)

In this scenario, the corporate name server delegates one or more subdomains to the Avi DNS service, which in turn acts as an authoritative DNS server for them. In the example shown below, avi.acme.com and gslb.acme.com are the subdomains. Typically, the corporate name server will have a 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.

Primary Name Server for a Domain

In this scenario, where there is a primary name server for a domain with pass-through to corporate name server Avi DNS responds to any zone it has been configured to support. DNS queries that do not 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.

Load Balancing

The corporate DNS servers are pooled together and exposed by an Avi SE group as a single, scaled DNS service.

Features

Visibility and Analytics

Navigate to Applications > Virtual Services and click on the name of a virtual service configured for DNS. For instance, DNS-Site-US-East as shown in the screenshot below.

Analytics, Logs, Health, Security, Events, Alerts, and DNS Records are the tabs revealed, as shown in the screenshot below.

The Analytics tab displays the required metrics.

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

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 a certain deployment, these errors should be excluded from significant logs.
Refer to Exclude DNS Error for more details on the exclude DNS errors section.

Click on one of the 12 options in the Log Analytics selector for relevant popups, as shown in the example below.

Note the followings

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, such as, 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 instance, 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 a virtual service.

DNS Record Search Option
Starting with NSX Advanced load balancer 22.1.3, the option to search DNS records for a DNS virtual service is available on NSX Advanced load balancer UI. This option is useful when there are multiple records, and it becomes difficult to find the specific entry to check if it is registered and receiving requests.

Health Monitoring

DNS health monitors can be configured to monitor the health of DNS servers that are configured as DNS service pool members. For complete information, refer to DNS Health Monitor.

Additional Features

Domain filtering drops requests for any domains that are not explicitly configured on the DNS service (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 full TCP proxy, client spoofing is prevented for TCP DNS queries. SYN flood attacks are mitigated.
You can respond to failed DNS requests by returning a DNS error code or dropping the packets.

Configuring DNS

Custom DNS Application Profile

Optionally create a custom DNS profile to be referenced when defining the DNS virtual service. Refer to the DNS Profile section of the Application Profile article.

DNS Virtual Service

Starting with release 18.1.2, the DNS virtual service can be configured with IPv4 VIP, IPv6 VIP, or a dual VIP.

Navigate to Applications > Virtual Services and click on Create Virtual Service (Advanced Setup). Configuration tabs associated with DNS are as explained below.

Settings

Under the Profiles section, choose either the default or the custom DNS profile from the dropdown list for Application Profile. Choose a suitable profile for the network settings under TCP/UDP Profile, such as System-UDP-Per-Pkt.

Under the Service Port section, enter 53 for the Services field.

Under the Pool section, choose a relevant IPv4, IPv6, or IPv4 + IPv6 pool from the dropdown list or click on Create Pool to configure a new pool. On creating a new pool, navigate to the Servers tab to enter the IPv4, IPv6, or IPv4v6 member information.

Static DNS Records

Click on Create DNS Record to create a new DNS record. Starting with 18.1.2, you can create the DNS record for both IPv4 and IPv6 traffic.

Enter a qualified domain name under FQDN. For Type, choose A and AAAA Record from the dropdown list.

Under the A and AAAA Record section, enter the IP for A record under IPv4 Address field and IP for AAAA record under IPv6 Address. You can choose to enter only either of these or both. Multiple IP addresses (both for IPv4 and IPv6) can be configured as well.

DNS for Avi-hosted Virtual Services

Avi-SE-hosted DNS virtual services translate the FQDNs of Avi-Vantage-hosted virtual services into IP addresses. This configuration does not require pool assignment, as the translation is completely done within the SE VMs.

Navigate to Administration > Settings and select DNS Service. Under the DNS Virtual Services section, click on the dropdown list to either choose a pre-defined DNS virtual service or create a virtual service.

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

DNS for GSLB

For GSLB configuration, the DNS is not defined by the DNS virtual service, but is configured as a GSLB site object. As part of the GSLB site configuration, a few pre-existing DNS service(s) is (are) designated to serve in the role. To configure, navigate to Infrastructure > GSLB and click on the Add New Site button in the Site Configuration tab.

Enter relevant information for all fields in the editor. Enable the checkbox for Active Member option and click on Save and Set DNS Virtual Services.

Select from one or more DNS virtual services in the dropdown list and click on Save to enable it for the GSLB configuration.

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

High Availability Recommendations for GSLB

For high availability, it is recommended to configure DNS for GSLB on an SE group that is scalable to two or more Service Engines. It is also recommended to implement DNS for GSLB in more than one location. This can be implemented in the following two ways:

Have at least two geographically separated active GSLB sites. For each site configure DNS onto a scalable SE group.
If only one active site is defined, ensure a minimum of at least one geographically remote cloud. On that remote cloud, configure DNS for GSLB on a scalable SE group. Also define all virtual services to support the mission-critical applications running on the origin location.