Page 1 of 15 - Avi NetworksReferring to the diagram below, a DNS service ? shown in green? is hosted...

Avi Networks — Technical Reference (17.1)Avi DNS Architecture and Features

Copyright © 2020 Avi Networks, Inc. of 15

view onlineAvi 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 elaborative sections within this article.

Hosting GSLB service DNS entriesVirtual service DNS hosting (domain name to IP/IPAM)Hosting static/manual DNS entriesDNS load balancing

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

Functionality1. 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:

Avi GSLB OverviewAvi GSLB Architecture and Object ModelAvi GSLB Site Configuration and OperationsAvi GSLB Service Health Monitors

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 and .DNS-based Service Discovery for Mesos 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, 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 be assigned, loaded with any one of mustmany available DNS server software packages.

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

https://avinetworks.com/docs/17.1/avi-dns-architecture/

https://avinetworks.com/docs/17.1//avi-gslb-overview/

https://avinetworks.com/docs/17.1//gslb-architecture-and-object-model/

https://avinetworks.com/docs/17.1//avi-gslb-site-configuration-and-operations/

https://avinetworks.com/docs/17.1//avi-gslb-service-and-health-monitors/

https://avinetworks.com/docs/17.1//service-discovery-using-ipam-and-dns/

https://avinetworks.com/docs/17.1//service-discovery-for-mesos/

https://avinetworks.com/docs/17.1//avi-vantage-openshift-installation-guide/



Referring to the diagram below, a DNS service ? shown in ? is hosted on the leftmost SE. The DNS VS responds to DNS greenqueries 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.

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



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

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



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



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 the exclude DNS errors discussion found .here

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

https://avinetworks.com/docs/17.1//architectural-overview/templates/profiles/analytics-profile/#exclude-dns-errors



Notes

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.

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 article for more details.DNS Health Monitor

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

https://avinetworks.com/docs/17.1//dns-health-monitor/



Illustrated below is the application profile editor. Setting the field to brings up settings by which to customize the Type DNSbehavior of Avi DNS.



1. 2. 3.

DNS Settings

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 MonitorsTTL 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 MonitorsSubnet prefix length specifies the IP address prefix length to use in the EDNS client subect (ECS) option. When the incoming request does not have any ECS option and the prefix length is specified, we insert an ECS option in the request to upstream servers.The are two:(Options for) Invalid DNS Query processingDrop unhandled DNS requestsRespond to unhandled DNS requestsProcess EDNS Extensions should be optioned on so that EDNS extensions will be parsed and shown in logs. For GSLB services, the EDNS subnet option can be used to influence load balancing. For more information, read Extension

.Mechanisms for DNS Client Subnet Option InsertionRespond to AAAA queries with empty response: Click this option ON to respond to an AAAA query with an empty response when there are only IPv4 records.

DNS Request Rate Limiter Settings

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

Advanced 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 serviced by an Avi DNS that uses this profile. These are configured with Ends-With semantics.



https://avinetworks.com/docs/17.1//ecs-option-insertion/

https://avinetworks.com/docs/17.1//ecs-option-insertion/



Authoritative Domain Names are those serviced by an Avi DNS that uses this profile. These are configured with Ends-With semantics. Queries for FQDNs that are subdomains of these domains and do not have DNS records in Avi are dropped or an NXDOMAIN response is sent.

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.

Notes: 1. A complete discussion of all settings relevant to configuration of a DNS service can be found in the DNS Profile of the Application Profile article. 2. In the Advanced tab, one can identify the SE group on which the DNS VS will be section

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.



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

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 click the Active Member option to enable the mustSave 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.

https://avinetworks.com/docs/17.1//avi-gslb-site-configuration-and-operations#configure-local-dns-vs

https://avinetworks.com/docs/17.1//avi-gslb-site-configuration-and-operations#configure-local-dns-vs

https://avinetworks.com/docs/17.1//avi-gslb-site-configuration-and-operations/

https://avinetworks.com/docs/17.1//avi-gslb-site-configuration-and-operations/#configure-local-dns-vs



1. 2.

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

Page 1 of 15 - Avi NetworksReferring to the diagram below, a DNS service ? shown in green? is hosted...

Documents

Transcript of Page 1 of 15 - Avi NetworksReferring to the diagram below, a DNS service ? shown in green? is hosted...