Install and configure your business continuity cluster using the following components:
Novell Business Continuity Clustering 1.2 for Linux
Novell Cluster Services™ 1.8.6 for Linux
Novell Open Enterprise Server 2 SP1 for Linux
To integrate dynamic DNS in your BCC solution, use the bcc_dyn_dns.pl NSMI script that is included in the BCC 1.2 ISO image in the <media>/nsmi_scripts/linux directory.
The examples used in this BCC 1.2 for Linux solution use the ISC BIND 9 DNS server on Linux. It is not a requirement that you use the ISC BIND DNS server, but your DNS server must meet the following requirements:
Your DNS server must support the Dynamic DNS standard in RFC 2136.
If you use the ISC BIND DNS server, you should install the bind and bind-utils RPM packages on each node in your business continuity cluster.
We recommend that your DNS strategy involve redundant DNS servers that make use of secure zone transfers. Furthermore, redundant DNS servers should be implemented at each individual disaster recovery site.
Another option for your DNS servers is to put them in your Novell Cluster Services cluster. This creates a DNS service that is extremely resilient to failure. For information, see Configuring DNS with Novell Cluster Services
in the OES 2 SP1: Novell DNS/DHCP Administration Guide for Linux.
TSIG (Transaction Signature) keys are used in the examples to authenticate dynamic updates of the DNS server. It is not a requirement that you use TSIG. Other methods of authorizing updates can be used instead, such as DNSSEC (DNS Security Extensions). In addition, good security requires more then authorization keys. Logging, monitoring, firewalls, intrusion detection systems, and so on should all be employed to keep your systems and network safe from unwanted access. However, it is beyond the scope of this document to cover these alternatives.
The TSIG dnssec-keygen utility should be automatically installed as part of the ISC BIND 9 DNS server package.
Selecting the proper Time-to-live (TTL) value for the DNS records can be a bit tricky. If the values are too short, the DNS traffic on your network can increase dramatically. If the values are too long, the end users are unable to reconnect to the cluster resources after a BCC migration until the DNS records expire. There is no perfect TTL value. Each customer and environment is unique and has different needs and goals. You should experiment with the TTL values while monitoring the DNS traffic on your network to find the ideal value for your network.