Deployment Planning

Traffic Manager Positioning

The 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 Traffic Managers either in parallel with, in front of, or instead of your current DNS infrastructure. When the 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 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 Traffic Manager's built-in DNS capability, see The Traffic Manager DNS Server.

Deployment Methods

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 Traffic Manager in one of two ways:

•With an “Inline” deployment, your Traffic Managers become the authoritative DNS servers for the domain containing the hostname. By modifying the delegation records in the parent domain, you ensure that all DNS traffic for the domain is directed to your Traffic Managers. The Traffic Managers either serve the requests using the built in DNS server capability, or forward it to your existing DNS servers, and then manipulate the responses on hostnames with GLB configured.

•With a “Parallel” deployment, the Traffic Managers are not authoritative for the domain containing the hostname, and you instead create a parallel hostname in a separate DNS domain for which the Traffic Managers are authoritative. In the existing domain, create a CNAME to the parallel hostname in the other domain, and configure a GLB Service with the parallel hostname.

When your (Authoritative) Name Servers receive a DNS request for the hostname, they respond with a CNAME, which causes the client to make a DNS request for the parallel hostname from a Traffic Manager. As with the Inline deployment, the Traffic Manager either processes the request using the built in DNS server, or forwards it to another authoritative DNS server. The response is then manipulated according to the GLB Service configuration.

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.

Inline Deployment

For an Inline deployment, the 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 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 Traffic Manager DNS Server.

Then create DNS Virtual Servers on your 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 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 Traffic Managers authoritative for that domain by updating the delegation records in the parent domain.

The parent domain contains a number of record types:

•NS (delegation) records: Hostnames of the DNS servers that are authoritative for the domain. You typically provide multiple NS records.

•A and AAAA (glue) records: For every NS record, you must provide either an A record or an AAAA record. Particularly if the hostnames in the NS records are contained in your own domain, the parent zone needs to contain glue A or AAAA records, which provide the IP addresses of the hostnames.

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

1.DNS settings controlled by your DNS registrar can typically be configured through a Web based interface. Contact your DNS registrar for details about its configuration interface.

2.Login to your domain configuration page and locate the list of name servers.

3.Each record consists of a Fully Qualified Domain Name (FQDN) and, optionally, corresponding IP addresses. To update these records, replace the FQDNs and IP addresses for your current DNS servers with those of your Traffic Managers.

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 Traffic Manager receives all DNS requests for the hostname to be load balanced. On receiving a request, the Traffic Manager forwards it to the appropriate DNS back end, and receives a list of IP addresses as a response. The Traffic Manager processes this list to select precisely which IP address it returns to the end user.

Parallel Deployment

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:

•Provide the redirection from "www.example.com" to "www.gslb.example.com".

•Delegate authority for "gslb.example.com" to the Traffic Manager.

Using either the internal 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 Traffic Manager. In the "example.com" zonefile, add the following entries:

; Delegation for gslb.example.com using the Traffic Manager.

gslb.example.com. IN NS stm1.gslb.example.com.

IN NS stm2.gslb.example.com.

 

; Glue records for gslb.example.com

stm1.gslb.example.com. IN A 192.0.2.11

stm2.gslb.example.com. IN A 192.0.2.12

 

; CNAME for www.example.com to parallel GLB-enabled name.

www.example.com. CNAME www.gslb.example.com.

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

The DNS client now sends a request for www.gslb.example.com to the Traffic Manager, and that 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 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.

If, in a parallel deployment, your DNS servers are not your Traffic Managers, the DNS servers for the parallel hostname (www.gslb.example.com) must not return the unmodified A records for the original hostname (www.example.com). Therefore, Ivanti strongly recommends that your top level DNS servers are different name servers from your back-end DNS servers.

It is also possible, although complex, to use split horizon DNS. However, with this approach care is needed to ensure that unmodified responses do not leak out.

If your back-end DNS servers are all Traffic Managers, this problem does not occur. Instead, you must ensure that the GLB Service is configured on all DNS Virtual Servers publicly serving the globally load balanced hostnames.

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 Traffic Managers. You can then configure many domains centrally from a single CNAME by setting up the back-end DNS service of your Traffic Manager deployment accordingly.

The Time-to-Live (TTL) Field

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.