Before you install a 3DNS Controller, you should do some careful planning for your network. The issues you need to consider vary, depending on your network environment:
As mentioned in Chapter 1 , all DNS servers can resolve names, but only primary DNS servers are an authoritative source for zone information.
This section provides examples of name resolution transactions for the following situations:
The name resolution process for either situation is similar. The difference is that when the primary DNS is outside of your network, name resolution requests for specified domains are delegated from the primary DNS to the 3DNS Controller. When a 3DNS Controller is the primary DNS, there is no delegation process.
If you're adding 3DNS Controllers into an existing network, you probably have an existing primary DNS in place. Figure 2.1 is an example of the name resolution process where the primary DNS is located outside of the 3DNS network.
The numbers in the illustration correspond to the steps of the process that follows.
The transaction process is as follows:
The choice of data center is based on collected metrics information and load balancing algorithms. This information is not collected during the actual transaction, but at specified intervals. Details on update intervals are given in Periodic task intervals, on page 7-8 . For details on the available load balancing modes, see Chapter 5, Load Balancing .
As mentioned earlier, you can configure a 3DNS Controller to act as the primary DNS for the domains it controls.
To migrate the primary DNS to a 3DNS Controller:
/etc/named-bootconf.pl /etc/named.boot > /etc/named.conf
Note: InterNIC changes typically take approximately 24 hours to process and confirm, and another 24 hours to propagate after your configuration becomes active. To avoid outages, always keep a secondary system configured and running during this transition.
Figure 2.2 shows a typical 3DNS transaction where the primary DNS is located on the 3DNS Controller that is the data collector. The numbers in the illustration correspond to the steps of the process described below.
In Figure 2.2 , note that part of line 7 is dotted. This is to indicate that the actual hardware for this step is not shown, due to the number of ways ISPs can configure their networks. The actual machines that handle all other transaction events are shown, so all other lines are solid.
This section describes issues to consider as you plan which 3DNS Controllers collect data directly from BIG/ip Controllers and hosts, and which 3DNS Controllers simply copy data from the collector 3DNS Controllers. When you are ready to configure data collectors and data copiers, see Defining data collectors and data copiers, on page 4-18 .
Remember that a primary DNS is the DNS that is authoritative for zone information. A secondary DNS can resolve names, but gets its database from a primary DNS. Similarly, a data collector 3DNS Controller collects metrics information, and a data copier 3DNS Controller copies metrics from the data collector at specified intervals.
If you have one 3DNS Controller, you must configure it to be a data collector. As a data collector, it will collect metrics from the BIG/ip Controllers and other host machines on your network. Note that you have the option of defining the 3DNS Controller as the primary DNS.
When you have more than one 3DNS Controller, you increase the reliability and efficiency of your network. However, you must decide how to handle metrics collection and zone information. For example, suppose you have two 3DNS Controllers, one in New York and one in Los Angeles. The following are some of the ways you can configure these two 3DNS Controllers. Although you can have more than two 3DNS Controllers, the purpose of these examples is to serve as a starting point in the planning process. These examples all assume that the primary DNS is a 3DNS Controller.
Note that the example figures in this section show only how metrics collection is handled, and not the name resolution process. Figures 2.1, on page 2-4 , and 2.2, on page 2-7 illustrate the name resolution process.
Figure 2.3 shows an implementation where both 3DNS Controllers act as primary DNS systems as well as data collectors.
In this case, both 3DNS Controllers perform metrics collection and both are authoritative sources for zone information.
Figure 2.4 shows an example where the 3DNS Controller in New York is the primary DNS and data collector. The 3DNS Controller in Los Angeles, however, is a secondary DNS and data copier.
In this case, the 3DNS Controller in New York performs metrics collection. The 3DNS Controller in Los Angeles does not collect metrics, but instead copies metrics from the 3DNS Controller in New York at specified intervals. As in Example A, the 3DNS Controller in New York is the authoritative source for zone information. The 3DNS Controller in Los Angeles is also capable of resolving name requests, but gets its zone information from the New York machine.
Figure 2.5 shows an example where both 3DNS Controllers are data collectors. The 3DNS Controller in New York is the primary DNS, and the 3DNS Controller in Los Angeles is a secondary DNS.
In this case, both 3DNS Controllers perform metrics collection. The 3DNS Controller in New York is the authoritative source for zone information. The 3DNS Controller in Los Angeles is also capable of resolving name requests, but gets its zone information from the New York machine.
Figure 2.6 shows an example where both 3DNS Controllers are primary DNS systems. The 3DNS Controller in New York is the data collector, and the 3DNS Controller in Los Angeles is a data copier.
In this case, both 3DNS Controllers are authoritative sources for zone information. The 3DNS Controller in New York is the only machine that collects metrics information.
Each configuration example has its advantages and disadvantages. You should evaluate each configuration option carefully before to determine which type of configuration is best suited to your network.
Using an international version of the 3DNS Controller, the version for use in countries that do not allow encryption, requires additional planning. This section explains how to configure an international 3DNS Controller, and also discusses configuration issues that you must address if you have a mixed environment where international 3DNS Controllers need to communicate with US 3DNS Controllers, and with US and international versions of the BIG/ip Controller and the big3d utility.
US 3DNS Controllers are different from international 3DNS Controllers only in the communication tools that they utilize:
Warning: The Install and Start big3d item on the 3DNS Maintenance menu installs the US or international version of the big3d utility depending on whether the 3DNS Controller from which you execute the command is a US version or an international version. In a mixed environment, we recommend that you manually install the appropriate version of the big3d utility on each BIG/ip Controller rather than using the Install and Start big3d menu item.
When you run the First-Time Boot utility to configure an international 3DNS Controller, certain screens are different from those you would normally see if you were running the First-Time Boot utility on a US 3DNS Controller. On US 3DNS Controllers, the First-Time Boot utility prompts you to configure an administrative IP address from which the 3DNS Controller accepts ssh connections. On international 3DNS Controllers, the First-Time Boot utility prompts you to configure an administrative IP address from which the 3DNS Controller accepts rsh connections.
The 3DNS Controller stores the administrative IP address for rsh and rcp connections in the /etc/hosts.allow file. Note that storing the administrative IP address in the /etc/hosts.allow file may be slightly different from other common rsh configurations where it is often stored in the /etc/hosts.equiv file.
All other configuration issues are automatically handled by the international 3DNS Controller.
There are two situations in which a 3DNS Controller needs to communicate with other 3DNS Controllers: when you synchronize configurations between one 3DNS Controller and another; and when data copiers copy metrics data from a data collector.
If you work in a mixed environment where you have both international and US 3DNS Controllers that need to communicate with each other, you must change the US 3DNS Controller configuration by enabling the remote login tools, including rsh and rcp. You do not need to make any configuration changes to international 3DNS Controllers.
To enable the remote login tools on a US 3DNS Controller, run the rsetup script from the command line. The rsetup script performs several essential steps to enable access for rsh and rcp, and we strongly recommend that you use the script rather than doing this manually.
International 3DNS Controllers use rsh and rcp to communicate with BIG/ip Controllers. Note that only BIG/ip Controller version 2.0.1PTF-03 supports rsh and rcp, and that you must explicitly enable these rlogin tools on each BIG/ip Controller that the international 3DNS Controller communicates with, regardless of whether the BIG/ip Controller is a US or an international version.
US 3DNS Controllers issue encrypted queries to big3d utilities that run on BIG/ip Controllers. In a mixed environment where a 3DNS Controller may have to issue queries to both US and international big3d utilities, you must disable iQuery encryption on the US 3DNS Controller. To disable encryption, set the following global variable to no:
The 3DNS Controller load balances DNS requests to individual virtual servers. A virtual server is a specific combination of a virtual IP address and a virtual port number.
Virtual servers can be managed by BIG/ip Controllers, or they can be managed by generic host servers, such as a standard network server, a web server, or an array controller. For this reason, the load balancing pools that you define in the 3DNS Controller configuration are broken down into two types:
These terms, vsb and vsh, also appear in the Web Administration tool.
Note: 3DNS Controllers do not collect metrics data or support dynamic load balancing for virtual servers managed by other host machines. However, 3DNS Controllers can perform all static load balancing modes for virtual servers managed by hosts.
The process of configuring virtual servers varies by type:
You may also want to review the following sections for more information:
The iQuery protocol is a UDP-based protocol used to communicate and exchange information between BIG/ip Controllers and 3DNS Controllers. All 3DNS Controllers that are configured as data collectors send queries to BIG/ip Controllers via port 245 or 4353 using the iQuery protocol. You can distribute return iQuery traffic across individual ephemeral ports, or you can use either port 245 or 4353 as a single port for return iQuery traffic. See Configuring iQuery options, on page 4-20 .
You can enable encryption for iQuery protocol transactions. See Enabling encryption on US 3DNS Controllers, on page 4-3 . However, if you have a 3DNS Controller in a country that does not allow encryption, see Working with international versions, on page 2-15 .
The big3d utility is the listener that runs on each BIG/ip Controller and 3DNS Controller, and it processes and responds to queries received from data collector 3DNS Controllers.
The big3d utility can be used only with BIG/ip software version 1.8.3 or later. To determine which version of big3d you are using, use the Check versions of named, BIG/ip kernel and needed big3d item on the 3DNS Maintenance menu.
To install and run the appropriate version of big3d on each BIG/ip Controller, use the Install and Start big3d item on the 3DNS Maintenance menu.
big3d configuration options are described in Configuring the big3d process, on page D-25 .
Before you install and configure 3DNS Controllers, it is helpful to understand how the probing process works. This section provides an overview of the probing process and an example of a typical sequence of events.
The 3DNS Controller collects a list of the local DNS servers that request name resolutions from the 3DNS Controller. For the purpose of load balancing future connection requests, the 3DNS Controller collects statistics about the paths (such as round trip time and packet completion rate) between each local DNS and each BIG/ip Controller that the 3DNS Controller manages. 3DNS Controller version 1.0.6 improves path statistics collection over older product versions in three ways:
For each requesting local DNS, you can view the current state of probing and discovery in the 3DNS Web Administration tool (see the Local DNS screen). There are six different probe and discovery states as shown in the following table:
|Needs Probe||Target has never been probed or scanned.|
|Idle||Target has been successfully probed and is waiting for next probe.|
|In Probe||Target is currently being probed.|
|Needs Discovery||Target failed a probe, and now needs to be scanned.|
|In Discovery||Target is currently being scanned.|
|Suspended||Target failed the scan and is no longer eligible for probing or scanning.|
The following global variables let you control the behavior of the probing and discovery mechanisms, and the way in which the 3DNS Controller uses path data to make load balancing decisions. For information on these variables and all other global variables, see The globals statement, on page 7-4 .
The following steps outline the typical sequence of events for probing and discovery of a local DNS server.
Table 2.1 lists all the ports and protocols used for 3DNS Controller communications.
|3DNS||BIG/ip||udp||4353||iQuery (when use_alternate_iq = yes)|
|BIG/ip||3DNS||udp||245||iQuery (when multiplex_iq = yes)|
|BIG/ip||3DNS||udp||4353||iQuery (when use_alternate_iq = yes and multiplex_iq = yes)|
|Admin||3DNS||tcp||4999||Web administration (HTTP)|
|3DNS||Admin||tcp||>1024||Web administration (HTTP)|
|LDNS||3DNS||tcp||53||DNS resolution and zone transfers|
|3DNS||LDNS||tcp||>1024||DNS resolution and zone transfers|
|BIG/ip||LDNS||tcp||53||Probing (rtt_probe_protocol = tcp or rtt_probe_dynamic = yes) (CISCO routers should "allow establish")|
|LDNS||BIG/ip||tcp||2000-2300||Probing (rtt_probe_protocol = tcp or rtt_probe_dynamic = yes) (CISCO routers should "allow establish")|
|3DNS||LDNS||tcp||53||Probing (rtt_probe_protocol = tcp or rtt_probe_dynamic = yes) (CISCO routers should "allow establish")|
Note that you might not need to allow access on all these ports on your network, because you may not need all services. For example, unless you have an international version of 3DNS Controller, you won't use RSH/RCP, which is the only service that requires port 514.
Figure 2.7 shows a subset of the information in the table. For legibility purposes, the specific services are not shown in the figure.