Install and configure your business continuity cluster using the following components:
Business Continuity Clustering
Novell Cluster Services
Open Enterprise Server 23.4
To integrate dynamic DNS in your BCC solution, use the bcc_dyn_dns.pl NSMI script that is included in the BCC software CD in the <media>/nsmi_scripts/linux directory.
The examples used in this BCC 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 OES Cluster Services
in the OES 23.4: DNS/DHCP Services for Linux Administration Guide.
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 challenging. 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.