Installing the update

These installation instructions apply to all customers upgrading from previous versions of 3DNS software.

1. Connect to the F5 Networks FTP site at ftp.f5.com. Click here and follow the instructions for using the F5 Networks FTP site.



2. Verify the integrity of the file using the sum command:
   sum 3dns104kit.tar
   
   If the file is correct, the command displays the following checksum:
   11553 6720

3. Extract the 3dns104kit.tar file in the /var/tmp/ directory:
   cd /var/tmp
   tar xvf 3dns104kit.tar
   
   The following table lists the files that are extracted, and also includes the checksums that you can use to verify the files.
   
   

   File Name	Checksum	Description
   3.v1.0.4.tar.gz	46043 4733	3DNS tarball ( gzipped )
   3dnsbook.pdf	15669 1773	3DNS user manual
   backupfile.txt	33958 1	List of modified configuration files.

   
   

4. Backup the existing configuration files on the 3DNS System:
   cd /var/tmp
   /usr/contrib/bin/gtar -cvf 3dbackup.tar -T backupfile.txt
   
   
5. Stop all currently running 3DNS System processes:
   ndc stop
   kill `cat /var/run/big3d.pid`
   kill `cat /var/run/syslog.pid`
   ps -aux thttpd
   kill pid#
   
   
6. Extract the 3.v1.0.4.tar.gz file in the /var/tmp/ directory:
   cd /
   /usr/contrib/bin/gtar -zxvpUf /var/tmp/3.v1.0.4.tar.gz
   
   
7. Run 3dparse to update the /etc/wideip.conf file.
   3dparse
   
   
8. Restart the 3DNS System.
   sync
   reboot
   

Note: Once you install the 3DNS software, you need to install new versions of the big3d utility on all BIG/ip Controllers managed by the 3DNS System. For details, see The big3d utility.

Once you install the software update, refer to the Configuring and using the new software section below, which contains important information about enhancements and new configuration options.

---

What's new in this version

New features and enhancements

• New load balancing options
  The 3DNS System now supports three hierarchical load balancing methods. For each pool in a wideip statement, you can specify a preferred method, an alternate method, and a fallback method. If the load balancing mode specified for the preferred method fails, the 3DNS System uses the alternate method. If the load balancing mode specified for the alternate method fails, the 3DNS System uses the fallback method. If the fallback method fails, the 3DNS System returns the connection request to DNS. For details, see Additions to the wideip statement in the following section.
• New static load balancing mode: Topology
  The new Topology load balancing mode distributes connections based on the proximity of an LDNS to a particular data center. Proximity is determined by network IP addresses of the LDNS compared to that of the data centers, and not necessarily by geographical location. For details about working with the Topology load balancing mode, see Working with new topology features.
• Topology-based access control
  The 3DNS System can now control access to specific data centers, based on the IP address of the requesting LDNS. For details about implementing topology-based access control, see Working with new topology features.
• QOS load balancing mode can now use topology information
  The Quality of Service (QOS) load balancing mode can now incorporate topology data in the qos equation. For details, see Incorporating topology scores into the QOS load balancing mode.
• New versions of big3d
  The 3DNS System includes a new big3d utility for all BIG/ip Controller versions through BIG/ip Controller version 2.0.2, see 3DNS Web Administration tool.
• Enhancements to the 3DNS Web Administration tool
  The 3DNS Web Administration tool now includes an Administration area where users can change the 3DNS System configuration and control statistics collection. The original statistics screens also display new information in several areas. For details, see 3DNS Web Administration tool.
• 3DNS Maintenance menu changes
  The 3DNS Maintenance menu includes new commands. List and/or Print named database allows you to view and print specific 3DNS System statistics on the command line. BIG/ip and big3d versions displays the version numbers of BIG/ip Controllers and their corresponding big3d utilities. The Use Static wideip.conf command, the Use Dynamic wideip.conf command, and the 3DNS mode command are used for working with static and dynamic wideip.conf files (for details, see Working with static and dynamic wideip.conf files). Note that the Install and Start big3d menu command is updated and automatically copies the correct version of the big3d utility to each BIG/ip Controller. For details, see 3DNS Maintenance menu changes.
• iQuery enhancements
  The 3DNS System has three new iQuery options: the iQuery protocol is officially registered with the IANA for port 4353, and you can run iQuery on either that port or on the original port 245; 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; and you can now set iQuery to include translated IP addresses in iQuery packets (useful for configurations where iQuery communication between a BIG/ip Controller and a 3DNS System passes through a firewall). For details about these features, see Using new iQuery options.
• Improved path probing
  The 3DNS System now has advanced path probing schemes, which determine path attributes such as round trip time and packet completion rate. For details about path probing and the new discovery factory, see Path probing and the discovery factory. The 3DNS System also supports several new global variables associated with path probing and statistics collection. For details, see Additions to the globals statement.
• Storing dynamic and static copies of the wideip.conf file
  You can now store your original wideip.conf file separately from a wideip.conf file that stores current path and LDNS information. For details, see Working with static and dynamic wideip.conf files.
• Increasing storage space for zone files
  You now have the option of storing zone files in a /var/namedb directory, which offers substantially more storage space than the /etc/namedb directory. To maintain zone files in the /var/namedb directory, you first need to change a line in the /etc/named.conf file, move /etc/namedb to /var/namedb, and then restart the named process. For details, see Changes to the named.conf file.
• New First-Time Boot utility trigger
  In previous versions of the 3DNS System, the First-Time Boot utility ran at start up if the system did not detected the /etc/wideip.conf file. In the current version of the 3DNS System, however, the First-Time Boot utility is triggered only if the /etc/netstart file is not found. The /etc/wideip.conf file is no longer used to trigger or prevent the First-Time Boot utility from running at start up. Customers who are upgrading to 3DNS System 1.0.4 need to change the appropriate lines in the /etc/rc file to take advantage of this change.
• Comments now allowed in bigips.txt and 3dns.txt files
  You can now use shell style comments (also known as Perl style comments) in the bigips.txt and 3dns.txt files. Shell style comments start with the pound sign character (#), and are no longer than one line in length.
• Support for international 3DNS Systems
  3DNS System version 1.0.4 now supports versions for international distribution. Users who work with international versions should refer to the technical note Working with international 3DNS Systems.
  

Fixes

• Using BIG/ip Controllers to probe paths for hosts
  In previous versions of the 3DNS System, the wideip.conf file did not parse correctly if it included a host statement where the prober variable was set to the IP address of a BIG/ip Controller. This feature now works, and is actually required for those users who want to multiplex iQuery traffic on a single port on the 3DNS System. For details, see Using new iQuery options.
• Domain names are no longer case-sensitive
  The domain names that you define in wideip statements are no longer case-sensitive. In previous product versions, the 3DNS System did not match a requested domain name to the domain name defined in the wideip statement, unless the case was consistent between the two.
• Improved handling of connection limits defined by BIG/ip Controllers
  The 3DNS System now respects all connection limits associated with virtual servers managed by BIG/ip Controllers. The 3DNS System is aware of connection limits set for all components of a virtual server, including the connection limits set for the virtual server itself, the virtual addresses, and all nodes and node addresses that are members of the virtual server. The 3DNS System considers the virtual server to be down if any or all of the following conditions are met: the connection limit on the virtual sever is reached; the connection limit on the virtual address is reached; all connection limits set on nodes associated with the virtual server are reached; all connection limits set on node addresses associated with the virtual server are reached.
• Frequently refreshing statistics screens no longer causes memory problems
  For 3DNS Systems that also act as primary and secondary DNS servers, frequently refreshing statistics screens in the 3DNS Web Administration tool no longer causes memory problems. In previous versions of the 3DNS System, some customers experienced problems when a 3DNS System acting as a secondary DNS issued a request to copy zone information from a 3DNS System acting as a primary DNS, or when a 3DNS System acting as a primary DNS attempted to respond to such as request.
• Fix for CERT Advisory CA-98.13 - TCP/IP Denial of Service
  The 3DNS System is protected from the types of attacks described in CERT Advisory CA-98.13.

---

Configuring and using the new software

Required configuration changes

The following configuration changes are required. All other configuration changes in this release are optional. Note, however, that the globals and wideip statements have new as well as changed attributes, which accommodate new product features. Although the 3DNS System supports old attributes to allow for backward compatibility, we recommend that new installations are configured using the new syntax supported in this release.

First-Time Boot utility

To check to see if the First-Time Boot utility has run, the 3DNS System now looks for the /etc/netstart file rather than /bin/config. If the /etc/netstart file exists, the 3DNS System does not run the First-Time Boot utility at start up. If the 3DNS System does not find the /etc/netstart file, it runs the First-Time Boot utility at start up and saves the /etc/netstart file upon completion.

Datasize settings

The 3DNS System now automatically manages all datasize statements, including process data and stack sizes, based on the amount of memory installed. We recommend that users remove or comment out datasize statements from /etc/named.conf files because they are no longer necessary.

System control variables on BIG/ip Controllers

If you configure the 3DNS System to use the registered iQuery port 4353 for iQuery traffic, you must change the corresponding bigip.open_3dns_lockdown_ports sysctl variable on all BIG/ip Controllers running version 2.0 and earlier. The default setting for this variable is 0, but if iQuery traffic is set to run on port 4353, you need to change the variable setting to 1.

The big3d utility

All versions of the big3d utility must be updated on BIG/ip Controllers. The 3DNS System includes big3d utilities for BIG/ip Controller version 1.8.3, version 2.0, and version 2.0.1. You should use the Install and Start big3d command (on the 3DNS Maintenance menu) to automatically copy and install the appropriate version of the big3d utility to all BIG/ip Controllers in your environment.

Note: The big3d utility version 2.0.1 is compatible with BIG/ip Controller version 2.0.2.

Y2K compliance

To make the 3DNS System Y2K compliant, you may need to change the serial numbering scheme you apply to zone files. The 3DNS System manual previously recommended the YYYYMMDDHHMM serial number format. This serial number format can cause problems with year 2000 dates because the serial number generated may be larger than a 32-bit integer. To resolve this problem, you should use the YYYYMMDDXX serial number format where the XX portion of the number reflects a series number that is attached to the date. This serial number format accommodates zone file transfers that occur more than once in a 24 hour period, but does not create serial numbers that exceed a 32-bit integer. For more information on zone file serial numbers, see page 136 in the O'Reilly book DNS and BIND, 3rd edition (covers BIND 8).

New configuration options

New load balancing modes and options

3DNS System 1.0.4 supports new load balancing modes, and also enhances the Quality of Service load balancing mode.

Load Balancing Mode	Description	Related Feature(s)
topology	Provides dynamic load balancing based on the proximity of an LDNS IP address to the virtual server IP addresses.	New load balancing modes. For detailed information about topology features, see Working with new topology features.
null	Bypasses the current load balancing method, and forces the 3DNS System to use next load balancing method, or to use the next available pool.	New load balancing modes. For details, see Working with multiple pools in a wide IP.
return_to_dns	Returns the resolution request to DNS, preventing the 3DNS System from using the next load balancing method, or using the next available pool.	New load balancing modes
qos	The Quality of Service (QOS) load balancing mode now accepts a topology coefficient in the QOS equation. The new coefficient allows a QOS equation to incorporate a topology score into the QOS path score (see Additions to the wideip statement).	Topology-based load balancing. For detailed information about topology features, see Working with new topology features.

Additions to the globals statement

There are a series of new variables added to the globals statement.

Parameter	Description	Related Feature(s)
default_alternate	Defines the default load balancing mode used for the alternate method (formerly default_static). The default setting is rr. Users can override the setting in the wideip statement (see Additions to the wideip statement below).	New load balancing methods
default_fallback	Defines the default load balancing mode used for the fallback method. The default setting is return_to_dns. Users can override the setting in the wideip statement (see Additions to the wideip statement below).	New load balancing methods
fb_respect_depends	Determines whether the 3DNS System respects virtual server status when load balancing switches to the specified fallback mode. The default setting is no.	Topology load balancing mode. For detailed information about topology features, see Working with new topology features.
fb_respect_acl	Determines whether the 3DNS System imposes access control when load balancing switches to the specified fallback mode. The default setting is no.	Topology-based access control. For detailed information about topology features, see Working with new topology features.
use_alternate_iq_port	Determines whether the 3DNS System runs iQuery traffic on port 245 (the port used in older configurations), or on the new registered iQuery port, 4353. The default setting is no, which uses port 245. To use port 4353, change the setting to yes.	iQuery port options. For detailed information on this enhancement, see Using new iQuery options.
multiplex_iq	Determines whether the 3DNS System uses the ephemeral ports for iQuery traffic returned from the big3d utility. The default is set to no. To force iQuery traffic to use port 4353 for all incoming iQuery traffic, change the setting to yes.	iQuery port options. For detailed information on this enhancement, see Using new iQuery options.
rtt_probe_dynamic	Determines whether the 3DNS System attempts a second probe using the alternate probe protocol if the probe protocol specified by rtt_probe_protocol fails during the first probe. The default setting is no.	Enhanced path probing. For detailed information on this enhancement, see Path probing and the discovery factory.
rtt_port_discovery	Determines whether the 3DNS System uses the discovery factory to find an alternate port to be used by the probing factory, if probing on port 53 fails. The default setting is no, which does not make use of the discovery factory.	Enhanced path probing. For detailed information on this enhancement, see Path probing and the discovery factory.
rtt_discovery_method	Determines which ports to scan. The default setting is short, which scans a minimal list. You can also use wks or full, or all.	Enhanced path probing. For detailed information on this enhancement, see Path probing and the discovery factory.
path_max_refreshes	Determines the maximum number of times the 3DNS System requests new data for the path. The default setting is 0, which does not apply a probe limit. You can apply a probe limit by changing the value to the total number of times you want the 3DNS System to probe a path since you last started the named process.	Enhanced control of path probing. For detailed information on this enhancement, see Path probing and the discovery factory.
paths_never_die	Specifies that dynamic load balancing modes can use path data even after the ttl for the path data has expired. The default setting is no to support the original system behavior. However, we strongly recommend that you change it to yes which requires that the 3DNS System always use path data even if the ttl for the path has expired.	Enhanced dynamic load balancing. For detailed information on this enhancement, see Path probing and the discovery factory.
paths_noclobber	Specifies whether the 3DNS System overwrites existing path data with blank data when a path probe fails. The default is set to no, to support the original system behavior. However, we strongly recommend that you change it to yes, which requires that the 3DNS System does not overwrite existing path data with blank data when a path probe fails.	Enhanced dynamic load balancing. For detailed information on this enhancement, see Path probing and the discovery factory.
check_dynamic_depends	Specifies that the 3DNS System checks the availability of a path before it uses the path for load balancing. The default is set to yes.	Enhanced dynamic load balancing. For detailed information on this enhancement, see Path probing and the discovery factory.

Changes to the wideip.conf file

The wideip.conf file now has only three minimum requirements: it must contain a globals statement; it must contain at least one virtual server, which can be defined in either a bigip or in a host statement; and it must contain a wideip statement.

The wideip.conf file also supports a new topology statement. The information you define in the topology statement allows you to use three new 3DNS System features: the new Topology load balancing mode, topology-based access control, and a new topology factor that you can incorporate in QOS load balancing equations. For details about the syntax and function of topology statements, see Working with new topology features below.

Additions to the wideip statement

The wideip statement now supports syntax for three new features:

• Three methods of load balancing per pool
  You can set a preferred load balancing mode, an alternate load balancing mode, and a fallback load balancing mode for each virtual server pool. If the preferred load balancing mode fails for a given pool, the 3DNS System uses the alternate load balancing mode. If the alternate load balancing mode fails, the 3DNS System uses the fallback load balancing mode. If the fallback load balancing mode fails, the 3DNS System returns the connection request to DNS. You can prevent the 3DNS System from using alternate or fallback load balancing methods by setting the load balancing mode for a given method to null. The null load balancing setting is most useful when you have multiple resource pools (see see Using multiple resource pools).
• Topology information in a QOS equation
  You can include a new topology coefficient in a QOS load balancing equation. For details about all topology-based features, see Working with new topology features.
• Multiple pools
  You can define multiple pools; you are no longer limited to a single vsb pool or a single vsh pool. Note that when you use multiple pool statements, the 3DNS System automatically coverts your existing vsb and vsh pools to the new format, naming them Vsb, and Vsh respectively (see the new name keyword in the pool sub-statement). For detailed information, see Using multiple resource pools.

The following sample wideip statement highlights the syntax associated with all new and enhanced features:

wideip {
   address 192.168.70.12
   port 80
   name "www.domain.com"
   alias "support.domain.com"
   ttl 120
   qos_coeff {
      rtt 20
      completion_rate 5
      packet_rate 3
      topology 1
   }
   pool_lbmode ratio
   pool {
      name "Seattle"
      type vsb
      ratio 2
      preferred qos
      alternate ratio
      fallback return_to_dns
      address 192.168.70.12 ratio 2
      address 192.168.70.13 ratio 1
      address 192.168.70.14 ratio 1
   }
   pool {
      name "Dallas"
      type vsh
      ratio 1
      preferred ratio
      alternate rr
      fallback return_to_dns
      address 192.168.100.50 ratio 3
      address 192.168.100.51 ratio 2
      address 192.168.100.52 ratio 1
   }
   pool {
      name "Herndon"
      type vsb
      ratio 1
      preferred ratio
      alternate rr
      fallback return_to_dns
      address 192.168.201.0 ratio 3
      address 192.168.201.1 ratio 2
      address 192.168.201.2 ratio 1
   }
}

Additions to the bigip statement

The bigip statement now supports the translate keyword. The translate keyword specifies that iQuery packets sent to the BIG/ip Controller include translated IP addresses (required if the packets must pass through a firewall). For detailed information about iQuery enhancements, see Using new iQuery options.

The following sample bigip statement highlights the syntax associated with this new feature:

bigip {
    address 192.168.101.40
    vs {
        address 192.168.101.41
        port 80
        translate {
            address 10.0.0.1
            port 80
        }
    }
}

Changes to /etc/named.conf

If you want to store zone files in a /var/namedb directory, you need to change the directory /etc/namedb line in the /etc/named.conf file to point to the /var/namedb directory instead:

directory /var/namedb

---

Working with new topology features

Incorporating topology data into the 3DNS System provides two major new features: topology-based access control, and topology-based load balancing. The data is specified through the new topology statement, which you can add to the end of the wideip.conf configuration file.

• Topology-based access control
  You can use topology-based access control to implement a form of wide-area IP filtering. Topology-based access control allows you to specify which data centers are acceptable for a given resolution request, based on the proximity of the data center's IP address to the requesting LDNS server's IP address. For example, you can specify that requesting LDNS clients in North America are allowed access to data centers in North America, but not allowed access to data centers in South America.
• Topology-based load balancing
  Topology-based load balancing attempts to load balance resolution requests based on the proximity of the requesting LDNS to the closest data center. Proximity is determined by comparing the requesting LDNS IP address to the IP addresses of the data centers defined in the topology statement. Two load balancing modes make use of this topology data: the new Topology load balancing mode, and the Quality of Service (QOS) load balancing mode.

Defining the topology statement

You insert the new topology statement at the end of the wideip.conf file. The topology statement basically consists of 3 parameters, acl_threshold, limit_probes, and longest_match, followed by a list of records defining a network.

topology {
    acl_threshold   <1 | 0>
    limit_probes    <yes |no>
    longest_match   <yes | no>

    <mask virtual server> <mask LDNS> <mask score>

}

The following is an example of a simple topology statement, which specifies that North American clients are load balanced only to data centers in North America, and that South American clients are load balanced only to data centers in South America.

topology {
    acl_threshold   1
    limit_probes yes
    longest_match   yes

    // Server/Mask      LDNS/Mask       Score

    // North America doesn't go to the South America data center
    200.107.34.0/24     198.0.0.0/8     0
    200.107.34.0/24     199.0.0.0/8     0

    // South America doesn't go to the North America data center
    199.5.23.0/24       200.0.0.0/8     0
    199.5.23.0/24       201.0.0.0/8     0
}

Understanding the list records

The record list records in the topology statement define a score for pairs of known LDNS servers and data centers. Essentially, each record defines 2 network endpoints in CIDR (Classless Interdomain Routing) format, and a score. The CIDR format consists of an IP address and a number n designating a subnet bitmask. The bitmask is made up of n ones followed by 32 - n zeros. For example, for n = 8, the bitmask is:

11111111000000000000000000000000
\______/\______________________/
 8 ones          24 zeros

The first endpoint, A, corresponds to the virtual server (managed either by a BIG/ip Controller or by another host system). The second endpoint, B, corresponds to the LDNS. Suppose a local DNS, L, requests a name resolution from the 3DNS System, and the virtual server being considered as an answer is managed by a BIG/ip Controller, S. The list record that matches is the one where the equation ((S & A-mask == A & A-mask) && (L & B-mask == B & B-mask)) is TRUE.

Referring to the example topology statement above, say that the LDNS 200.5.6.7 requested name resolution for www.domain.com, and a virtual server in the vsb pool belonged to the BIG/ip Controller 199.5.23.17. In this scenario, the 3DNS System would consider the third list record to be a match.

Understanding the topology score

Each list record includes a score, which is used both in topology-based load balancing, and in topology-based access control. If multiple list records in a topology statement have the exact same server IP/mask and LDNS IP/mask, but have different scores, only the last record declared will be valid. For example, the following:

9.8.7.0/24     10.20.30.0/24     6
9.8.7.0/8      10.20.30.0/16     1
9.8.7.0/24     10.20.30.0/24     89 <-- replaces 1st record
9.8.7.0/24     10.20.30.0/24     0  <-- replaces previous record
9.8.7.0/24     10.20.30.0/24     3  <-- replaces previous record

Is equivalent to:

9.8.7.0/8      10.20.30.0/16     1
9.8.7.0/24     10.20.30.0/24     3

Note:  The term list-record (LDNS,VS) refers to the longest matching record for the LDNS ip address and the parent Server of the VS ip address.

Using the longest match rule

The 3DNS System uses the same type of longest match rule that is commonly used by routers. If there are several IP/mask items that match a particular IP address, the 3DNS System selects the record that is most specific, and thus has the longest mask (n is the largest). For example, 1.2.3.4 matches 1.2.3.4/0, 1.2.3.4/8, 1.2.3.4/13, 1.2.3.4/24, and 1.2.3.4/32, but the longest matching IP/mask is 1.2.3.4/32. When the longest_match parameter is set to yes, the longest match rule is obeyed for LDNS IP addresses, and also for Server IP addresses, when there are multiple matches for a LDNS/VS combination. This means that for LDNS 10.20.30.40 and VS 9.8.7.6 owned by BIG/ip 9.8.7.2, or simply list-record (10.20.30.40, 9.8.7.6), the third list record is the longest match:

9.8.7.0/24     10.20.30.0/24     2
9.8.7.0/8      10.20.30.0/16     0
9.8.7.2/8      10.20.30.40/27    6 <-- Longest Match
9.8.7.0/16     10.20.30.0/24     7
9.8.7.2/32     10.20.30.0/24     3 <-- Second Longest Match

Though this is not how the search is implemented, consider that all the records matching the Server and LDNS ip address are gathered into a set. The records in this set are sorted in descending order by LDNS mask, then Server mask. The highest record in the sorted set wins. For example, if the third list record in the above example were removed, then the first and fifth records would tie for longest match on LDNS, but the fifth would win because it has the more specific Server mask.

Implementing topology-based access control

The acl_threshold default is set to 0. Any LDNS/VS matching a list record with a score below this threshold is interpreted as if the virtual server were unavailable. For example, if an LDNS 198.1.2.3 requests a name resolution, any virtual server owned by BIG/ip Controller 200.107.34.99 would be considered down for load balancing purposes due to the first list entry. This provides a hook for an administrator to set up access control to data centers based on LDNS IP address.

Using wildcard list records to explicitly allow or deny access to LDNS servers that do not match a specific list record

You may want to define a wildcard list record that you can use to prevent users from being locked out when access control is turned on. If the 3DNS System compares the LDNS server's IP address to the specific list records but does not find a match, it can use a wildcard list record to determine how to handle the resolution request.

A wildcard list record uses the following syntax:

0.0.0.0/0     0.0.0.0/0 <score>

The <score> parameter setting either allows or denies access, depending on whether its value is set greater than or less than the acl_threshold setting. A <score> value that is greater than or equal to the acl_threshold setting allows access. A <score> value that is less than the acl_threshold setting denies access.

Using access control to limit path probing

The limit_probes parameter specifies whether to apply access control to the probing of paths. If this parameter is set to yes, the 3DNS System requests a given BIG/ip Controller to probe only those LDNS servers that can connect to it according to the acl_threshold value and the topology map scores. In the example topology statement above, the 3DNS System would not send an LDNS 199.234.37.81 connection to the BIG/ip Controller 200.107.34.15 for probing, but would send it to the BIG/ip Controller 199.5.23.6.

Using the Topology load balancing mode

The new static load balancing method, lbmode topology, simply picks virtual servers based on topology scores defined in each list record in the topology statement. A given connection is load balanced to the virtual server that has the highest topology score. If there is no matching list record, then the score for that LDNS/VS is assumed to be zero.

Incorporating topology scores into the QOS load balancing mode

The topology score has also been integrated into QOS. It is controlled by the globals qos_coeff_topology (default 0) and qos_factor_topology (default 1), an by the optional qos_coeff sub-statement parameter topology defined in the wideip statement. It is incorporated into the QOS score for a path by:

1. Finding the score of list-record (LDNS, VS), and naming the value score_topology.
2. Computing X = qos_coeff_topology * (score_topology / qos_factor_topology)
3. Determining that score_qos = score_qos + X

Thus, by default, score_topology makes no contribution to QOS. It must be enabled by defining a non-zero qos_coeff_topology either in the global statement, or in the wideip statement.

---

3DNS Web Administration tool

The new Administration area

The 3DNS Web Administration tool is now divided into two areas:

• Administration area
  The Administration area is new to the 3DNS Web Administration tool. From the Administration area, users can view and edit the wideip.conf file, change global variable settings, update the current statistics and configuration settings in the wideip.conf file, start and stop metrics collection on paths, and reset all statistics.
• Statistics area
  The Statistics area is essentially the original set of screens, such as the BIG/ip Controllers and the Wide IPs screens, included in the 3DNS Web Administration tool. From the Statistics area, users can only view statistical data; they cannot change the system configuration, nor can they control metrics collection or reset statistics.

Setting user access privileges for administration and statistics

You can control user access to the statistics and administration areas using the Change/Add Users for 3DNS Web Administration command on the 3DNS Maintenance menu. This script prompts you to define a user name and password, and also prompts to chose which area(s) the user can access. You can specify that the user has access only to the statistics area, or you can specify the user has access to both the statistics and the administration areas.

Working in the Administration area

The Administration area allows you to perform the following simple tasks using the buttons in the left frame.

Task	Description
Reset Statistics	Sets all statistics values to zero and begins collecting new statistical data.
Start Metrics Collection	Activates the process of collecting statistical data.
Stop Metrics Collection	Interrupts the process of collecting statistical data.
View wideip.conf	Displays the currently saved wideip.conf file.
Edit wideip.conf	Opens the current wideip.conf file in an edit window. Once you edit the file, click Update to save your changes. Note that you cannot edit wideip.conf files that are greater than 64 Kb in the edit window; you need to edit large wideip.conf files directly in a text editor such as vi or pico.
Edit Globals	Allows you to view and edit individual global variables without loading the wideip.conf file. To edit a global variable, click on the variable name.
Update Database	The Update Database command creates two files: /var/3dns/etc/wideip.conf.dynamic and /var/3dns/etc/wideip.conf.static. The /var/3dns/etc/wideip.conf.dynamic file stores the wide IP definitions, path data, and LDNS data. The /var/3dns/etc/wideip.conf.static contains only the globals, bigip statements, hosts statements, and wideip statements.
Restart	Restarts the named process.

Warning:   The Edit wideip.conf feature has some limitations:

• You cannot edit a wideip.conf file larger than 64 Kb.
• You can only change or add items in a wideip.conf file; you cannot remove items from the file.
• If you use incorrect syntax in the wideip.conf file, the file fails once you click Update and named is restarted.

New states for servers

Servers now have four states as shown in the table below. These states are displayed in the Virtual Servers, and in the BIG/ip Controllers, and Hosts screens.

State	Indicator	Description
Unknown		The server is new to the 3DNS System, and the 3DNS System has not yet collected metrics for the server.
Up		The server is available to accept new connections.
Unavailable		The server either has old metrics data which needs to be refreshed, or the server is temporarily unavailable. A server can be temporarily unavailable for a variety of reasons, such as when its connection limit is reached, or when nodes associated with the virtual server are down. Note: This state applies only to virtual servers; it does not apply to BIG/ip Controllers, nor to hosts.
Down		The server is unresponsive.

The BIG/ip Controllers screen

The BIG/ip Controllers screen includes the following changes

• Each BIG/ip Controller IP address now links to a page that displays the bigip statement associated with the selected BIG/ip Controller.
• A TTL column displays the remaining time to live (ttl) before the BIG/ip Controller's metrics data needs to be refreshed.
• A VS Picks column displays the number of times a virtual server managed by the BIG/ip Controller received a resolution request from the 3DNS System.

The Hosts screen

The Hosts screen includes the following changes:

• Each host IP address now links to a page that displays the host statement associated with the selected host.
• A TTL column displays the remaining time to live (ttl) before a host's metrics data needs to be refreshed.
• The Virtual Address column is now named Interface Address. The column displays the IP address associated with the interface that accepts incoming connections for the host.
• The Virtual Port column is now named Probe Port. The column displays the port that the 3DNS System uses to verify whether the virtual server is available.

The Virtual Servers screen

The Virtual Servers screen includes the following changes:

• A TTL column displays the remaining time to live (ttl) before a virtual server's metrics data needs to be refreshed.
• The values displayed in the Enabled column are now Yes or No, rather than 1 or 0.
• The values displayed in the Conn Limit column are now Open or Full, rather than 1 or 0.

The Paths screen

The Paths screen includes the following changes:

• A TTL column displays the remaining time to live (ttl) before a path's metrics data needs to be refreshed.
• A Delta RTT column displays the difference (in microseconds) between the current known round trip time, and the average round trip time.
• The Last Refresh column is replaced with a column named Refreshes, which displays the number of data refreshes for each path.

The Local DNS screen

The Probe State column is now named State, because it displays both path probing and path discovery state information. The column displays the following values:

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 Wide IPs screen

The Wide IPs screen includes the following changes:

• Each domain name now links to a page that displays the wideip statement associated with the selected domain.
• The 3DNS Resolved column is now named Preferred. It displays the number of times a resolution request was resolved using the preferred load balancing method specified in the wideip statement.
• The Fallbacks column is now named Alternate. It displays the number of times a resolution request was resolved using the alternate load balancing method specified in the wideip statement.
• A Fallback column displays the number of times a resolution request was resolved using the fallback load balancing method specified in the wideip statement.
• The Return to DNS column remains the same. Note that this displays the number of times resolution requests were not handled by the 3DNS System, and returned to DNS for resolution. This count includes all returned requests, not just those that may be returned when the new return_to_dns load balancing mode is in use.
• The Fallback Address column is now named DNS Address.

The Summary screen

The Summary screen includes the changes outlined below.

Virtual Servers table

• The table now displays the total number of BIG/ip virtual servers that are up, and the total number that are down.
• The table now displays the total number Host virtual server that are up, and the total number that are down.

Wide IP table

Under Total Resolved, the table displays a breakdown of the percentage of the resolutions made using the three new load balancing settings (Preferred, Alternate, and Fallback).

The Globals screen

The Globals screen now includes a Default column and a Change Requires Restart column. The Default column displays the default value for the variable if the current variable setting is different from the default setting. If user never changes the variable setting and it is still set to the default, the Default column displays (same). The Change Requires Restart column simply displays whether the user must restart named if the user changes the variable setting.

The Globals screen displays values for the new global variables:

default_alternate
default_fallback
fb_respect_depends
fb_respect_acl
use_alternate_iq_port
multiplex_iq
rtt_probe_dynamic
rtt_port_discovery
rtt_port_discovery_method
path_max_refreshes
paths_never_die
paths_noclobber
check_dynamic_depends

---

3DNS Maintenance menu changes

Installing the big3d utility

The Install and Start big3d command now automatically installs and starts the appropriate version of the big3d utility on each BIG/ip Controller. You no longer have to manually copy the big3d utility to each BIG/ip Controller before you run the Install and Start big3d command.

Viewing and printing 3DNS System statistics on the command line

The List named database command allows you to view seven different statistics screens on the command line. You can choose from the following types of statistics:

• sum
  Displays summary statistics, such as the 3DNS System version, the total number of resolved requests, and the load balancing methods used to resolve requests.
• paths
  Displays path statistics, such as round trip time and packet completion rate.
• ldns
  Displays statistics collected for LDNS servers, including the number of resolution requests received from a given server, and the current protocol used to probe the server.
• vs
  Displays statistics about BIG/ip and host virtual servers, such as the server state, and the number of times it has received resolution requests.
• bigips
  Displays statistics about all BIG/ip Controllers known to the 3DNS System, including the number of virtual servers each BIG/ip Controller manages, and the number of times that the 3DNS System resolves requests to those virtual servers.
• hosts
  Displays statistics about all hosts known to the 3DNS System, including the number of times that the 3DNS System resolves requests to the host.
• wips
  Displays statistics about each wide IP defined on the 3DNS System, including load balancing information and the remaining time to live before the wide IP's metrics data needs to be refreshed.

Displaying BIG/ip Controller and big3d version numbers

The BIG/ip and big3d versions command displays version numbers for all BIG/ip Controllers and their corresponding big3d utilities known to the 3DNS System.

Using wideip.conf modes

There are three new 3DNS Maintenance menu commands that affect wideip.conf modes:

• Display mode of wideip.conf
  Displays the current wideip.conf mode: Initial, Static, or Dynamic.
• Use Dynamic wideip.conf
  Creates a static copy of the original wideip.conf file, and also creates a dynamic copy of the wideip.conf file that includes the path and LDNS data, as well as changes you make using the Edit wideip.conf feature in the 3DNS Web Administration tool.
• Use Static wideip.conf
  Returns to a single wideip.conf file, using the wideip.conf.static version created when you originally switched the mode to Dynamic.
• Edit 3DNS Configuration
  In Initial mode, this command edits the original wideip.conf file, but in Static or Dynamic mode, this command edits the wideip.conf.static file. Note that the command opens the file in pico for editing.

For more details about working with these commands and with wideip.conf modes, see Working with static and dynamic wideip.conf files.

Install and start named

Note that this command is removed from the 3DNS System. Each new 3DNS System product release includes the appropriate version of named, which is not necessarily compatible with older versions of the 3DNS System. You should not copy a named from one 3DNS System to other 3DNS Systems unless the other systems are running the same version of the software.

---

Using new iQuery options

Choosing ports for iQuery traffic

Port 4353 is now registered with the IANA as the standard port for the iQuery protocol. The 3DNS System has a new globals variable, use_alternate_iq_port, which allows you to specify whether you want outbound iQuery traffic to run on port 4353, or run iQuery on port 245, as it is run in older configurations. To support backward compatibility for older 3DNS Systems, the default setting for the use_alternate_iq_port variable is no, which specifies that the 3DNS System should run outbound iQuery traffic on port 245. However, we recommend that you set this variable to yes in new 3DNS System configurations, specifying that the configuration uses the new standard iQuery port.

Note:     If you use port 4353 for iQuery traffic, you must set the corresponding bigip.open_3dns_lockdown_ports sysctl variable to 1 (the default setting is 0) on all BIG/ip Controllers running version 2.0 and earlier.

The 3DNS System supports another new global variable associated with iQuery traffic. The multiplex_iq variable determines whether the 3DNS System allows all returning iQuery traffic to run only on port 4353 or port 253 (depending on the use_alternate_iq_port setting), or allows returning iQuery traffic to run on individual ephemeral ports. The default setting for this variable is no, which specifies that returning iQuery traffic runs on individual ephemeral ports.

Note: You cannot run the big3d utility on the 3DNS System to manage path probing on behalf of hosts if you also want returning iQuery traffic to use a single port. The returning iQuery traffic and the big3d utility create a conflict because they both need to use the same port. To resolve this problem, you should set each host to use a prober than runs on a BIG/ip Controller, rather than on the 3DNS System.

Setting up iQuery communications to allow passing through firewalls

The iQuery utility collects configuration and metric information from BIG/ip Controllers on behalf of the 3DNS System. The payload information of an iQuery packet contains information that potentially requires translation when there is an intermediate system in the path between a BIG/ip Controller and the 3DNS System. In previous versions of the 3DNS System, iQuery messages included only the configured virtual server address, which was not appropriate where iQuery packets traveled through a firewall and required both the configured address and the translated address. The 3DNS System now allows iQuery packets to contain both addresses.

In the example configuration shown below, a firewall separates the path between the BIG/ip Controller and the 3DNS System. The packet addresses are translated at the firewall. Addresses within the iQuery payload, however, are not translated and they arrive at the BIG/ip Controller in their original state.

To accommodate such a configuration, the 1.0.4 version of the 3DNS System supports a new keyword in the bigip statement: translate. When you include the translate keyword in the bigip statement, the iQuery utility includes translated IP addresses in the packets sent to the specific BIG/ip Controller.

The new syntax for the bigip statement is highlighted below:

bigip {
    address 192.168.101.40
    vs {
        address 192.168.101.41
        port 80
        translate
        {
            address 10.0.0.1
            port 80
        }
    }
}

---

Path probing and the discovery factory

The 3DNS System collects a list of the local DNS servers that request name resolutions from the 3DNS System.  For the purpose of load balancing future connection requests, the 3DNS System collects statistics about the paths, such as round trip time and packet completion rate, between each LDNS and each BIG/ip Controller that the 3DNS System manages. 3DNS System version 1.0.4 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 that it could in previous versions.
• Dynamic probe protocol switching
  The big3d utility dynamically switches to the alternate probe protocol (specified by rtt_probe_protocol) in an effort to generate a successful response if the initial probe on an LDNS 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 LDNS using either probe protocol, the 3DNS System sends the target LDNS to the discovery factory. The discovery factory scans the target, looking for an open port on which it can receive and respond to a ping. If the discovery factory finds an open port, the 3DNS System uses that port for future probes. If it cannot find an open port, the target is no longer probed.

For each requesting LDNS, 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.

Global variables that affect probing and discovery

The following global variables allow you to control the behavior of the probing and discovery mechanisms, and the way in which the 3DNS System uses path data to make load balancing decisions.

Variable	Default Setting	Description
rtt_probe_dynamic	no	Determines whether the 3DNS System attempts a second probe using the alternate probe protocol if the probe protocol specified by rtt_probe_protocol fails during the first probe. The default behavior is for the 3DNS System to bypass a second probe altogether if the first probe fails. We recommend that you change this setting to yes in an attempt to consistently maintain path data.
rtt_port_discovery	no	Determines whether the 3DNS System uses the discovery factory to find an alternate port to be used by the probing factory, if probing on port 53 fails. The default behavior does not make use of the discovery factory.
rtt_discovery_method	short	Determines which ports to scan. The default setting scans a minimal list. You can also use wks, full, or all.
rtt_sample_count	3	Determines the number of packets sent by the probing factory.
rtt_packet_length	64	Determines the length of probe packets.
rtt_probe_protocol	icmp	Specifies the protocol (ICMP or TCP) used to perform the probe.
timer_get_path_data	120	Sets the frequency at which path probing is performed.
path_max_refreshes	0	Determines the maximum number of times the 3DNS System can request new data for a given path. The default setting allows for an unlimited number of probes.
path_ttl	600	Sets the length of time for which path information is considered valid.
paths_never_die	no	Specifies whether the 3DNS System can use expired path data for load balancing. The default behavior allows path data to expire according to the ttl setting. We recommend that you change this setting to yes; however, you should take into consideration that the 3DNS System may use invalid path data.
paths_noclobber	no	Specifies whether the 3DNS System overwrites existing path data with blank data when a path probe fails. The default behavior requires that the 3DNS System overwrite existing path data with blank data when a path probe fails. We strongly recommend that you change the setting to yes, in an attempt to consistently maintain path data. Note that when the check_dynamic_depends global variable is set to yes (see below), the 3DNS System does not use invalid path data for load balancing.
check_dynamic_depends	yes	Specifies that the 3DNS System checks the availability of a path before it uses the path for load balancing. If the last path probe retrieved valid data, the 3DNS System considers the path to be available. If the last path probe retrieved zero data, the 3DNS System considers the path unavailable and does not use the path in load balancing. The default is set to yes. However, before you change this setting, you should take into consideration that the 3DNS System may use invalid path data.

A detailed look at the probing and discovery process

The following steps outline the typical sequence of events for probing and discovery of an LDNS server.

1. The 3DNS System sends a new set of target LDNS servers to the big3d utility for probing. The more often a target LDNS requests name resolutions from the 3DNS System, the more frequently the 3DNS System probes the target and refreshes the target's path metrics.
2. The big3d utility begins running the target LDNS servers through its probing factories.
3. For each target LDNS server, the target is first probed using the rtt_probe_protocol set by the 3DNS administrator.
   
4. 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.
5. After the big3d utility runs all target LDNS servers through the probing factory, the big3d utility returns the probe results to the 3DNS System.  The returned metrics include the round trip time, the number of successful replies, and the successful probe protocol.
6. The 3DNS System periodically scans the cache for targets that do not have metrics returned from a big3d utility.  The 3DNS System determines that for each of these targets, probing failed on port 53. The 3DNS System then 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.
7. For each target LDNS, the big3d discovery factory scans a short list of alternate ports, looking for a ping 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 ping response.
8. If the discovery factory fails to get a ping 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 BIG/ip Controller where the big3d utility runs). You can edit the /etc/services file to control which ports are scanned when the discovery factory makes a second pass.  Again, note that the port list is shuffled before each scan.
9. After all target LDNS servers have been run through the discovery factory, the big3d utility returns the results back to the 3DNS System.
10. If the 3DNS System receives a failed target back from the discovery factory, it switches the target LDNS system to the Suspended state. The 3DNS System no longer attempts to probe or scan the target, nor does it use dynamic load balancing modes to resolve requests issued by the LDNS system. If the preferred load balancing method were set to a dynamic mode, the 3DNS System would use a load balancing mode specified by either the alternate or the fallback load balancing method in the wideip statement instead.

---

Working with multiple pools in a wide IP

The 3DNS System now allows you to define multiple server pools in a wideip statement. Using multiple server pools allows you more control and flexibility for distributing resolution requests among virtual servers, regardless of their type. This new feature relies on new syntax in the pool sub-statement, and also introduces a new load balancing mode named null.

New pool syntax

To accommodate multiple pools, the pool sub-statement syntax now includes a pool name and a pool type. It also incorporate a new feature which allows three methods of load balancing. The sample below highlights the new syntax options:

pool {
      name "<pool name>"
      type <vsb | vsh>
      ratio 1
      preferred <rr | ratio | ga | topology | random | leastconn | packet_rate | completion_rate | rtt | qos>
      alternate <rr | ratio | ga | topology | random | return_to_dns | null>
      fallback <rr | ratio | ga | topology | random | return_to_dns | null>
      address <vs addr> ratio <weight>
      address <vs addr> ratio <weight>
   }

Using resource pools effectively

The following example uses multiple resource pools to determine how to distribute connections among three data centers: Seattle, Dallas, and Herndon. The administrator wants resolution requests made to the 3DNS System in Seattle, to be resolved to virtual servers in the data center in Seattle. If the data center in Seattle fills up and becomes unavailable, the administrator wants to send those resolution requests to virtual servers in the data center in Dallas. If both the Seattle and Dallas data centers are full, the administrator wants to send resolution requests to virtual servers in the data center in Herndon.

To achieve this, the administrator sets up the following wideip statement, which includes one resource pool for each data center:

wideip {
   address 192.168.70.12
   port 80
   name "www.domain.com"
   alias "home.domain.com"
   ttl 120
   pool_lbmode ga
   pool {
      name "Seattle"
      type vsb
      ratio 2
      preferred leastconn
      alternate null
      fallback null
      address 192.168.70.12 ratio 2
      address 192.168.70.13 ratio 1
      address 192.168.70.14 ratio 1
   }
   pool {
      name "Dallas"
      type vsh
      ratio 1
      preferred leastconn
      alternate null
      fallback null
      address 192.168.100.50 ratio 3
      address 192.168.100.51 ratio 2
      address 192.168.100.52 ratio 1
   }
   pool {
      name "Herndon"
      type vsb
      ratio 1
      preferred leastconn
      alternate null
      fallback return_to_dns
      address 192.168.201.0 ratio 3
      address 192.168.201.1 ratio 2
      address 192.168.201.2 ratio 1
   }
}

The pool_lbmode set at the top of the wideip statement determines how the connection requests are balanced among the three resource pools, Seattle, Dallas, and Herndon. The load balancing methods set within each pool determine how connection requests are load balanced among the virtual servers in the pool. For this wide IP, the pool load balancing method is set to Global Availability mode (ga). Global Availability mode uses the pools in the order in which they are defined in the wideip statement. Because the administrator wants resolution requests to go first to Seattle, then to Dallas as a second choice, and to Herndon as a third choice, the resource pools are listed in that order.

Note that in the resource pools above, the alternate and fallback load balancing methods are set to null. This new load balancing mode prevents the 3DNS System from attempting to do load balancing for the given method. Instead, the 3DNS System either goes to the next load balancing method, or if it has gone through all three load balancing methods for the pool, it then goes to the next resource pool. In this case, because the preferred load balancing method leastconn depends on the same metrics data as any static method for vsb virtual servers, it is more efficient to perform one load balancing attempt per pool, rather than trying three load balancing attempts before moving to the next available pool.

Also note that the fallback load balancing method in the Herndon pool is set to return_to_dns, instead of being set to null. Because the wideip statement is set to use Global Availability for load balancing the pools, the 3DNS System always utilizes the Herndon pool last, if at all. If the Herndon pool fails, the 3DNS System returns the resolution request to DNS. This would actually happen regardless of how the fallback method is set in the Herndon pool, but it is more efficient to set this last fallback to use return_to_dns specifically.

---

Working with static and dynamic wideip.conf files

You now have the option of maintaining your original wideip.conf file separately from a dynamic wideip.conf file that includes the most recent path and LDNS information. The 3DNS Maintenance menu includes two new commands which support this feature: Use Dynamic wideip.conf, and Use Static wideip.conf.

The Update Database command creates two files: /var/3dns/etc/wideip.conf.dynamic and /var/3dns/etc/wideip.conf.static. The /var/3dns/etc/wideip.conf.dynamic file stores the wide IP definitions, path data, and LDNS data. The /var/3dns/etc/wideip.conf.static contains only the globals, bigip statements, hosts statements, and wideip statements.

The Use Dynamic wideip.conf command renames the existing /etc/wideip.conf file to /var/3dns/etc/wideip.conf.ORIG if it is found to be in the Initial state, and it also creates a link from /etc/wideip.conf to /var/3dns/etc/wideip.conf.dynamic.

The Use Static wideip.conf command renames the existing /etc/wideip.conf file to /var/3dns/etc/wideip.conf.ORIG if it is found to be in the Initial state, and it also creates a link from /etc/wideip.conf to /var/3dns/etc/wideip.conf.static.

You can always edit the /etc/wideip.conf file manually in a text editor and the correct file would be modified in preparation for a restart.

Note: A restart must be done before any other dynamic commands, such as Update Database, to prevent losing changes to the edited wideip.conf. To avoid any possible loss of any changes use the Edit 3DNS Configuration command from the menu or the edit_wideip (described below) command directly.

---

Working with new scripts

There are several new scripts supported in the 3DNS System.

3dns_mode conf | watch

The 3dns_mode script takes an argument and returns a text string that displays the wideip.conf mode that the 3DNS System is currently using.

The conf argument determines which wideip.conf mode is currently running. This argument is also available on the 3DNS Maintenance menu as the Display mode of wideip.conf command. There are four different modes:

• Initial
  The /etc/wideip.conf file is an plain file (not a link), and the 3DNS System has never been put into Static or Dynamic mode.
• Static
  The /etc/wideip.conf file is actually a link to /var/3dns/etc/wideip.conf.static.
• Dynamic
  The /etc/wideip.conf file is actually a link to /var/3dns/etc/wideip.conf.dynamic.
• Unknown
  The /etc/wideip.conf file is missing, or is linked to an unknown file that, or is otherwise corrupt.

The watch argument determines whether watchdog-named is currently active. The script returns yes or no.

An invalid argument to 3dns_mode returns a ?.

3dns_dump

Without an argument, this script simply dumps the named cache and creates new versions of the files /var/3dns/etc/wideip.conf.static and /var/3dns/etc/wideip.conf.dynamic, using file /var/run/wideip.cmd. If there already is a wideip.cmd file before the 3dns_dump script is called, wideip.cmd will temporarily be moved, and then restored afterwards. This script prints out an error message if named does not respond to the signal to dump or read in the command file.

dynamic_wideip

This script puts the 3DNS System into Dynamic mode for wideip.conf. The script is also available on the 3DNS Maintenance menu as the Use Dynamic wideip.conf command.

The script first dumps the named cache; if the dump fails, the 3DNS System prompts the user to choose whether to continue the script or exit the script (we recommend that you exit the script if this error occurs). Once the dump is complete, if you are switching the 3DNS System from Initial mode to Dynamic mode, the script backs up the /etc/wideip.conf file to /var/3dns/etc/wideip.conf.ORIG, and changes /etc/wideip.conf to be a link to /var/3dns/etc/wideip.conf.dynamic. If you are switching the 3DNS System from Static mode to Dynamic mode, the script simply changes /etc/wideip.conf to link to /var/3dns/etc/wideip.conf.dynamic (in Static mode, the link points to /var/3dns/etc/wideip.conf.static).

Note: Running this script while the system is already in Dynamic mode is ineffective, and essentially does not change the state of the system.

static_wideip

This script puts the 3DNS System into Static mode for wideip.conf. The script is also available on the 3DNS Maintenance menu as the Use Static wideip.conf command.

The script first dumps the named cache; if the dump fails, the 3DNS System prompts the user to choose whether to continue the script or exit the script (we recommend that you exit the script if this error occurs). Once the dump is complete, if you are switching the 3DNS System from Initial mode to Static mode, the script backs up the /etc/wideip.conf file to /var/3dns/etc/wideip.conf.ORIG, and changes /etc/wideip.conf to be a link to /var/3dns/etc/wideip.conf.static. If you are switching the 3DNS System from Dynamic mode to Static mode, the script simply changes /etc/wideip.conf to link to /var/3dns/etc/wideip.conf.static (in Dynamic mode, the link points to /var/3dns/etc/wideip.conf.dynamic).

Note: Running this script while the system is already in Static mode is ineffective, and essentially does not change the state of the system.

edit_wideip

This script opens the current wideip.conf file in pico and allows you to edit it. The script is also available on the 3DNS Maintenance menu as the Edit 3DNS Configuration command.

In Initial mode, the script edits /etc/wideip.conf. In either Dynamic or Static mode, the script first dumps the named cache; if the dump fails, the 3DNS System prompts the user to choose whether to continue the script or exit the script (we recommend that you exit the script if this error occurs). Once the dump is complete, the script opens /var/3dns/etc/wideip.conf.static (even if in dynamic mode) for editing in pico. Once the edits are completed and you close pico, wideip.conf.static is read as a command to reload into named.

---

Known issues

• Be aware that the discovery factory methodically scans ports on LDNS servers, which can be mistaken for a prelude to an attack. There are several settings that allow you to control which ports are scanned, how often a scan occurs, and what type of protocol a scan uses. If you want to use the discovery factory but have questions about these issues of which port scan settings would be most desirable in your environment, contact F5 Networks technical support.
• In the Wide IPs screen of the 3DNS Web Administration tool, load balancing settings for wideip statements that incorporate multiple pools are available if you click on the domain name for the given wideip statement. The table in the Wide IPs screen itself displays only the load balancing modes for the first VSb pool type, and the first VSh pool type that are defined in the statement.

---

---