Deploy a NetScaler for Azure DNS private zone

Azure DNS is a service on the Microsoft Azure infrastructure for hosting DNS domains and providing name resolution.

Azure DNS private zones are a service focused on resolving domain names in a private network. With private zones, customers can use their own custom domain names rather than the Azure-provided names available today.

NetScaler, the leading application delivery solution, is best suited to provide load balancing and GSLB capabilities for an Azure DNS private zone. By subscribing to Azure DNS private zone, the business can rely on NetScaler Global Server Load Balancing’s (GSLB) power and intelligence to distribute intranet traffic across workloads in multiple geographies and across data centers, connected via secure VPN tunnels. This collaboration guarantees businesses seamless access to part of their workload that they want to move to Azure public cloud.

Overview of Azure DNS

The Domain Name System (DNS) is responsible for translating or resolving a service name to its IP address. A hosting service for DNS domains, Azure DNS provides name resolution by using the Microsoft Azure infrastructure. In addition to supporting internet-facing DNS domains, Azure DNS now also supports private DNS domains.

Azure DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual network without needing a custom DNS solution. By using private DNS zones, you can use your own custom domain names rather than the Azure-provided names. Using custom domain names helps you to tailor your virtual network architecture to best suit your organization’s needs. It provides name resolution for virtual machines (VMs) within a virtual network and between virtual networks. Also, customers can configure zone names with a split-horizon view, which allows a private and a public DNS zone to share a name.

Why NetScaler GSLB for Azure DNS private zone?

In today’s world, businesses want to transition their workloads from On-premises to Azure cloud. The transition to cloud allows them to apply time to market, capital expenses/price, ease of deployment and security. Azure DNS private zone service provides a unique proposition for the businesses that are transitioning part of their workloads to the Azure Cloud. These businesses can create their private DNS Name, which they had for years in On-premises deployments, when they use the private zone service. With this hybrid model of intranet application servers being in On-premises and Azure cloud connected via secure VPN tunnels, the one challenge is to have a seamless access to these intranet applications. NetScaler solves this unique use case with its global load balancing feature, which routes the application traffic to the most optimal distributed workloads/servers either On-premises or on Azure cloud, and provides application server health status.

Use case

Users in an On-prem network and in different Azure VNets are able to connect to the most optimal servers in an internal network for accessing the required content. This ensures that the application is always available, cost is optimized and user experience is good. Azure private traffic management (PTM) is the primary requirement here. Azure PTM ensures that users’ DNS queries resolve to an appropriate private IP address of the application server.

Use case solution

NetScaler includes the global server load balancing (GSLB) feature to meet the Azure PTM requirement. GSLB acts like a DNS server, which gets the DNS requests and resolves the DNS request into an appropriate IP address to provide:

• Seamless DNS-based failover.
• Phased migration from On-premises to cloud.
• A/B testing a new feature.

Among the many load balancing methods supported, following methods can be useful in this solution:

1. Round Robin

2. Static proximity (Location based server selection). It can be deployed in two ways:

   1. EDNS Client Subnet (ECS) based GSLB on NetScaler.
   2. Deploy a DNS forwarder for every virtual network.

Topology

The following figure depicts the NetScaler GSLB deployment for an Azure private DNS zone.

A user can access any application server either on Azure or On-prem based on the NetScaler GSLB method in an Azure private DNS zone. All traffic between On-prem and Azure virtual network is through a secure VPN tunnel only. Application traffic, DNS traffic, and monitoring traffic are shown in the preceding topology. Depending on the required redundancy, NetScaler and DNS forwarder can be deployed in the virtual networks and data centers. For simplicity purpose, only one NetScaler is shown here but we recommend at least one set of NetScaler and DNS forwarder for the Azure region. All user DNS queries first go to the DNS forwarder that has rules defined for forwarding the queries to an appropriate DNS server.

Configuring NetScaler for Azure DNS private zone

Products and Versions tested:

Note:

The deployment is tested and remains the same with NetScaler version 12.0 and above.

Prerequisites

The following are general prerequisites.

• Microsoft Azure portal account with a valid subscription.
• Ensure connectivity (Secure VPN Tunnel) between On-prem and Azure cloud. To set up a secure VPN tunnel in Azure, see Step-By-Step: Configuring a site-to-site VPN Gateway between Azure and on-premises.

Solution description

If you want to host one application Azure DNS private zone (rr.ptm.mysite.net) which runs on HTTPs and is deployed across Azure and On-premises with intranet access based on the round robin GSLB load balancing method. To achieve this deployment enable GSLB for the Azure private DNS zone with NetScaler that consists of the following configurations:

1. Configure Azure and On-premises Setup.
2. NetScaler appliance on Azure virtual network.

Configure Azure and On-premises Setup

As shown in the topology, set up Azure virtual network (VNet A, VNet B in this case) and On-premises setup.

1. Create an Azure private DNS zone with domain name (mysite.net).
2. Create two virtual networks (VNet A, VNet B) in a Hub and Spoke model in an Azure region.
3. Deploy App Server, DNS forwarder, Windows 10 Pro client, NetScaler in VNet A.
4. Deploy an App Server and deploy a DNS forwarder if any clients are in VNet B.
5. Deploy an App server, DNS forwarder, and Windows 10 pro client on On-premises.

Azure private DNS zone

Create an Azure private DNS zone with domain name.

1. Log in to the Azure portal and select or create a dashboard.
2. Click create a resource and search for DNS zone to create (mysite.net in this case) Azure private DNS zone with domain name (mysite.net).

Azure virtual networks (VNet A, VNet B) in Hub and spoke model

Create two virtual networks (VNet A, VNet B) in a Hub and Spoke model in an Azure region.

1. Create two virtual networks.

2. Select the same dashboard and click create a resource and search for virtual networks to create two virtual networks namely VNet A, VNet B in the same region and peer them to form a Hub and Spoke model as shown in the following image. For more information on how to set up a hub and spoke topology, See Implement a hub-spoke network topology in Azure.

   

   

VNet A to VNet B peering

To peer VNet A and VNet B:

1. Click Peerings from the Settings menu of VNet A and peer VNet B.

2. Enable Allow forwarded traffic and Allow gateway transit as shown in the following image.

   

The following image depicts the successful peering of VNet A to VNet B.

VNet B to VNet A peering

To peer VNet B and VNet A:

1. Click Peerings from the Settings menu of VNet B and peer VNet A.
2. Enable Allow forwarded traffic and use remote gateways as shown in the following image.

![VNet B to A](/en-us/vpx/media/image-07.png)

The following image depicts the successful peering of VNet B to VNet A.

Deploy App server, DNS forwarder, Windows 10 Pro client, NetScaler in VNet A

We discuss briefly about App server, DNS forwarder, Windows 10 pro client, and NetScaler on VNet A.

1. Select the same dashboard, click Create a resource.
2. Search for the respective instances and assign an IP from VNet A subnet.

App server

App server is nothing but the web server (HTTP server) where an Ubuntu server 16.04 is deployed as an instance on the Azure or On-premises VM. To make it as a web server, at the command prompt, type:

sudo apt install apache2

Windows 10 Pro Client

Launch Windows 10 pro instance as client machine on VNet A and On-premises.

NetScaler

NetScaler compliments the Azure DNA private zone by health check and Analytics from NetScaler MAS. Launch a NetScaler from Azure Marketplace based on your requirement, here we have used NetScaler (BYOL) for this deployment.

For the detailed steps on how to deploy NetScaler on Microsoft Azure. See Deploy a NetScaler VPX Instance on Microsoft Azure.

After deployment, use NetScaler IP to configure NetScaler GSLB.

DNS forwarder

It is used to forward the client requests of hosted domains bound to NetScaler GSLB (ADNS IP). Launch an Ubuntu server 16.04 as Linux instance (Ubuntu server 16.04) and refer below URL on how to set up it as a DNS forwarder.

Note:

For Round Robin GSLB load balancing method one DNS forwarder for Azure Region is sufficient but for Static proximity we need one DNS forwarder per virtual network.

1. After deploying forwarder, change the DNS server settings of virtual network A from default to custom with VNet A DNS forwarder IP as shown in the following image.
2. Modify the named.conf.options file in VNet A DNS forwarder to add forwarding rules for domain (mysite.net) and subdomain (ptm.mysite.net) to the ADNS IP of NetScaler GSLB.
3. Restart the DNS forwarder to reflect the changes made in the file named.conf.options.

VNet A DNS forwarder settings

    zone "mysite.net" {
               type forward;
    forwarders { 168.63.129.16; };
    };
    zone "ptm.mysite.net" {
        type forward;
        forwarders { 10.8.0.5; };
    };
 <!--NeedCopy-->

Note:

For the domain (“mysite.net”) zone IP address, use the DNS IP address of your Azure region. For the subdomain (“ptm.mysite.net”) zone IP address, use all ADNS IP addresses of your GSLB instances.

Deploy App server and a DNS forwarder if any clients are in VNet B

1. For virtual network B, select the same dashboard, click create a resource.
2. Search for the respective instances, and assign an IP from VNet B subnet.
3. Launch App server and DNS forwarder if there is static proximity GSLB load balancing similar to VNet A.

4. Edit the VNet B DNS forwarder settings in named.conf.options as shown in the following setting:

   VNet B DNS forwarder settings:

    zone "ptm.mysite.net" {
        type forward;
        forwarders { 10.8.0.5; };
    };
<!--NeedCopy-->

The following image depicts the VNet B DNS forwarder settings:

Deploy app server, DNS forwarder, and Windows 10 pro client on On-premises

1. For On-premises, launch the VMs on bare metal and bring the App server, DNS forwarder and Windows 10 pro client similar to VNet A.

2. Edit the On-premises DNS forwarder settings in the named.conf.options as shown in the following example.

On-Premises DNS forwarder settings

    zone "mysite.net" {
               type forward;
               forwarders { 10.8.0.6; };
    };
    zone "ptm.mysite.net" {
        type forward;
        forwarders { 10.8.0.5; };
    };
<!--NeedCopy-->

For mysite.net, we have given DNS forwarder IP of VNet A instead of Azure private DNS zone server IP because it is a special IP address that is not reachable from On-premises. Hence this change is required in the DNS forwarder setting of On-premises.

Configure the NetScaler on Azure virtual network

As shown in the topology, deploy the NetScaler on the Azure virtual network (VNet A in this case) and access it through the NetScaler GUI.

Configuring NetScaler GSLB

1. Create ADNS Service.
2. Create local and remote sites.
3. Create services for the local virtual servers.
4. Create virtual servers for the GSLB services.

Add ADNS service

1. Log in to the NetScaler GUI.
2. In the Configuration tab, navigate to Traffic Management > Load Balancing > Services.
3. Add a service. We recommended you to configure the ADNS service both in TCP and UDP as shown in the following image:

Add GSLB sites

1. Add local and remote sites between which GSLB will be configured.

2. On the Configuration tab, navigate to Traffic Management > GSLB > GSLB Sites. Add a site as shown in the following example and repeat the same procedure for other sites.

   

   

   

Add GSLB services

1. Add GSLB services for the local and remote virtual servers which load balances App servers.
2. On the Configuration tab, navigate to Traffic Management > GSLB > GSLB Services.
3. Add the services as shown in the following examples.

4. Bind HTTP monitor to check server status.

   

   

5. After creating the service, go to the Advanced settings tab inside the GSLB service.

6. Click Add Monitor to bind the GSLB service with an HTTP monitor to bring up the state of service.

7. Once you bind with the HTTP monitor, the state of the services is marked as UP as shown in the following image:

Add GSLB virtual server

Add GSLB virtual server through which App servers’ alias GSLB services are accessible.

1. On the Configuration tab, navigate to Traffic Management > GSLB > GSLB Virtual Servers.
2. Add the virtual servers as shown in the following example.

3. Bind GSLB services and domain name to it.

   

4. After creating the GSLB virtual server and selecting the appropriate load balancing method (Round Robin in this case), bind GSLB services and domains to complete the step.

   

5. Go to the Advanced settings tab inside the virtual server and click Add Domains tab to bind a domain.

6. Go to Advanced > Services and click the arrow to bind a GSLB service and bind all three services (VNet A, VNet B, On-premises) to virtual server.

   

   After binding GSLB services and domain to the virtual server it appears as shown in the following image:

   

Check if GSLB virtual server is up and 100% healthy. When the monitor shows that the server is up and healthy, it means that sites are in sync and back end services are available.

To test the deployment, access the domain URL rr.ptm.mysite.net from either cloud client machine or On-premises client machine. If you access it from cloud windows client machine ensure that the on-premises App server is accessed in a private DNS zone without any need for third party or custom DNS solutions.