Deployment Planning

The Virtual Traffic Manager contains a database of geographic locations for the public IPv4 address space and acts either as an authoritative DNS server or as a proxy for a separate back-end DNS service. You deploy your Virtual Traffic Managers either in parallel with, in front of, or instead of your current DNS infrastructure. When the Virtual Traffic Manager receives a DNS request from a client, it determines the response from either the internal or external DNS service it is managing. The Virtual Traffic Manager then modifies the response, based on a number of configurable metrics (including geographic location), before sending it back to the client.

To see more information about the Virtual Traffic Manager's built-in DNS capability, see The Virtual Traffic Manager DNS Server.

A DNS domain needs a set of name servers that are nominated as authoritative by the name servers for the parent domain. Where the parent domain is a public domain, such as a global top level domain, you modify the authoritative name servers for your domain through a DNS registrar.

To use GLB with a hostname, you can deploy the Virtual Traffic Manager in one of two ways:

A Parallel deployment can be more complex to configure, but is a better solution if you are managing large numbers of domains or if you expect to make frequent changes.

For an Inline deployment, the Virtual Traffic Manager operates as the authoritative name server for the entire domain containing the hostname. A DNS request is received on a DNS Virtual Server, and processed by the associated Pool, which might be either the built in DNS server or an external pool of DNS servers.

To deploy the Virtual Traffic Manager using the Inline method, configure the built in DNS server or external DNS servers to return multiple "A" records for each hostname you want to globally balance. To configure the built in DNS server, see The Virtual Traffic Manager DNS Server.

Then create DNS Virtual Servers on your Virtual Traffic Managers. For greatest coverage, Ivanti recommends creating both a DNS (TCP) and a DNS (UDP) Virtual Server. Set the default pool to either the built in DNS Server pool or your external DNS servers, depending on your requirements. While using an external DNS pool, the Virtual Traffic Managers proxy all DNS requests to these Name servers.

Add a GLB Service to your DNS Virtual Servers for the hostname to be globally balanced, and make the Virtual Traffic Managers authoritative for that domain by updating the delegation records in the parent domain.

The parent domain contains a number of record types:

To update the parent domain, first determine which organization manages the parent domain. This might be an external DNS registrar, another part of your organization, or a domain that you manage yourself.

To update the delegation records with a DNS registrar

For further assistance with this procedure, contact either your DNS provider or your DNS registrar.

After your parent domain’s delegation records have been updated, the Virtual Traffic Manager receives all DNS requests for the hostname to be load balanced. On receiving a request, the Virtual Traffic Manager forwards it to the appropriate DNS back end, and receives a list of IP addresses as a response. The Virtual Traffic Manager processes this list to select precisely which IP address it returns to the end user.

To create a parallel deployment, you configure a CNAME for your DNS entry that points to a hostname in a separate domain, often a subdomain of the domain that you own. You then configure GLB for the parallel hostname, in accordance with the Inline deployment method.

Suppose, for example, that you manage the domain "example.com" yourself, and want to enable GLB on "www.example.com", using a parallel deployment with the alternative hostname "www.gslb.example.com".

You configure the name servers for "example.com" to fulfill two roles:

Using either the internal Virtual Traffic Manager DNS server capability, or through a separate pool of back-end DNS servers, you then host the "gslb.example.com" domain on the Virtual Traffic Manager. In the "example.com" zonefile, add the following entries:

When a DNS client looks up the domain name www.example.com, it contacts the name server for the example.com domain. This name server returns a CNAME response corresponding to "try www.gslb.example.com instead". Because it is authoritative for the example.com domain, the name server also gives additional information concerning the names and IP addresses of some name servers for gslb.example.com (which, in this case, are your Virtual Traffic Managers).

The DNS client now sends a request for www.gslb.example.com to the Virtual Traffic Manager, and that Virtual Traffic Manager in turn obtains the list of IP addresses for all your GLB Locations (using either its internal DNS service or by querying your back-end DNS servers). The Virtual Traffic Manager processes this list, returning back one or more A records containing the IP address or IP addresses of one of the GLB Locations.

A parallel deployment can be more complex to deploy because you must create and configure a new DNS subdomain. However, it is a more flexible and suitable technique if you expect to change your DNS configuration frequently, or want to centralize the configuration for many domains as you can use the same subdomain for each one.

For example, you can alias many different domain names (www.example.com, www.mysite.com, and www.example.org) to the same CNAME (www.gslb.example.com), which is in turn hosted by your Virtual Traffic Managers. You can then configure many domains centrally from a single CNAME by setting up the back-end DNS service of your Virtual Traffic Manager deployment accordingly.

When you make a change to any of your DNS records, it is possible that the change might not have an immediate effect on your Internet traffic. This is because each DNS record contains a Time-to-Live (TTL) field. The TTL field typically tells downstream DNS servers to cache this record for a given number of seconds, after which time it should send a new request. To ensure that your records propagate across the Internet in a timely fashion, Ivanti recommends a TTL value between 30 and 60 seconds.