Applies To:
Show Versions
3-DNS Controller versions 1.x - 4.x
- 1.0.6
2
Preparing for Installation
- General network considerations
- Planning the primary DNS
- Integrating 3DNS Controllers
- Working with international versions
- Understanding virtual servers
- The iQuery protocol
- Setting up the big3d utility
- Understanding probing
- Port and protocol usage
General network considerations
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:
- Decide where the primary DNS should be located. Should it remain on its own machine, inside or outside of your network, or do you want to migrate the existing primary DNS to a 3DNS machine? See the following section, Planning the primary DNS .
- Decide how to integrate 3DNS Controllers and where to locate data collectors and data copiers. Note that all 3DNS Controllers are data collectors until you specify otherwise. See Integrating 3DNS Controllers, on page 2-8 .
- If you are preparing to install BIG/ip® Controllers for the first time as well as 3DNS Controllers, you'll need to do additional planning. To start, review both this chapter and Chapter 2, Preparing for Installation, in the Administrator Guide for the BIG/ip Controller.
- If you are preparing to incorporate single network servers or other server array controllers, there may be additional issues to consider, depending on the different products' requirements and configuration.
- Allow access to the necessary ports for communications between 3DNS Controllers, BIG/ip Controllers, and other network equipment. Consult Port and protocol usage, on page 2-25 for details.
Planning the primary DNS
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 primary DNS is located outside of your network.
- The primary DNS is migrated to a 3DNS Controller. The migration procedure is also provided.
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.
Working with a primary DNS outside of your network
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.
Figure 2.1 Name resolution process (primary DNS outside of 3DNS network)
The transaction process is as follows:
- The client connects to an Internet Service Provider (ISP) and queries the local DNS to resolve the domain name www.domain.com.
- If the information is not already in the local DNS' cache, the ISP's local DNS queries a root server (such as InterNIC's root servers). The root server returns the IP address of a DNS associated with domain.com.
- The ISP's local DNS connects to the primary DNS to resolve domain.com. The primary DNS refers the local DNS to the 3DNS Controller in New York because a subdomain was delegated to the 3DNS Controller, making the 3DNS Controller the authoritative source for this subdomain. The primary DNS created an alias (CNAME) for the domain name to a name in the subdomain that is managed by the 3DNS Controller. This alias is the name that is made public.
- The local DNS queries the 3DNS Controller in New York for the name resolution, which responds with the IP address to use for the connection.
- The local DNS passes this IP address back to the client.
- The client connects to the selected virtual server, which is managed by the BIG/ip Controller in Los Angeles, via the ISP. Note that a portion of the line is dotted to indicate that the actual hardware for this step is not shown, due to the number of ways ISPs can configure their networks.
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 .
Migrating the primary DNS to a 3DNS Controller
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:
- If you are migrating from a BIND 4 system to a 3DNS Controller, you must convert the named.boot file using the /etc/named-bootconf.pl Perl script. Run the script by typing the following on the command line:
/etc/named-bootconf.pl /etc/named.boot > /etc/named.conf
- Find the primary DNS' resource records and copy them to a directory of the same name on the 3DNS Controller.
- Give the old DNS machine's IP address to the 3DNS Controller, or modify all the domains managed by the 3DNS Controller at InterNIC by replacing or adding the IP address to each domain's registration record with a modify domain request.
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.
Using a 3DNS Controller as your primary DNS
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.
Figure 2.2 Name resolution process (3DNS Controller as primary DNS)
The transaction process is similar to that shown in Figure 2.1 . The steps in Figure 2.2 are as follows:
- The client connects to an Internet Service Provider (ISP) and queries the local DNS to resolve the domain name www.domain.com.
- If the information is not already in the local DNS' cache, the ISP's local DNS queries a root server (such as InterNIC's root servers).
- The root server returns the IP address of a DNS associated with www.domain.com.
- The ISP's local DNS connects to the primary DNS (in this case, the primary DNS is the 3DNS Controller) for www.domain.com. The 3DNS Controller handles the name resolution.
- The 3DNS Controller responds to the local DNS with the IP address to use for the connection.
- The local DNS passes this IP address to the client.
- The client is connected to the selected virtual server, which is managed by the BIG/ip Controller in Los Angeles, via the ISP.
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.
Integrating 3DNS Controllers
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.
Note: Metrics collection occurs independently of name resolution.
Working with a single 3DNS Controller
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.
Working with multiple 3DNS Controllers
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.
Example A
Figure 2.3 shows an implementation where both 3DNS Controllers act as primary DNS systems as well as data collectors.
Figure 2.3 Multiple 3DNS Controllers
In this case, both 3DNS Controllers perform metrics collection and both are authoritative sources for zone information.
Example B
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.
Figure 2.4 Multiple 3DNS Controllers
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.
Example C
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.
Figure 2.5 Multiple 3DNS Controllers
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.
Example D
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.
Figure 2.6 Multiple 3DNS Controllers
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.
Advantages and disadvantages
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.
Multiple primary DNS systems
- Advantages
Having more than one primary DNS can be useful in networks where there are a large number of secondary DNS systems. Adding another primary DNS is one possible solution for an overloaded primary DNS. - Disadvantages
Creating more primary DNS systems creates more work for the administrator. As the administrator, you must synchronize database files between the two systems, or keep track of the differences between each system's zone files.
Secondary DNS
- Advantages
Adding a secondary DNS is the simplest way to add new servers for your domain. - Disadvantages
An overly large number of secondary DNS systems may overtax the primary DNS. If this is a problem, adding another primary DNS is one possible solution.
Multiple data collectors
- Advantages
Having multiple 3DNS Controllers configured as data collectors adds reliability to your network, because more than one machine has the most current metrics information and can answer queries most intelligently. - Disadvantages
Having multiple data collectors means that more than one machine is collecting metrics from the BIG/ip Controllers and host machines they manage. This is not a problem unless you have a large number of data collectors. In this case, the BIG/ip Controllers and host machines may be overloaded having to respond to queries from multiple 3DNS Controller.
Data copiers
- Advantages
Configuring a 3DNS Controller as a data copier can reduce the load on the managed BIG/ip Controllers and host machines, because it reduces the number of queries that the controllers and hosts need to respond to. - Disadvantages
Data copiers may not have the most current metrics information.
Working with international versions
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.
Differences between US and international 3DNS Controllers
US 3DNS Controllers are different from international 3DNS Controllers only in the communication tools that they utilize:
- US 3DNS Controllers
US 3DNS Controllers allow secure remote connections via ssh (secure shell), and allow secure copying using scp (secure copy). They also support encryption for iQuery communications between the 3DNS Controller and US big3d utilities that run on BIG/ip Controllers. To allow US 3DNS Controllers to communicate with international 3DNS Controllers, US 3DNS Controllers include rsh (remote shell) and rcp (remote copy) tools, but they are initially disabled. If you need to configure a US 3DNS Controller to communicate with international 3DNS Controllers, you must explicitly enable the rsh and rcp tools on the US 3DNS Controller. If you need to configure US 3DNS Controllers to communicate with international versions of the big3d utility, you must disable iQuery encryption on US 3DNS Controllers. - International 3DNS Controllers
International 3DNS Controllers allow remote connections using rsh (remote shell), and allow copying using rcp (remote copy). International 3DNS Controllers do not encrypt iQuery communications between the 3DNS Controller and the big3d utility that runs on BIG/ip Controllers. However, this does not prevent an international 3DNS Controller from successfully making iQuery requests to a US version of the big3d utility.
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.
Configuring international 3DNS Controllers
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.
Allowing communications between US and international
3DNS Controllers
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.
Note: Enabling rsh and rcp does not prevent US 3DNS Controllers from using encryption when they communicate with other US 3DNS Controllers.
Allowing communications between international 3DNS Controllers and BIG/ip Controllers
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.
To enable the rlogin tools on a BIG/ip Controller
- Use ftp to copy the /usr/contrib/bin/rsetup file from the 3DNS Controller to /usr/contrib/bin/rsetup on the BIG/ip Controller.
- On the BIG/ip Controller, update the permissions in the /usr/contrib/bin/rsetup file to match the corresponding file permissions as they are set on the 3DNS Controller.
- From the command line, run the rsetup script.
Note: You can disable rsh and rcp access at any time by changing the bigip.open_rsh_ports system control variable to 0.
Allowing communications between US 3DNS Controllers
and international big3d utilities
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:
encryption no
Understanding virtual servers
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:
- vsb
Vsb pools load balance virtual servers associated with BIG/ip Controllers. - vsh
Vsh pools load balance virtual servers associated with hosts.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:
- Configuring vsb pools
First define each BIG/ip Controller and its virtual servers in a bigip statement, and then configure one or more pools in the wideip statement using that BIG/ip Controller's virtual servers. - Configuring vsh pools
First define each host and its virtual servers in a host statement, and then configure one or more pools in the wideip statement using that host's virtual servers.You may also want to review the following sections for more information:
- The bigip statement, on page 7-16 . This section provides syntax for adding BIG/ip Controllers and their virtual servers.
- The host statement, on page 7-19 . This section provides syntax for adding host machines and their virtual servers.
- Defining a wide IP, on page 4-5 . This section provides a step-by-step guide to configuring wide IPs so that you can perform load balancing.
- Example syntax for global availability, on page 5-30 . This section provides examples for common load balancing situations.
- Chapter 7, Statements and Comments . This chapter provides complete syntax for all statements.
- The Administrator Guide for the BIG/ip Controller. Provides information on configuring virtual servers on the BIG/ip Controller.
The iQuery protocol
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 .
Setting up the big3d utility
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 .
Understanding probing
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.
Path probing and the discovery factory
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:
- Running multiple probing factories
Each big3d utility runs multiple probing factories at one time, and can process up to 20 times the number of probe targets than in earlier versions. - Dynamic probe protocol switching
The big3d utility dynamically switches to the alternate probe protocol (specified by rtt_probe_dynamic) in an effort to generate a successful response if the initial probe on a local DNS fails. - Implementing the discovery factory
The big3d utility supports a discovery factory. If the probing factories fail to get a response from port 53 on a given local DNS using either probe protocol, the 3DNS Controller sends the target local DNS to the discovery factory. The discovery factory scans the target, looking for an open port on which it can receive and respond to a probe. If the discovery factory finds an open port, the 3DNS Controller uses that port for future probes. If it cannot find an open port, the target is no longer probed.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:
State Description 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 .
rtt_probe_dynamic
rtt_port_discovery
rtt_discovery_method
rtt_sample_count
rtt_packet_length
rtt_probe_protocol
timer_get_path_data
path_max_refreshes
path_ttl
paths_never_die
paths_noclobber
check_dynamic_depends
The probing and discovery process
The following steps outline the typical sequence of events for probing and discovery of a local DNS server.
Note: In this example, rtt_probe_protocol is set to icmp and rtt_probe_dynamic is set to yes.
- The 3DNS Controller sends a new set of target local DNS servers to the big3d utility for probing. The more often a target local DNS requests name resolutions from the 3DNS Controller, the more frequently the 3DNS Controller probes the target and refreshes the target's path metrics.
- The big3d utility begins running the target local DNS servers through its probing factories.
- For each target local DNS server, the target is first probed using the rtt_probe_protocol set by the administrator.
- If the first probe fails, the big3d utility switches the rtt_probe_protocol to the alternate probe protocol, and again probes the target on port 53, this time using the alternate probe protocol.
- After the big3d utility runs all target local DNS servers through the probing factory, the big3d utility returns the probe results to the 3DNS Controller. The returned metrics include the round trip time, the number of successful replies, and the successful probe protocol.
- The 3DNS Controller periodically scans the cache for targets that do not have metrics returned from a big3d utility. The 3DNS Controller determines whether probing failed on port 53 for each of these targets. If so, the 3DNS Controller sends the targets to any available big3d for processing in the discovery factory, which determines whether the target has another open port that can be used for probing.
- For each target local DNS, the big3d discovery factory scans a short list of alternate ports, looking for a response. The port numbers it scans include 21, 22, 23, 25, 80, 110, 113, 139, 248, 1127, 1524, 1525, and 2105. These ports are shuffled before each scan. The discovery factory stops scanning the target upon the first successful response.
- If the discovery factory fails to get a response from all ports on the short scan list, the discovery factory then scans the target one final time using the ports specified in the /etc/services file (stored on the machine where that big3d utility resides). You can edit the /etc/services file to control which ports are scanned when the discovery factory makes a second pass. (Be sure to make a backup copy of the /etc/services file before you edit it.) Again, note that the port list is shuffled before each scan.
- After all target local DNS servers have been run through the discovery factory, the big3d utility returns the results back to the 3DNS Controller.
- If the 3DNS Controller receives a failed target back from the discovery factory, it switches the target local DNS system to the Suspended state. The 3DNS Controller no longer attempts to probe or scan the target, nor does it use path-related dynamic load balancing modes to resolve requests issued by the local DNS system. If the preferred load balancing method is set to a path-related dynamic mode, the 3DNS Controller instead uses a load balancing mode specified by either the alternate or the fallback load balancing method in the wideip statement.
Port and protocol usage
Table 2.1 lists all the ports and protocols used for 3DNS Controller communications.
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.
