This chapter covers the planning issues that you need to address before you install and set up the 3-DNS Controller. It explains the three different phases of an installation, along with load balancing configuration options and important DNS planning issues. If you plan to do a simple configuration, briefly review the hardware setup and network setup requirements, along with the load balancing options. If you plan to do a more advanced configuration, we recommend that you read about each advanced feature you want to work with in Chapter 6 before you begin the installation.
Be sure to review the DNS zone file management section included later in this chapter. It provides an important overview of the process involved in setting up a 3-DNS Controller that runs as a master DNS server, as well as integrating 3-DNS Controllers into networks that have an existing master DNS server.
You can set up a basic 3-DNS Controller configuration, or an advanced 3-DNS Controller configuration. Regardless of whether you are creating a basic or an advanced configuration, you always go through three installation phases:
DNS zone file integration happens at different times, depending on how you decide to handle DNS zone file management, and depending on whether you are installing new 3-DNS Controllers in your network, or upgrading existing 3-DNS Controllers in your network. Issues relating to DNS zone file management are covered in Planning DNS zone file management, on page 2-32 .
When you configure the 3-DNS Controller, you have two configuration tool options:
If you have worked with previous versions of the 3-DNS Controller, you can view statement syntax in the Configuration utility. To display the existing configuration at any time, click the View Configuration button in the Conf column of certain screens in the configuration utility.
Warning: We recommend that you do not switch between using the Configuration utility and manually configuring the 3-DNS Controller. If you manually configure a 3-DNS Controller and then attempt to use the Configuration utility to modify the configuration, you risk losing custom configuration settings not supported by the Configuration utility.
In the hardware setup phase, you connect the 3-DNS Controller hardware to the network, and run the First-Time Boot utility on each of the 3-DNS Controllers in the network. The First-Time Boot utility is a command line wizard that helps you define basic required system settings such as the IP address, host name, root user ID, and other information necessary for the controller and its web server to be accessible over the network.
When you run the First-Time Boot utility, you must work on a keyboard and monitor, or a serial terminal, connected directly to the 3-DNS Controller. However, after you complete the hardware setup phase, you can finish the remaining installation tasks from a remote administrative workstation.
The prompts in the First-Time Boot utility are generally self-explanatory, and you should be able to answer them as long as you prepare the following information before you start running the utility:
Before you start the hardware setup, you may want to review the following items which address configuration and management issues for redundant systems, systems that use more than one network interface, and DNS zone file management.
If you are setting up a stand-alone unit, you need one IP address and host name for each of the interfaces you plan to connect to the network. If you are setting up a redundant system, you need one IP address for each network interface card in each unit, as well as a shared IP alias for the primary network interface, and a shared IP alias for the secondary network interface (if you are connecting the redundant system to more than one network).
Hardware-based fail-over is a redundant system that connects two 3-DNS Controller units directly to each other using a fail-over serial cable. Network-based fail-over is a redundant system where two units are either connected to each other directly using an Ethernet cable, or they are connected indirectly via an Ethernet network. Of the two units in a redundant system, one runs as the active unit, managing all DNS resolution requests, and the other runs as the standby unit, waiting to take over in case the active unit fails and reboots. The communication between the units, such as fail-over notification, runs across either the fail-over cable in the hardware-base redundant system, or the network in the network-based redundant system.
When you run the First-Time Boot utility, it prompts you to enter the IP address of the other unit in the system.
The 3-DNS Controller tracks two key aspects of the system to validate system performance. In a redundant system, there are two events that indicate a system failure and trigger a fail-over.
If you include a redundant system in a sync group, you include the system by specifying the system's shared IP alias. When a controller in the sync group broadcasts new information to the redundant system, only the active unit receives the updated information. The moment a fail-over occurs and the standby unit becomes active, the next synchronization check compares timestamps on the configuration files and immediately updates the unit with the current system configuration, path metrics, and DNS zone files.
If you have a sync group that includes a redundant system, you may want to make test changes to the configuration on the standby unit, without having those changes synchronized to the other controllers in the group. As long as the unit runs as a standby, the changes remain local. Once you validate your changes and you are ready to broadcast them to the other controllers in the group, you can run the bigpipe fo command on the active unit to force a fail-over. After the system fails over to the standby unit with your new configuration changes, those changes broadcast to the other controllers in the group during the next synchronization pass.
Note that you always run the risk of having the active unit initiate a fail-over to the standby unit before you can verify that the configuration changes are complete. Although the 3-DNS Controller does not commit any configuration changes that violate syntax rules, there is always the possibility that a fail-over may occur before you complete your configuration changes.
The First-Time Boot utility prompts you to configure the primary network interface, and then asks if you want to configure more interfaces, or if you want to skip to the next section of the utility. If you want to configure another network interface, you simply enter the same type of information you entered for the first interface. The other interfaces can connect to a separate network, or they can act as redundant paths to the same network that the first interface is connected to.
The First-Time Boot utility asks you if you want to use the NameSurfer application as the master for DNS zone files. We recommend that you always run NameSurfer as the master for DNS zone files. When you define or modify wide IPs in the Configuration utility, NameSurfer automatically makes the corresponding changes to the DNS zone files. The NameSurfer application also provides you with easy management of high-level domain zone files unrelated to the wide IP configuration.
If you plan on transferring existing BIND files from a master DNS server to the 3-DNS Controller, you do not configure NameSurfer when you run the First-Time Boot utility; you configure the application later on in the installation process. For more details about this and other DNS zone file management issues, see Planning DNS zone file management, on page 2-32 .
After you finish running the First-Time Boot utility and get each controller connected to the network, you can do the network setup and load balancing configuration on one controller, and let the sync group feature automatically broadcast the configuration to the other controllers in the network. You do not have to configure 3-DNS Controllers individually, unless you are planning an advanced configuration that requires different configurations for different data centers, or you are doing the configuration manually.
During the network setup phase, you define three basic aspects of the network layout, in the following order:
Note: During the network setup phase of configuration, we recommend that you connect to the 3-DNS Controller from a remote workstation where you can complete the remaining configuration tasks using the web-based Configuration utility.
It is important that you define all of your data centers before you begin defining servers. When you define a server, you specify the data center where the server runs by choosing a data center from the list of data centers you have already defined.
To define a data center, you need only specify the data center name. To define a server, however, you need to specify the following items:
The most important part of planning data centers and servers is to decide how to set up the big3d agent, and which ports you need to open for communications between the controllers in your network. The following sections in this chapter, Setting up data collection with the big3d agent, on page 2-9 , and Setting up communications between 3-DNS Controllers, BIG-IP Controllers, and big3d agents, on page 2-17 , provide help with determining how both of these issues affect your installation.
The time tolerance value is a global variable that defines the number of seconds that one 3-DNS Controller's time setting is allowed to be out of sync with another 3-DNS Controller's time setting. If the difference between the times on the controllers is greater than the time tolerance, the time setting on the controller running behind is reset to match the controller with the most recent time. For example, if the time tolerance is 5 seconds, and one 3-DNS Controller is running 10 seconds ahead of the other, the controller running behind has its time reset to match the one running 10 seconds ahead. If the second controller was running only 2 seconds ahead of the other, the time settings would remain unchanged. The values are 0, 5, and higher (values of 1-4 are automatically set to 5, and 0 turns off time syncing). The default setting is 10 seconds.
The time setting on 3-DNS Controllers is important because a 3-DNS Controller compares time stamps on files when deciding whether to synchronize files with other 3-DNS Controllers in the sync group.
The big3d agent collects performance information on behalf of the 3-DNS Controller. The big3d agent runs on both 3-DNS Controllers and BIG-IP Controllers. The default setting is to run a big3d agent on all controllers in the network, but you can turn off the big3d agent on any controller at any time.
Setting up the big3d agents involves the following tasks:
A big3d agent collects the following types of performance information used for load balancing. This information is broadcast to all 3-DNS Controllers in your network.
To install the big3d agent on the BIG-IP Controllers in your network, log on to the 3-DNS Controller using either a remote shell, or the serial terminal or keyboard and monitor attached directly to the controller. At the command prompt, type 3dnsmaint to open the 3-DNS Maintenance menu and choose the Install and Start big3d command.
To gather performance information, the big3d agent uses different types of factories. A factory is a process which collects different types of data. The big3d agent currently supports five factory types:
The standard configuration specifies that each BIG-IP Controller and 3-DNS Controller in the network runs a big3d agent using five prober factories, one SNMP factory, one discovery factory, no hops factories, and the two default factories. In the BIG-IP Controller or 3-DNS Controller server definition, you can change the number of factories that the big3d agent runs. For example, the default number of hops factories is set to 0; if you want to run a hops factory, you change the setting to 1 or more.
The big3d agents collect and broadcast information on demand. The principal 3-DNS Controller in the sync group issues a data collection request to all big3d agents running in the network. In turn, the big3d agents collect the requested data using the factories, and then broadcast that data to all 3-DNS Controllers running in the network, including the principal controller that issued the request.
The 3-DNS Controller tracks the state of path data collection for each LDNS that has ever requested a name resolution from the controller. Table 2.1 shows the six states that can be assigned to an LDNS. Note that you can view the state of LDNS servers in the Local DNS Statistics page in the Configuration utility.
|Needs Probe||The big3d agent has never collected data for the LDNS, or the data has expired.|
|Idle||The big3d agent successfully collected data for the LDNS, and is waiting for the next collection request.|
|In Probe||The big3d agent is currently collecting data for the LDNS.|
|Needs Discovery||The big3d agent failed to collect data for the LDNS using its standard protocols and ports, and now needs to run the LDNS through a discovery factory.|
|In Discovery||The big3d agent is currently running the LDNS through a discovery factory to look for an alternate available port.|
|Suspended||The big3d agent failed to discover a port open for data collection, and the LDNS is no longer eligible for data collection requests.|
You must run a big3d agent on each BIG-IP and 3-DNS Controller. If you are using advanced load balancing modes, you must have a big3d agent running on at least one controller in each data center to gather the necessary path metrics.
The load on the big3d agents depends on two factors: the time-to-live (TTL) settings that you assign to the different types of data the agents collect, and the number of factories that each agent runs. The shorter the TTLs, the more frequently the agent needs to refresh the data. While short TTLs guarantee that you always have valid data readily available for load balancing, they also increase the frequency of data collection. The more factories a big3d agent runs, the more metrics it can refresh at one time, and the more quickly it can refresh data for the 3-DNS Controller.
Another factor that can affect data collection is the number of client LDNS servers that make name resolution requests. The more LDNS servers that make resolution requests, the more paths that the big3d agent has to collect. While round trip time for a given path may vary constantly due to current network load, the number of hops along a network path between a data center and a specific LDNS does not often change. Consequently, you may want to set short TTL settings for round trip time data so that it refreshes more often, but set high TTL settings for hops data because it does not need to be refreshed often.
The host probing feature uses SNMP conversations to collect performance data for the host. The 3-DNS Controller uses this performance data for advanced load balancing modes such as Packet Rate and Quality of Service. The big3d agent uses a special SNMP factory to collect metrics from host servers. The SNMP factory establishes a conversation with an SNMP agent running on a given host server. From the SNMP conversation, the factory determines the following types of information about the host:
The Configuration utility displays the host metrics in the Host statistics screen. The 3-DNS Controller bases the advanced load balancing decisions on the packet rate metrics, but the Host screen displays the other metrics as well, for your convenience.
The SNMP probing feature requires that each host run an SNMP agent, and that there is open network communication between the hosts and the big3d agents in the data centers. Certain firewall configurations block SNMP communications, and you may need to verify that the firewalls in your network allow SNMP traffic to pass through. The 3-DNS Controller supports the following common SNMP agents for host probing:
In addition to properly configuring these agents on the hosts themselves, you need to specify SNMP host probing settings in two places in the 3-DNS Controller configuration. First, when you define a BIG-IP Controller or 3-DNS Controller server, you set the big3d agent to run at least one SNMP factory. Second, when you define the host servers, you configure specific SNMP agent settings for each host. For example, you need to specify the type of agent running on the host as well as the community string that allows access to the SNMP agent.
A sync group is a group of 3-DNS Controllers that share information. In a sync group, a principal 3-DNS Controller issues requests to the big3d agents to gather metrics data. Both the principal controller and the receiver 3-DNS Controllers in the group receive broadcasts of metrics data from the big3d agents. All controllers in the group also receive broadcasts of updated configuration settings from the 3-DNS Controller that has the latest configuration changes.
When you define the sync group, select 3-DNS Controllers from the list of servers you have already defined. The sync group lists the controllers in the order in which you selected them. The first controller in the list is the principal 3-DNS Controller. The remaining controllers in the list are receiver 3-DNS Controllers. If the principal controller becomes disabled, the next controller in the list becomes the principal 3-DNS Controller until the original principal controller comes back online.
The sync group feature synchronizes individual configuration files, such as wideip.conf and other files that store system settings. You have the option of adding files to the synchronization list.
The controllers in a sync group operate as peer servers. At set intervals, the sync daemon compares the timestamps of the configuration files earmarked for synchronization on all of the controllers. If the timestamp on a specific file differs between controllers, the controller with the latest file broadcasts the file to all of the other controllers in the group.
There are three different communication issues that you need to resolve when you set up communication between controllers running in your network:
Figure 2.1 shows the ports necessary for administrative communication between individual 3-DNS Controllers, and also between 3-DNS Controllers and administrative workstations.
Figure 2.2 shows the ports necessary for iQuery communication between 3-DNS Controllers and big3d agents that run on 3-DNS or BIG-IP Controllers.
Figure 2.3 shows the ports necessary for path probing between 3-DNS Controllers and LDNS servers.
The 3-DNS Controllers need to communicate with each other in order to synchronize configuration and performance data. If you use exclusively crypto 3-DNS Controllers (those which use ssh and scp), or exclusively non-crypto 3-DNS Controllers (those which do not use ssh and scp), the communication tools set up by the First-Time Boot utility are all you need. Crypto controllers all use ssh and scp, and non-crypto controllers all use rsh and rcp.
If you work in a mixed environment where some 3-DNS Controllers are crypto, and other 3-DNS Controllers are non-crypto, you need to enable the rsh and rcp tools on the crypto 3-DNS Controllers. Though the rsh and rcp tools come pre-installed on the crypto 3-DNS Controllers, you must explicitly enable these tools on the crypto 3-DNS Controllers. You can easily do this by running the rsetup script or the config_rshd script from the command line, or you can enable the tools when you run the First-Time Boot utility.
Table 2.2 shows the ports and protocols that 3-DNS Controllers use to communicate with each other.
|Crypto 3-DNS Controller||Crypto 3-DNS Controller||tcp||<1023||22||SSH/SCP|
|Crypto 3-DNS Controller||Non-crypto
|Crypto 3-DNS Controller||tcp||>1024||514||RSH/RCP|
In order to copy big3d agents from the 3-DNS Controllers to the BIG-IP Controllers, the 3-DNS Controllers need to communicate with BIG-IP Controllers. If you use exclusively crypto 3-DNS Controllers and crypto BIG-IP Controllers, or exclusively non-crypto 3-DNS Controllers and non-crypto BIG-IP Controllers, the communication tools set up by the First-Time Boot utility are all you need. Crypto controllers all use ssh and scp, and non-crypto controllers all use rsh and rcp.
However, if you work in a mixed environment where some controllers are crypto, and other controllers are non-crypto, you need to enable the rsh and rcp tools on the crypto controllers. These tools come pre-installed on all crypto 3-DNS and BIG-IP Controllers, but you must explicitly enable them as described following.
From the command line, run the rsetup script.
Table 2.3 shows the ports and protocols that 3-DNS Controllers use to communicate with BIG-IP Controllers. For more information about using rsh and rcp tools on the BIG-IP Controller, refer to the BIG-IP Controller Administrator Guide.
|From||To||Protocol||From Port||To Port||Purpose|
|Crypto 3-DNS Controller||Crypto BIG-IP Controller||tcp||<1023||22||SSH/SCP|
|Crypto 3-DNS Controller||Non-crypto
|Crypto 3-DNS Controller||N/A||N/A||N/A||N/A|
The iQuery protocol can use one of two ports to communicate between the big3d agents and the 3-DNS Controllers. The ports used by iQuery traffic change, depending on whether the traffic is inbound from the big3d agent or outbound from the 3-DNS Controller.
Table 2.4 shows the port numbers and corresponding protocols used for iQuery traffic.
|From||To||Protocol||From Port||To Port||Purpose|
|3-DNS Controller||big3d agent||udp||245, 4354||245||Old standard iQuery port for outbound traffic|
|3-DNS Controller||big3d agent||udp||4353 or 4354||4353||Alternate iQuery port for outbound traffic (open this port only when the use_alternate_iq global variable is set to yes)|
|big3d agent||3-DNS Controller||udp||245 or 4353||4354||Ephemeral port used for inbound iQuery traffic (when multiplex_iq is set to no)|
|big3d agent||3-DNS Controller||udp||245||245||Single port used for multiplexed inbound iQuery traffic (open this port only when the multiplex_iq global variable is set to yes)|
|big3d agent||3-DNS Controller||udp tcp||4353 4354 4353||4353 4353 4354||Single port used for multiplexed inbound iQuery traffic (open this port only when both the use_alternate_iq and the multiplex_iq global variables are set to yes)|
|big3d agent||host SNMP agent||udp||>1024||161||Ephemeral ports used to make SNMP queries for host statistics|
|host SNMP agent||big3d agent||udp||161||>1024||Ephemeral ports used to receive host statistics via SNMP|
Note that if you run big3d agents in a mixed crypto/non-crypto environment, the crypto controllers automatically turn off Blowfish encryption when communicating with non-crypto big3d agents. When communicating with crypto big3d agents, however, crypto 3-DNS Controllers always use Blowfish encryption by default, although you can manually disable it if you prefer.
The payload information of an iQuery packet contains information that potentially requires translation when there is a firewall in the path between the big3d agent and the 3-DNS Controller. Only packet headers are translated by the firewall, payloads are not.
The iQuery translation option resolves this issue. With iQuery translation turned on, the iQuery packet stores the original IP address in the packet payload itself. When the packet passes through a firewall, the firewall translates the IP address in the packet header normally, but the IP address within the packet payload is preserved. The 3-DNS Controller reads the IP address out of the packet payload, rather than out of the packet header.
In the example configuration shown in Figure 2.4 , a firewall separates the path between a BIG-IP Controller running a big3d agent and the 3-DNS Controller. The packet addresses are translated at the firewall. However, addresses within the iQuery payload are not translated, and they arrive at the BIG-IP Controller in their original states.
The following tables show the other ports and protocols that 3-DNS Controllers use for communication. Table 2.5 shows the ports that 3-DNS Controllers use for remote administrative connections to the 3-DNS web server.
|Remote Workstation||Crypto 3-DNS Controller||tcp||443||Connection to secure web server|
|Remote Workstation||Non-crypto 3-DNS Controller||tcp||80||Connection to standard web server|
Table 2.6 shows the ports on which the 3-DNS Controller receives and responds to DNS resolution requests issued by LDNS servers.
|LDNS||3-DNS Controller||udp||53 or >1024||53||DNS resolution requests|
|3-DNS Controller||LDNS||udp||53||53 or >1024||DNS resolution answers|
Table 2.7 shows the ports that the big3d agent uses when collecting path data for LDNS servers.
|big3d agent||LDNS||icmp||N/A||N/A||Probing using ICMP pings|
|big3d agent||LDNS||tcp||2000-12000||53||Probing using TCP (CISCO routers should "allow establish")|
|LDNS||big3d agent||tcp||53||2000-12000||Probing using TCP (CISCO routers should "allow establish")|
|big3d agent||LDNS||udp||2000-12000||33434||UDP probing and traceroute|
|LDNS||big3d agent||icmp||N/A||N/A||Replies from ICMP, UDP pings, or traceroute probes|
|big3d agent||LDNS||dns_ver dns_dot||>1024||53||DNS version or dot queries|
|LDNS||big3d agent||dns_ver dns_dot||53||>1024||DNS version or dot response|
The big3d agent can run on either a 3-DNS Controller or a BIG-IP Controller. If you run a big3d agent on a BIG-IP Controller and you set the SNMP probing factory count to 1 or higher, the big3d agent automatically opens UDP ports to allow for SNMP communications. If you do not want to open UDP ports for this purpose, you need to set the SNMP factory count to 0.
The final phase of installing 3-DNS Controllers is setting up the load balancing configuration. Load balancing configurations are based on pools of virtual servers. When the 3-DNS Controller receives a connection request, it uses a load balancing mode to determine which virtual server in a given pool should receive the connection. The virtual servers in the pool can be the virtual servers managed by BIG-IP Controllers, or virtual servers managed by a generic host server, or they can be individual host servers themselves. Note that the 3-DNS Controller continuously verifies which virtual servers in the pool are currently available to accept load balanced connections.
Simple configurations typically use a single pool of virtual servers and a load balancing mode, such as Round Robin or Hops, that does not require significant additional configuration steps. More advanced load balancing configurations can use multiple pools, customizable load balancing modes, and other advanced traffic control features, such as topology-based access control and production rules. If you plan on implementing a more complex configuration, you may want to refer to Chapter 6 for additional details about advanced load balancing features.
The wide IP key is the same address as the domain name. The wide IP key binds the information from DNS to the 3-DNS Controller, and indicates to DNS that the 3-DNS Controller (within the named process) should attempt to handle requests to this domain name. This allows the 3-DNS Controller to resolve the request by making a decision based upon its metric database and returning a better answer. Each wide IP definition must have its own unique address.
The wide IP key is sometimes referred to as the fallback address. When the preferred, alternate, and fallback load balancing modes (as specified in the wide IP definition) fail, the 3-DNS Controller instructs the DNS to issue its original answer. When this happens, the wide IP key is called the fallback address.
The 3-DNS Controller offers several different load balancing modes. Basic, static modes base load balancing on a pre-defined distribution pattern. More advanced, dynamic modes base load balancing on current network information such as the round trip time between a requesting client and a web server.
Basic load balancing modes distribute connections based on pre-defined distribution patterns, and do not take current server or network performance into account. The 3-DNS Controller supports the following basic load balancing modes:
Advanced load balancing bases connection distribution on current server and network performance information gathered by the big3d agent. The different dynamic load balancing modes incorporate different performance factors.
Before the 3-DNS Controller selects a virtual server to receive a connection, it verifies that the virtual server is up and available. Certain types of network traffic, such as FTP traffic or e-commerce traffic, require that more than one port be available in order for the client's requests to be properly handled. For example, FTP servers use both ports 20 and 21, while e-commerce sites typically require that both ports 80 and 443 are available to handle HTTP and SSL traffic.
When you set up a load balancing configuration, you can define a list of ports that are verified on each virtual server before the virtual server is made available to receive load balanced connections.
LDNS round robin is an attribute that you can use in conjunction with any load balancing mode. The LDNS round robin attribute allows the 3-DNS Controller to return a list of available virtual servers, instead of a single virtual server. Certain browsers keep the answer returned by DNS servers. By enabling this attribute, the 3-DNS Controller returns a maximum of 16 virtual servers as the answer to a DNS resolution request. This provides browsers with alternate answers when a virtual server becomes unavailable.
The 3-DNS Controller offers three advanced features that you can configure to further control the distribution and flow of network traffic.
Topology-based access control limits users to a subset of available servers based on their proximity to the servers. You can use topology-based access control to force European clients to connect only to servers also in Europe, rather than connecting to servers in South America.
The 3-DNS Controller uses topology-based access control in conjunction with load balancing modes. For example, even though topology-based access control may force a European client to connect to a server in Europe, the 3-DNS Controller still uses the load balancing modes specified for the preferred, alternate, and fallback methods to choose the best European server that should receive the connection.
You can use the IP packet filtering feature to reject unwanted connection requests that may bog down your site and compromise performance. For example, if you detect an attack on your site, such as when your system is suddenly flooded with DNS requests from a single client, you can block that client's connection requests by defining an IP filter that rejects all packets containing that client's source IP address.
Note that the IP packet filtering supported on the 3-DNS Controller is based on BSD IP packet filtering. You can configure IP filters manually, but we recommend that you define IP filters in the Configuration utility, which greatly simplifies the process. To define a new IP filter in the Configuration utility, you specify one of three filter criteria:
Production rules are a policy-based management feature that you can use to dynamically change the load balancing configuration and the system settings based on specific triggers, such as the time of day, or the current network traffic flow. You can set up standard production rules using the Configuration utility, or you can define custom production rules using the production rules scripting language.
An important part of installing 3-DNS Controllers in your network is planning which servers should be master for a given DNS zone. When you initially set up a 3-DNS Controller in your network, you have two basic options for setting up DNS zone masters:
The 3-DNS Controller must always be the DNS master for your wide IP sub-domains, regardless of which server is the master DNS in your network. We strongly recommend that you set up the 3-DNS Controller to run as a master DNS that manages your domain.
One major benefit of setting up the 3-DNS Controller to be the master DNS for your domain is that you can easily manage DNS zone files using NameSurfer, a browser-based, third-party application included on the 3-DNS Controller. You can also easily transfer your existing zone files to the 3-DNS Controller after the initial installation.
When you define wide IPs in the Configuration utility, the NameSurfer application automatically makes the appropriate additions to the zone files, and broadcasts the new zone files to the other DNS servers in your network. If you configure wide IPs manually, however, you need to make the corresponding zone file changes manually.
If you use the advanced synchronization features of the 3-DNS Controller, we strongly recommend that you configure each 3-DNS Controller to run as a master DNS. This effectively creates a group of peer/master DNS servers. This type of configuration offers the following advantages:
Figure 2.5 shows an implementation where both 3-DNS Controllers in the network act as master DNS servers for the domain, domain.com.
After you initially install the 3-DNS Controller, you need to transfer existing BIND files, and then convert them to the NameSurfer format.
One option for converting your existing BIND files is to skip the NameSurfer configuration when you run the First-Time Boot utility. You transfer the zone files and named.conf file after the system has rebooted, and then run the config_namesurfer script that configures, converts, and starts the NameSurfer application. For more information, see Appendix C, BIND 8 Information .
The second option for importing your existing BIND files is to zone transfer from your current name server to NameSurfer. After configuring NameSurfer during the First-Time Boot utility and connecting to the Configuration utility, use the Copy from other name server option in the NameSurfer UI. For more information, refer to the NameSurfer documentation available from the splash screen in the Configuration utility.
At a minimum, all 3-DNS Controllers must be the DNS masters for the zones associated with wide IP definitions. When you set up a configuration where the 3-DNS Controllers are DNS masters for only those sub-domains, you need to make a few changes to the zone files on the master DNS for your domain after you configure the 3-DNS Controller.
Figure 2.6 shows an example where both 3-DNS Controllers are DNS masters for the wide IP sub-domains, and a generic name server in the Tokyo data center is the master DNS server for the domain, domain.com.
Note that you should still set NameSurfer to be the master during the First-Time Boot utility for initial installations, or during the NameSurfer configuration script for upgrade installations. Remember that NameSurfer is the master for the zone files on the 3-DNS Controller, but in this configuration the zone files contain only those records associated with wide IPs configured on the 3-DNS Controller. When you configure wide IPs in the Configuration utility, the NameSurfer application automatically updates the corresponding sub-domain zones and broadcasts them to the other DNS servers in the network. For configurations where synchronization is enabled, changes to any NameSurfer files are automatically updated to the other 3-DNS Controllers.