HowTo: Policy-based DNS on Citrix ADC (NetScaler) with DNS Views

Introduction

Citrix ADC is a bonafide DNS server platform, capable of servicing a range of DNS services. This is necessary on account of its foundational use in Global Server Load Balancing (GSLB), but beyond that, it has come in handy for non-GSLB functions such as policy-based DNS or merely acting as an edge DNS server for customer environments to further extend the utility of Citrix ADCs and minimize additional infrastructure investment. Citrix ADC can also load balance DNS servers (very common) and act as a DNS proxy. And yes, Citrix ADC supports DNSSEC.

This guide will walk through the DNS Views feature. DNS Views is a subcomponent of GSLB. DNS Views allows administrators to craft policy-based DNS logic to control the IP address (for a domain\subdomain Citrix ADC is authoritative for) returned by Citrix ADC to a client based on logic such as the client’s network. Whether or not you are using GSLB today in your deployment to make automated DNS resolution decisions based on back-end service health, or simply are using Citrix ADC as a DNS server for edge use cases DNS Views can be used to provide a policy-based DNS. Of note, DNS Views is but one of about three ways to invoke policy-based DNS on Citrix ADC. Others include Content Switch of type GSLB, and DNS Responders.

References

• CTX127590 – How to Configure a DNS View for Global Server Load Balancing on a NetScaler Appliance
• CTX130163 – How to Configure GSLB Setup for Internal Users From GUI

Use Cases

The most common use case for policy-based DNS tends to be resolving different IPs for a given FQDN based on the user’s network location. Examples of this are as follows, just to highlight a few:

• GSLB services are used on appliances servicing internal and external use cases. Users on the Internet need to resolve a public IP for an FQDN while internal users must resolve a private IP address.
• Users on the internal network must resolve an FQDN to a Citrix StoreFront VIP, while partners or remote users coming in via a site-to-site VPN or MPLS link must resolve the FQDN to a Citrix Gateway vServer for security reasons.
• Resolving different IPs (for example different NAT IPs on different network segments) for the same FQDN, depending on the extranet connection users are coming in on.

A Note on DNS Recursion and ECS

Before we get going, I want to draw attention to a DNS resolution consideration which if ignored, may not allow your solution to work as intended for some of these examples. Most DNS deployments use recursive DNS, wherein the DNS server may contact another DNS server on the client’s behalf to resolve the requested DNS entry if the client’s local DNS (LDNS) server is not authoritative for a particular domain. Recursion is often preferred over leaving clients to communicate directly with each DNS server involved in the lookup (iterative DNS query). For Infoblox, documentation is here.

With this enabled, however, authoritative DNS services on Citrix ADC by default will be unable to ascertain the true client IP, which may hamper policy-based DNS outcomes. Enter EDNS Client Subnet (ECS) which is a DNS header extension that provides client subnet details. Citrix ADC only supports EDNS0. Provided the LDNS server supports EDNS0 and the respective Citrix ADC configuration is set for ECS, we can make decisions based on the client subnet info included. By default, a GSLB vServer does not have ECS enabled, but this is a simple checkbox to toggle or via CLI:

set gslb vserver <vserver_name> -ecsAddrValidation ENABLED

To invoke the expressions once enabled, instead of using an expression such as “CLIENT.IP.SRC.IN_SUBNET(x.x.x.x/24)” in a policy, we can use “DNS.REQ.OPT.ECS.IP.IN_SUBNET(x.x.x.x/24)” to invoke policy logic based on the contents of the DNS query header.

Hopefully, the above explanation will provide sufficient context for use of such expressions in this guide.

DNS Views Overview

Beyond the GSLB infrastructure which DNS Views is an extension of, there are a few main constructs that make up DNS Views as follows which are all found within the DNS blade under Traffic Management on Citrix ADC:

• DNS Policy. Not an exclusive construct to DNS Views. Allows setting of an expression upon which to take a DNS action. In a DNS Views configuration, the policy is bound to the DNS View.
• DNS Action. Not an exclusive construct to DNS Views. Used to direct action for DNS responses including DNS views, drop requests, DNS cache bypass, rewrite response, and preferred location list as possible actions.
• DNS View. DNS Views act as a tag on GSLB services that have bound a view to them. Creating a DNS View object merely requires providing a label upon creation. The DNS View is then bound to a given GSLB service, and referenced by DNS policy. Essentially it provides linkage between GSLB service and DNS policy. The DNS View through its association with various objects in GSLB and DNS allows the Citrix ADC to resolve the appropriate IP for a given FQDN for a user’s request. We define the alternative IP when we bind the DNS View to the GSLB service.

Attempting to map out the relationships of these constructs and how they relate to the GSLB configuration for policy-based DNS can be a bit difficult. And although clicking through the GUI to make the necessary associations is easy, visualizing the relationships and thinking through the linkages can be a little convoluted. This diagram hopefully will allow you to visualize the relationship more easily, in the context of policy-based DNS.

Creating DNS Views Logic

The following steps will guide you through the steps of creating the constructs \ objects to invoke policy-based DNS on a GSLB service. it assumes your GSLB Site, vServer, and services are already created.

If you need to delete any of these configurations once created, this is the relationship dependency order in which you need to delete the objects.

Policy > Action > View (after unbound from a GSLB service)

Step 1 – Create DNS View

From Traffic Management > DNS > Views, click the “Add” button. Name the view a logical name denoting its relationship to the environment. Click “Create”.

Step 2 – Create DNS Action

From Traffic Management > DNS > Actions click the “Add” button. Name the action a logical name denoting its relationship to the environment. For “Type”, select “View Name” and select the view created in Step 1. Click “Create”.

Step 3 – Create DNS Policy

From Traffic Management > DNS > Policies click the “Add” button. Name the action a logical name denoting its relationship to the environment. For “Action”, select the DNS Action created in Step 2. For expression, specify the client IP subnet(s) or other pertinent decision logic upon which to invoke the DNS View. In the example below I have included a regular client subnet expression, in addition to an EDNS0 client expression example (please refer to the pre-requisites earlier in this article related to ECS). Click “Ok” to create the policy.

Step 4 – Bind DNS View to GSLB Service

From Traffic Management > GSLB > Services, edit the service to which you want to apply the DNS View. In “Advanced Settings” to the right, click “DNS Views” and bind the DNS View to the GSLB service. In this binding step, specify the alternate IP to be resolved, if the DNS policy expression matches. For example, if a user coming in off the extranet network accesses the DNS record for which Citrix ADC is authoritative for, it may resolve a NAT IP accessible on an extranet network segment, versus the internal LAN IP of the service used by trusted clients on the corporate network. Click “Bind” to complete the configuration.

If you navigate back to Traffic Management > DNS > Views and click your view and then “Details” you will see a relationship table of the DNS View, the GSLB Service, and the DNS policy.

Step 5 – Test

With the configuration complete, you may now test the URL access via ping or URL. Endpoints not within the subnet range of the example expression used should receive the IP of the service as indicated natively on the GSLB service itself. Users coming from endpoints on the extranet network should receive the alternate IP defined in the DNS View bound to the GSLB service.

Conclusion

It is my hope this guide will help clear up some confusion on configuring and maintaining policy-based DNS on Citrix ADC where GSLB is in use. The logic in the example steps can be expanded upon to accommodate multi-datacentre setups by creating additional constructs for other GSLB services associated GSLB vServers. If DNS resolution is not occurring as expected, please validate the ADNS configurations are configured and functioning properly, then validate the DNS configurations on both Citrix ADC and the enterprise DNS servers for EDNS0\ECS support.