July 11, 2021

Introduction

This article covers the configuration of DNS delegation in 1&1 (1AND1 \ IONOS) DNS servers to allow Citrix ADC (NetScaler) to be authoritative for a DNS subdomain. For DNS subdomain \ subzone delegation to Citrix ADC for other popular domain registrars, please refer to the following articles:

Citrix Global Server Load Balancing (GSLB) is a powerful DNS-based load balancing feature commonly used to direct users to one web server over another for geo-proximity and/or resiliency. With the DNS subzone delegated to Citrix ADC, we enable Citrix ADC to make intelligent traffic routing decisions based on parameters we define within the configuration (which is highly extensible) and return the appropriate IP to the client according to those configurations.

This article does not go into the details on how GSLB works nor its leading practices for implementation, but you may refer to the following links for primers on the technology.

Delegating entire domains to Citrix ADC to act as a DNS server is also a popular design in customer environments, as Citrix has numerous policy-based DNS configurations which administrators can implement, avoiding the need for adding additional cost to their IT landscape.

Many purpose-built enterprise DNS solutions have straightforward controls for delegating other DNS serves to be authoritative for a subzone. When dealing with DNS registrars, however, the configurations may not appear to be as straightforward. This article is intended to help guide an administrator through DNS delegation to Citrix ADC for domains hosted by 1&1 (1AND1 \ IONOS) on the Internet.

Please note that this registrar has a more straightforward process for creating subzones in their DNS control panel as compared to other DNS registrars (which is nice for familiarity), however, there are a couple more steps involved. Of note, there is a need to delete some default records when creating subzones which otherwise override desires delegation behaviours but nothing a few mouse clicks can’t rectify.

Prerequisites

A purchased DNS domain with the registrar.
Administrative rights to the DNS registrar in order to make DNS changes (or access to a competent team who can implement the instructions at your direction).
ADNS IPs hosted on your Citrix ADCs (one on each GSLB Site within the GSLB mesh), that has a public IP (or ideally a NAT to the DMZ IP of the ADNS service on each respective GSLB Site).
The ADNS server on the Citrix ADC should be configured as DNS type ADNS and ADNS_TCP to be compliant with DNS standards. This requires creating two ADNS services using the same IP.
ADNS public IP ACLs for TCP and UDP 53.

Step 1 – Create Subdomain

From the IONOS administration console, navigate to “Domains & SSL” and select the domain you intend to work on. From the sub-menu, select “Subdomains” and then on the right select “Add subdomain”.

Assign subzone \ subdomain name and click ‘Save’. In our example, we will be using ‘gslb’ but you may choose whatever you like, provided it is used consistently in later sections such as CNAME record creation and Citrix ADC DNS configurations.

Step 2 – Delete Irrelevant A Records

From the subdomain view, click the cog and then ‘DNS’ to get to the DNS entry control panel for the subdomain.

The registrar auto-creates a number of DNS entries that we do not want in our configuration as it will interfere with a delegation of the subzone to authoritative DNS servers (in this case, Citrix ADC). Select the following entries and delete them by clicking ‘Delete records’ and confirming the deletion.

Step 3 – Create A Records

Back on the subdomain > DNS page, click “Add record” at the top of the page, and select ‘A’ to begin creating the A records.

The “Host Name” value will be the hostname of the name server (name as you wish), and the “Points to” value will be the ADNS public IP created on Citrix ADC.

Click “Save” once complete, to commit the change, repeat for other ADNS IPs. Create A records for each of your name servers defined on the Citrix ADCs in the GSLB mesh. In this example only one A record is created. However, in a real-world implementation, you will need to create an A record corresponding to the name server public IP for each ADNS server in the solution. For example, if you have 3 GSLB Sites, you may have configured 3 ADNS IPs to support the GSLB solution, so you’d create 3 A records (one for each). An ADNS server can be authoritative for multiple DNS zones.

Step 4 – Create NS Records

Back on the subdomain > DNS page, click “Add record” at the top of the page, and select ‘NS’ to begin creating the NS records.

The “Host Name” value will be the subdomain (gslb in this case), and the “Points to” value will be the Host A record in FQDN format we just created in the prior step.

Click “Save” and repeat the process for the other name servers which will be authoritative for the subzone. In each case, the subzone name (such as GSLB) will remain the same.

Step 5 – Create CNAME Record

Now we will create the last DNS record in the DNS registrar, the CNAME record which will direct requests for say… citrix.domain.com to citrix.gslb.domain.com. This will in effect direct DNS resolution for the user-friendly URL to the Citrix ADC to resolve (and thus return the most appropriate IP for the configured GSLB health and behaviour logic).

Back on the subdomain > DNS page, click “Add record” at the top of the page, and select ‘CNAME’ to begin creating the CNAME record.

Populate the “Host Name” value as the user-friendly hostname, and the “Points to” value as the FQDN of the URL including the subdomain\subzone, allowing the Citrix ADCs to return the IP response to user requests. The TTL does not matter as the “points to” value would not change over the course of operation.

Click “Save” once complete, the DNS registrar DNS configurations are now complete.

Step 6 – Create DNS Records on Each Citrix ADC

On each Citrix ADC within the GSLB mesh that has an ADNS IP, create Host A, NS, and SOA records. In the example below I have manually created A record for citrix.gslb.domain.com for the purposes of expedient testing, but in a true GSLB configuration, you would not create those records manually, the DNS FQDN you configure on the GSLB vServer would automatically populate this. Note that for Host A and NS records, you must create one for each of the ADNS public IPs on your Citrix ADCs that are participating in the GSLB mesh. These records should exist on all Citrix ADCs, which is where the GSLB sync option can come in handy to reduce effort and human error.

The examples below include all records for the DNS delegation series to date, to act merely as examples.

Citrix ADC Host A Records Example

Citrix ADC NS Records Example

Citrix ADC SOA Records Example

Step 7 – Test DNS Delegation

Most DNS registrars will forewarn up to 24+ hours to populate DNS records, however, in my case, I found changes were available very quickly. If after 15 minutes your test is unsuccessful, begin the usual routine of troubleshooting including:

Reconfirming all DNS records were created with DNS registrar.
The IPs used when creating DNS records were correct.
Confirm ADNS IPs are reachable on the Citrix ADCs to rule out firewall issues (TCP and UDP 53 should be open to each ADNS IP from the Internet) by checking with firewall admin for blocks, and nslookup commands to manually query records against each ADNS IP.
If GSLB has been configured, double-check the GSLB Site configurations are correct, and the DNS FQDN (in the format of hostname.gslb.domain.com, not hostname.domain.com!) is configured on the GSLB vServer.

In the test below, you will note the successful CNAME resolution for the user-friendly URL.

Quick Tip: Andrew Gravett (Citrix Alumnus) has reminded me that we can conduct command-line ‘dig’ or ‘nslookup’ against our ADC DNS IPs to ensure firewall ACLs and public NATs are working correctly. Citrix has a great guide on using the dig command at this link. for example: dig @<public DNS IP> citrix.gslb.michaelshuster.ca should pump out a chunk of data with an answer section indicating the IP and record type of the FQDN I was testing against.

Conclusion

DNS configuration for Internet DNS registrars is often a bit more restricted than enterprise DNS platforms. It is our hope this article helps dispel confusion and enables administrators and consultants to successfully delegate DNS resolution for a GSLB subzone to Citrix ADCs out on the Internet.

Subscribe