Novell Home

Integrating Dynamic DNS with Novell Business Continuity Clustering 1.1 for Linux

Novell Cool Solutions: AppNote
By Brad Rupp

Digg This - Slashdot This

Posted: 14 Sep 2007
 

Table of Contents

1 - Introduction
2 - Prerequisites and Assumptions
3 - Configuration
      3.1 - The DNS Server
              3.1.1 - Creating the Keys
              3.1.2 - Configuring the DNS server with the Public Key
              3.1.3 - Configuring the DNS Server Zones
              3.1.4 - Testing the DNS Server
      3.2 - The Cluster Resource
              3.2.1 - The BCC Load Script
              3.2.2 - Public and Private Keys
              3.2.3 - Testing the Perl Wrapper Script
4 - Testing the Final Solution
5 - Parting Thoughts
      5.1 - DNS Record Time-to-live Values
      5.2 - Configuring the Remaining BCC Resources
      5.3 - Redundant DNS Servers
      5.4 - Highly Available DNS Servers
      5.5 - What about NetWare?
6 - Summary
7 - Appendix A: Definitions
8 - Appendix B: References

1 - Introduction

As customers implement Novell Business Continuity Clusters (BCC) one design decision that must always be made is client reconnectivity. In other words, how do the client computers (e.g. your users) reconnect to a particular service when the cluster resource fails over to the disaster recovery site? The core problem is that many times this disaster recovery site is located in a geographically dispersed site and therefore a different network subnet, which forces the cluster resources to use a different IP address range.

As an example of this problem, assume I have a GroupWise Post Office Agent (POA) as a resource in a BCC. On the primary cluster in the BCC, this POA resource has an IP address of 10.1.1.1. However, on the secondary cluster in the BCC, the POA resource has an IP address of 10.1.2.1. During a DR test or a real disaster, the POA resource will be migrated from the primary cluster to the secondary cluster, and thus the IP address of the resource will change. The question is, how do I get my GroupWise clients to reconnect to that POA? Depending on the resource type, this can be accomplished in many ways including SLP, virtual IP, VLANs and DNS updates.

While virtual IP is certainly the most seamless solution, we have found the majority of BCC customers are using DNS updates to solve this problem. Unfortunately, there has been no way to automate this process up until now. With BCC 1.1, the infrastructures is in place for BCC to act as a dynamic DNS client. This article will take you through the steps of integrating dynamic DNS in your BCC solution.

2 - Prerequisites and Assumptions

This article assumes you have a working knowledge of Novell Cluster Services (NCS). After all, if you don't have a cluster and know how to use it you certainly can't get to the next step in high availability and implement a BCC. Furthermore, you must be using BCC 1.1 or later as this solution will not work with BCC 1.0.

It is also assumed that you have a working knowledge of DNS and your particular DNS server. This article was written using 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 support the Dynamic DNS standard RFC 2136. If you do use the ISC BIND DNS server then you should install the bind and bind-utils RPM packages on each node in your BCC.

The last assumption is that you are using Novell Open Enterprise Server 1 (OES) or later based on the SuSE Linux kernel. This solution does not run on the version of OES based on the NetWare kernel simply because the required nsupdate and dig tools is not available for NetWare.

3 - Configuration

With all the preliminary stuff out of the way, lets dive in and get started with configuring your BCC to integrate with dynamic DNS.

3.1 - The DNS Server

We start off by configuring the DNS server so that it will accept dynamic updates to a particular zone as well as to authenticate these updates using TSIG keys.

3.1.1 - Creating the Keys

Obviously we don't want to allow just anyone to be able to update our DNS server. To circumvent this we need to configure the DNS server to authorize updates. For the purposes of this article, we will configure the DNS server to use Transaction Signatures (TSIG). It should be noted that other methods of authorizing updates are available, such as DNSSEC, but it is beyond the scope of this article to discuss these alternative methods. It should also be noted that good security requires more then authorization keys. Logging, monitoring, firewalls, intrusion detection systems, etc. should all be employed to keep your systems and network safe from unwanted access. These too are beyond the scope of this article but should always be considered.

On a node in your secondary cluster, use the dnssec-keygen utility to create a TSIG key (the dnssec-keygen utility should have been installed as part of the bind-9 RPM package). The dnssec-keygen utility will create two files of the format K<name>.+157+<random number>.key and K<name>.+157+<random number>.private. These two files are the public and private keys respectively. You should afford these files the proper protection they deserve. After all, anyone with access to these files will be able to update your DNS server.

The format of the command is as follows:

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST <name>

where:

  • -a specifies the cryptographic algorithm. For dynamic DNS, this must be HMAC-MD5.
  • -b specifies the number of bits in the key. You should use the strongest encryption possible, which in the case of HMAC-MD5 is 512.
  • -n is the name type. Since a computer will be updating the DNS server, I have chosen the HOST name type.
  • <name> is the name of the host. In the case of BCC, the cluster node that hosts the NCS Master IP Address resource will be doing the updating. Since this can be any node in the cluster I have chosen to use the fully qualified name of the cluster as my host name.

For example, to create the key for this article the following command was ran on a node in the secondary cluster:

brupp5:~ #dnssec-keygen -a HMAC-MD5 -b 512 -n HOST 
linux_cluster.bcclab.provo.novell.com

Note that the above command is a single line and may be wrapped. The above command creates two files in the /root directory. They are

Klinux_cluster.bcclab.provo.novell.com.+157+60303.key (the public key) and Klinux_cluster.bcclab.provo.novell.com.+157+60303.private (the private key).
Remember that the number 60303 in the filename is a random number created by the dnssec-keygen utility. Since it is a random number, your filename will be slightly different if you are following along and creating your own keys.

Store these files in a secure location. If you are the DNS administrator, you will need to configure your master DNS server with the public key as outlined in the following sections. Otherwise you should send the public key to the DNS administrator in a secure fashion (e.g. scp or sftp, not e-mail) and have him or her modify the DNS server as outlined below.

3.1.2 - Configuring the DNS server with the Public Key

You can place the public key information right in /etc/named.conf. However, I prefer to create a separate keys.conf file in the /var/lib/named directory so I can lock down /var/lib/named/keys.conf (e.g from junior administrators who have access to /etc/named.conf). With that in mind, modify /etc/named.conf and add the line

	include "keys.conf";

right before the zone configuration.

Once this is done, you need to create the /var/lib/named/keys.conf file. This file contains a section for each key you are going to add. The format of the key section is:

	key <name>. {
		algorithm <cryptographic algorithm>;
		secret ?<the public key secret>?;
	};

where:

  • The key name is the same name used when creating the key via dnssec-keygen. It is also found in the public key file that dnssec-keygen created.
  • The cryptographic algorithm must be HMAC-MD5.
  • The secret is the base 64 encoded secret found in the public key file that the dnssec-keygen utility created. You can copy and paste the secret from the public key file right into /var/lib/named/keys.conf.

For example, the following is the /var/lib/named/keys.conf file created for this article:

	key linux_cluster.bcclab.provo.novell.com. {
        	algorithm HMAC-MD5;
        	secret "SCUT8rIUoGByvcI1Iok7tY7YvcEaHaM3zusCxXmboBxVcJvUxr335HCg
		lXcDQRPrJrzIKQhH4dJ4cY10ebOJFw==";
	};

3.1.3 - Configuring the DNS Server Zones

After the DNS server has been configured with the public keys the next step is to configure the zones so they will accept authorized DNS updates. This is done right in /etc/named.conf by specifying the allow-update keyword and key in the zone configuration sections. Remember that there should be two sections. One for regular lookups and the other for reverse lookups.

For example, the following zone configuration section is found in the /etc/named.conf file created for this article:

	zone "bcclab.provo.novell.com" in {
        	file "dyn/bcclab.provo.novell.com";
        	type master;
        	allow-update {
        	        key linux_cluster.bcclab.provo.novell.com.;
        	};
	};

	zone "1.1.10.in-addr.arpa" in {
        	file "dyn/10.1.1.zone";
        	type master;
        	allow-update {
        	        key linux_cluster.bcclab.provo.novell.com.;
        	};
	};

Notice the allow-update keyword and the inclusion of the key created earlier in this article. These were the only changes made to the existing zone configuration. Once these changes have been made you should restart your DNS server to ensure the new configuration has been imported.

3.1.4 - Testing the DNS Server

If you reach this point in the article then your DNS server is configured to accept secure dynamic updates. The next step would be to test the setup so far and ensure the DNS server is really accepting dynamic updates. The easiest way to accomplish this is to install the bind-utils package on a Linux client machine. You must also ensure the client machine is configured to use the correct DNS server (alternatively, you can force the dig utility to query a specific DNS server).

Once the client machine is properly configured and has the necessary utilities installed on it then it is time to do a base line test. The purpose of the base line test is to view the original configuration of a set of DNS records in the system. For this article, I created a DNS record for the FTP server in my lab. This FTP server has an IP address of 10.1.1.215 which can be verified via the DIG command. For example:

brupp@jekyl:~> dig @10.1.1.172 ftp.bcclab.provo.novell.com

; <<>> DiG 9.3.2 <<>> @10.1.1.172 ftp.bcclab.provo.novell.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47449
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;ftp.bcclab.provo.novell.com.   IN      A

;; ANSWER SECTION:
ftp.bcclab.provo.novell.com. 10 IN      A       10.1.1.215

;; AUTHORITY SECTION:
bcclab.provo.novell.com. 120    IN      NS      brupp5.bcclab.provo.novell.com.

;; ADDITIONAL SECTION:
brupp5.bcclab.provo.novell.com. 120 IN  A       10.1.1.172

;; Query time: 0 msec
;; SERVER: 10.1.1.172#53(10.1.1.172)
;; WHEN: Tue Aug 14 17:19:55 2007
;; MSG SIZE  rcvd: 98

As you can see, the dig command returns the correct IP address of 10.1.1.215. The next base line test is to check the reverse lookup records in the DNS server. This too is also accomplished via the dig command. For example:

brupp@jekyl:~> dig @10.1.1.172 -x 10.1.1.215

; <<>> DiG 9.3.2 <<>> @10.1.1.172 -x 10.1.1.215
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -<<HEADER<<- opcode: QUERY, status: NOERROR, id: 34957
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;215.1.1.10.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
215.1.1.10.in-addr.arpa. 10     IN      PTR     ftp.bcclab.provo.novell.com.

;; AUTHORITY SECTION:
1.1.10.in-addr.arpa.    120     IN      NS      brupp5.bcclab.provo.novell.com.1.1.10.in-addr.arpa.

;; Query time: 0 msec
;; SERVER: 10.1.1.172#53(10.1.1.172)
;; WHEN: Tue Aug 14 17:32:11 2007
;; MSG SIZE  rcvd: 127

Notice the -x command line parameter which indicates a reverse lookup. From the above query, it is easy to see that a reverse lookup returns the DNS name ftp.bcclab.provo.novell.com.

The next step in the testing process is to change the IP address of the FTP record via dynamic DNS. To perform this test, you must securely copy both the public and private keys created above to the client machine. These keys have filenames of the form K<name>.+157+<random number>.key (the public key) and K<name>.+157+<random number>.private (the private key). It should be noted that the nsupdate utility requires the public key for historical reasons. Once this is done, you can update an A record on the DNS server via the nsupdate utility. For example:

brupp@jekyl:~> nsupdate -v -k /home/brupp/Klinux_cluster.bcclab.provo.novell.com.+157+60303.private
> server 10.1.1.172 53
> update delete ftp.bcclab.provo.novell.com. A
> update add ftp.bcclab.provo.novell.com. 300 A 10.1.1.216
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
ftp.bcclab.provo.novell.com. 0  ANY     A
ftp.bcclab.provo.novell.com. 300 IN     A       10.1.1.216

> send
> quit

Likewise, use the nsupdate utility to update the PTR record used for reverse lookups. For example:

brupp@jekyl:~> nsupdate -v -k /home/brupp/Klinux_cluster.bcclab.provo.novell.com.+157+60303.private
> server 10.1.1.172 53
> update delete 215.1.1.10.in-addr.arpa PTR
> update add 216.1.1.10.in-addr.arpa 300 PTR ftp.bcclab.provo.novell.com
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
215.1.1.10.in-addr.arpa. 0      ANY     PTR
216.1.1.10.in-addr.arpa. 300    IN      PTR     ftp.bcclab.provo.novell.com.

> send
> quit

The final step in the testing process is to verify that the changes occurred on the DNS server. Once again, this is done via the dig utility. Both lookups are shown below.

brupp@jekyl:~> dig @10.1.1.172 ftp.bcclab.provo.novell.com

; <<>> DiG 9.3.2 <<>> @10.1.1.172 ftp.bcclab.provo.novell.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35080
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;ftp.bcclab.provo.novell.com.   IN      A

;; ANSWER SECTION:
ftp.bcclab.provo.novell.com. 300 IN     A       10.1.1.216

;; AUTHORITY SECTION:
bcclab.provo.novell.com. 120    IN      NS      brupp5.bcclab.provo.novell.com.

;; ADDITIONAL SECTION:
brupp5.bcclab.provo.novell.com. 120 IN  A       10.1.1.172

;; Query time: 0 msec
;; SERVER: 10.1.1.172#53(10.1.1.172)
;; WHEN: Tue Aug 14 17:50:13 2007
;; MSG SIZE  rcvd: 98
brupp@jekyl:~> dig @10.1.1.172 -x 10.1.1.216

; <<>> DiG 9.3.2 <<>> @10.1.1.172 -x 10.1.1.216
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14497
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;216.1.1.10.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
216.1.1.10.in-addr.arpa. 300    IN      PTR     ftp.bcclab.provo.novell.com.

;; AUTHORITY SECTION:
1.1.10.in-addr.arpa.    120     IN      NS      brupp5.bcclab.provo.novell.com.1.1.10.in-addr.arpa.

;; Query time: 6 msec
;; SERVER: 10.1.1.172#53(10.1.1.172)
;; WHEN: Tue Aug 14 17:55:01 2007
;; MSG SIZE  rcvd: 127

As a final sanity check, a reverse lookup is done with the old IP address to ensure that it does not return an answer.

brupp@jekyl:~> dig @10.1.1.172 -x 10.1.1.215

; <<>> DiG 9.3.2 <<>> @10.1.1.172 -x 10.1.1.215
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49360
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;215.1.1.10.in-addr.arpa.       IN      PTR

;; AUTHORITY SECTION:
1.1.10.in-addr.arpa.    120     IN      SOA     brupp5.bcclab.provo.novell.com.
root.brupp5.bcclab.provo.novell.com. 2007032716 10800 3600 604800 86400

;; Query time: 0 msec
;; SERVER: 10.1.1.172#53(10.1.1.172)
;; WHEN: Tue Aug 14 17:55:07 2007
;; MSG SIZE  rcvd: 105

If you make it to this point successfully and the various tests above look good then your DNS server should be properly configured for dynamic DNS.

3.2 - The Cluster Resource

At this point, it is time to start configuring the individual cluster resources in your BCC to take advantage of dynamic DNS. This is done by modifying each individual cluster resource so it will automatically update the DNS server with the correct IP address of the given resource during a BCC migration.

For those readers new to Novell's BCC product, BCC has the notion of load and unload scripts. These are not the same as the NCS load and unload script that the NCS software uses to online, offline, migrate, or failover a cluster resource in a standard NCS cluster. Rather, the BCC Load and Unload scripts are used during a BCC migration to do such things such as manage the SAN or update eDirectory. In a nutshell, the BCC Load and Unload scripts are used to automate any task that needs to occur when a cluster resource is failed over to an entirely different cluster via the BCC software.

The BCC Load and Unload scripts are Perl based which means a Perl based wrapper for the nsupdate utility will need to be created. Since we want to update the DNS server when the resource moves to another cluster via a BCC migrate, then the appropriate location for the nsupdate utility wrapper script would be in the BCC Load scripts. Most likely the nsupdate utility wrapper script would be the last BCC Load script to run, but this may not be the case for all environments.

3.2.1 - The BCC Load Script

The following is the Perl script that wraps the nsupdate utility. It should be noted that this script has been modified slightly in order to aid in formating for this article. The actual script has been included with this article as the file bcc_dyn_dns.pl.

#!/usr/bin/perl -w
#****************************************************************************
#
# Copyright (c) 2007 Novell, Inc. All Rights Reserved.
# THIS WORK IS SUBJECT TO U.S. AND INTERNATIONAL COPYRIGHT LAWS AND TREATIES.
# NO PART OF THIS WORK MAY BE USED, PRACTICED, PERFORMED COPIED, DISTRIBUTED,
# REVISED, MODIFIED, TRANSLATED, ABRIDGED, CONDENSED, EXPANDED, COLLECTED,
# COMPILED, LINKED, RECAST, TRANSFORMED OR ADAPTED WITHOUT THE PRIOR WRITTEN
# CONSENT OF NOVELL, INC. ANY USE OR EXPLOITATION OF THIS WORK WITHOUT
# AUTHORIZATION COULD SUBJECT THE PERPETRATOR TO CRIMINAL AND CIVIL LIABILITY.
#
#  Author:	Novell, Inc.
#  Workfile:	bcc_dyn_dns.pl
#  Contents:	BCC wrapper for the BIND nsupdate utility.
#
#****************************************************************************

package bcc_dyn_dns;

#**********************************************************************
#	Use Statements
#**********************************************************************
use strict;
use warnings;
use diagnostics;

#**********************************************************************
# Name:		ReverseIP
# Description:	Reverses the IP address for use in reverse lookup zones
# Parameters:	scalar	- (string) IP address to reverse
# Return:	scalar	- (string) Reversed IP address
# Notes:
#**********************************************************************
sub ReverseIP($)
{
	my ($ip) = @_;
	my @temp_ip;
	my $reverse_ip;

	@temp_ip = split(/\./, $ip);
	$reverse_ip = join(".", reverse(@temp_ip));

	return($reverse_ip);
}

#**********************************************************************
# Name:		Main program entry point
# Description:	Updates an RFC 2136 compliant DNS server (e.g. BIND)
# 		with the new IP address of the given host name.  The
# 		script accomplishes this by using the 'nsupdate' and 
# 		'dig' utilities that are included in the bind-utils
# 		package.
# Parameters:	None
# Return:	int	- 0 on success.  nsupdate error otherwise.
# Notes:
#**********************************************************************

my $result;
my $output;
my $command;
my $nsupdate		= "nsupdate -v";	# use nsupdate -d -v to turn on debugging
my $dns_server_addr	= "%DNS_SERVER_ADDR%";	# The IP address or host name of the DNS master (e.g. 10.1.1.172)
my $host_name		= "%HOST_NAME%";	# The host name of the cluster resource whose IP address will be
updated (e.g. ftp.bcclab.provo.novell.com)
my $host_record_ttl	= "%HOST_RECORD_TTL%";	# The time-to-live value of the DNS record in seconds (e.g. 300)
my $host_ip		= "%HOST_IP%";		# The new IP address of the cluster resource (e.g. 10.1.1.216)
my $key_file		= "%KEY_FILE%";		# The location of the private key file.  
(e.g. /mnt/bcc-master/dyndns/keys/Klinux_cluster.bcclab.provo.novell.com.+157+60303.private)
my $reverse_host_ip;
my $old_host_ip;
my $old_reverse_host_ip;

# Strip any trialing dots from the host name if needed
while ($host_name =~ m/\.$/)
{
	chop($host_name);	
} # while ($host_name =~ m/\.$/)

# Figure out the IP address needed for reverse lookups
$reverse_host_ip = ReverseIP($host_ip);

# Query the DNS server for the old IP address
$old_host_ip = `dig \@$dns_server_addr $host_name +short`;
chomp($old_host_ip);
$old_reverse_host_ip = ReverseIP($old_host_ip);

# Format the command that is sent to nsupdate
$command  = "server $dns_server_addr\n";
$command .= "update delete $host_name. A\n";
$command .= "update add $host_name. $host_record_ttl A $host_ip\n";
# The default is to add 'A' records
$command .= "show\n";
$command .= "send\n";
$command .= "update delete $old_reverse_host_ip.in-addr.arpa PTR\n";
$command .= "update add $reverse_host_ip.in-addr.arpa $host_record_ttl PTR $host_name\n";	
# The default is to add 'PTR' records for reverse lookups
$command .= "show\n";
$command .= "send\n";
$command .= "quit\n";

# Document the fact that we are updating the DNS server
print("\n*****************************************************************************\n");
print("*** BCC: Updating DNS record for host $host_name\n");
print("*** IP: $host_ip, TTL: $host_record_ttl seconds\n");
print("*** DNS Server: $dns_server_addr\n");
print("*****************************************************************************\n\n");

# Uncomment the following lines to log the commands that are going to be sent
# to the DNS server.
#print("* * * * *  Start of nsupdate commands  * * * * *\n\n");
#print($command);
#print("\n* * * * *  End of nsupdate commands  * * * * *\n\n");

eval
{
	# Make it so my good man
	$output = `echo -n \"$command\" | $nsupdate -k $key_file`;

	# Get the real error code
	$result = $?;				# Save the return value of nsupdate
	$result = $result >> 8;

	# Uncomment the following lines to log the output from nsupdate
	#print("* * * * *  Start of nsupdate output  * * * * *\n\n");
	#print($output);
	#print("\n\nReturn code: $result\n");
	#print("\n* * * * *  End of nsupdate output  * * * * *\n\n");
}; # eval
if ($@)
{
	print("There was a fatal error updating the DNS server.  If the problem\n");
	print("persists, please contact Novell Technical Support.  The error details are:\n");
	print($@);

	$result = 255;
} #if ($@)

print("\n*****************************************************************************\n");
print("*** BCC: Done updating DNS record for host $host_name\n");
print("*** Result: $result\n");
print("*****************************************************************************\n\n");

exit($result);

The above script can be used as a BCC load script without any modifications. To use this script, you need to modify the cluster resource via iManager. It should be noted that iManager is the only management utility supported by BCC (i.e. Novell Remote Manager and ConsoleOne are not supported by BCC). Once you have connected to iManager via a web browser you should perform the following steps to save the dynamic DNS script as a BCC Load script.

  1. Select Clusters followed by Cluster Options in the Roles and Tasks pane on the left of the browser window.
  2. In the right pane, select the secondary cluster in the BCC environment (similar changes will be made to the resource on the primary cluster at a later point in this article).
  3. Modify the resource you want to add dynamic DNS support to by clicking on the resource name. This brings up the property page for the given resource
  4. Click on the Business Continuity tab followed by the SAN Management link right under the tabs.

If you followed the above steps correctly, you should see something similar to the page shown in Illustration 1. Please note that the color scheme for your pages may look different based on what version of iManager you are using (the screen shots for this article were created using iManager 2.7.0).

One important point to be aware of is that this script cannot be executed directly by a Perl interpreter. The problem is the BCC variables used in lines 62 ? 66 of the script. The Perl interpreter will not understand these variables and will show a compilation error if you try to execute this script as is. However, it is a simple matter to change these variables to the actual values needed. This allows you to test the script outside of a BCC environment via a Perl interpreter. Just be sure to put the variables back in place before using this script in BCC. More details on testing the script are given later in this article.


Illustration 1:SAN Management page in iManager

Illustration 1 shows a single BCC Load Script, named BCC Test for the resource Test1. To add a new BCC Load Script, click the New link in the BCC Load Script table. This brings up the SAN Management Script Details page as shown in Illustration 2 below.


Illustration 2: SAN Management Script Details page in iManager

This page is where the BCC Load and Unload scripts are created. Since we selected New in the BCC Load Script table, rather then in the BCC Unload Script table, this page is creating a new BCC Load Script. This page has a lot of fields for handling CIM and SMI-S enabled scripts that manage a physical SAN. These are not needed for the dynamic DNS script, so we should immediately clear the CIM Enabled check box at the bottom of the page. Once this is done the only fields that matter are the Name, Description, Script Parameters, the script edit box, and the Synchronous check box. Each of these will be discussed in detail below.

Name
This is the name of the script and will be shown in the BCC log files (e.g. /var/log/messages). This can be any string that you want but should give enough information that the entries in the log file will be meaningful. For this article, we will name the script Dynamic DNS Update ? Resource Test1. That way, we know what the script is doing and which resource it is acting upon.

Description
The description field can be any string that better helps you understand the nature of the script. It is not displayed in any of the BCC log files.

CIMOM IP/DNS
The CIMOM IP/DNS field is used by CIM or SMI-S enabled scripts. Since the CIM Enabled check box was cleared this field is not needed for the dynamic DNS script.

Namespace
The CIMOM IP/DNS field is used by CIM or SMI-S enabled scripts. Since the CIM Enabled check box was cleared this field is not needed for the dynamic DNS script.

Port
The port field is used by CIM or SMI-S enabled scripts. Since the CIM Enabled check box was cleared this field is not needed for the dynamic DNS script.

Secure
The secure check box is used by CIM or SMI-S enabled scripts. Since the CIM Enabled check box was cleared this field is not needed for the dynamic DNS script.

Username
The username field is used by CIM or SMI-S enabled scripts. Since the CIM Enabled check box was cleared this field is not needed for the dynamic DNS script.

Password
The password field is used by CIM or SMI-S enabled scripts. Since the CIM Enabled check box was cleared this field is not needed for the dynamic DNS script.

Script Parameters

The script parameters are used to customize the dynamic DNS script to work with a particular DNS server. A script parameter is added to the table by clicking on the new link. This inserts a new editable row into the script parameters table. The left field is the parameter name and the right field is the parameter value. When you are done adding the name value pair, click on the OK button to save the parameter. Illustration 3 shows the process of entering name/value pairs in the script parameters table.

The following are the name value pairs that must be entered into the script parameters table for the dynamic DNS script.

Name Value Description
DNS_SERVER_ADDR IP Address The IP address of the DNS master server (e.g. 10.1.1.172)
HOST_NAME Host name string The host name of the cluster resource whose IP address will be updated (e.g. ftp.bcclab.provo.novell.com)
HOST_RECORD_TTL Time-to-live The time-to-live value of the DNS record in seconds (e.g. 60)
HOST_IP IP Address The new IP address of the cluster resource (e.g. 10.1.1.216)
KEY_FILE Path and filename of key The location of the private key file (e.g. /mnt/bcc-master/dyndns/keys/Klinux_cluster.bcclab.provo.novell.com.+157+60303.private). Remember that the public key must be in this same directory too.

Script
The script edit box is where the dynamic DNS script should be placed. You can simply cut and paste the dynamic DNS script above into the script edit box. The script edit box does not have a label, but it is the large edit box on the SAN Management Script Details page shown in Illustration 2.

CIM Enabled
As stated earlier, the Dynamic DNS script is not CIM or SMI-S enabled. Therefore, the CIM Enabled check box should be cleared. Once this check box is cleared, the CIMON IP/DNS, Namespace, Port, Secure, Username, and Password controls are all disabled.

Synchronous
The Synchronous check box is used to synchronize execution of multiple BCC load and unload scripts. This is not necessary for the dynamic DNS script so this check box can be left in the cleared state.

Edit Flags
The Edit Flags check box is an advanced option that should only be enabled when instructed to do so by Novell Technical Services. As such, this check box should remain in the cleared state.


Illustration 3:Entering name/value pairs in the Script Parameters table

Once you have entered all of the information in the SAN Management Script Details page for the dynamic DNS script you can click OK to return to the Cluster Resource Properties page for the resource you were modifying. Remember to click OK again on the Cluster Resource Properties page to actually save the new dynamic DNS BCC load script.

3.2.2 - Public and Private Keys

The BCC Load and Unload scripts always run on the node that is hosting the NCS master resource (e.g. the Master_IP_Address_Resource). This resource can be hosted on any node in the NCS cluster which means the BCC Load and Unload scripts can also be executed on any node in the cluster.

The Perl wrapper script for nsupdate needs access to both the private and public keys created in the section title Creating the Keys above (nsupdate really only needs access to the private key. However, for historical reasons the public key must be in the same location as the private key).

Since the keys are stored in a file, the files must be available on all nodes in the cluster. This can be accomplished in one of two ways.

  1. 1.Copy the keys to the same location on each node in the cluster. While this is simple and relatively quick to do initially, it makes for a maintenance nightmare. If the keys ever change then they must be copied to all nodes in the cluster. Failure to copy the keys to all nodes in the cluster (e.g. when a node is down for maintenance) will result in the potential for failure in the dynamic DNS update process. You must also remember to copy the keys to any nodes you add to the cluster at a later date.
  2. 2.Create a cluster resource that hosts a small disk volume using any standard journaled Linux file system (e.g. EXT3, ReiserFS, etc.). This cluster resource must be configured with the Resource Follows Master setting enabled as shown in Illustration 4. This setting forces the given resource to always be hosted by the same node that is hosting the NCS master resource. The keys can then be copied to the file system hosted by this resource which will make them available to the same node that is hosting the NCS master resource, and therefore to the BCC Load and Unload scripts. This option takes a bit more configuration time up front, but results in easier maintenance down the road. If the keys change then they only need to be copied to one place ? the file system hosted by this resource. Furthermore, if a node is ever added to the cluster at a later date then there is nothing to do as the new node will have access to the keys if it ever becomes the NCS master.


Illustration 4:Configuring a resource to follow the master

The second approach described above will be used in this article. For this article, we created a 10MB volume on an EXT3 file system. We named the cluster resource BCC-Master and the file system is mounted at /mnt/bcc-master. As described above, the BCC-Master resource is configured with the Resource Follows Master setting enabled.

Once the BCC-Master resource is created, both the public key and the private key files are copied to the /mnt/bcc-master/dyndns/keys directory on the NCS master node as verified via the following directory listing.

	brupp5:~ # ll /mnt/bcc-master/dyndns/keys/
	total 4
	drwxr-xr-x  2 root root 1024 Aug 30 14:28 .
	drwxr-xr-x  3 root root 1024 Aug 30 13:04 ..
	-rw-------  1 root root  146 Aug 30 14:04 Klinux_cluster.bcclab.provo. novell.com.+157+60303.key
	-rw-------  1 root root  145 Aug 30 14:28 Klinux_cluster.bcclab.provo. novell.com.+157+60303.private
	brupp5:~ #

Note that root is the only user that is allowed access to the key files. This provides additional security so other users cannot modify your DNS server.

More details on creating a cluster resource that hosts a standard Linux filesystem can be found at http://www.novell.com/documentation/oes/cluster_admin_lx/data/h2mdblj1.html#bsqyr3y.

3.2.3 - Testing the Perl Wrapper Script

As noted earlier, the dynamic DNS script cannot be compiled directly by a Perl interpreter due to the BCC variables on lines 62 ? 66 of the script. It is a simple matter to manually test the dynamic DNS script to see if it is working properly and if our DNS server is configured properly as well. This can be accomplished by first copying the script to the local file system on the NCS master node (e.g. /tmp/bcc_dyn_dns.pl). We make a local copy of the script as we do not want to modify the version that BCC will use as stored in iManager during the steps above.

Once a local copy has been made, remove the BCC variables by modifying lines 62 ? 66 of the script. The uppercase string surrounded by the percent character ( % ) is the BCC variable and should be replaced with the real value (e.g. %DNS_SERVER_ADDR%). For example, lines 62 ? 66 of the script could be modified like the following:

	my $dns_server_addr	= "10.1.1.172";
	my $host_name		= "ftp.bcclab.provo.novell.com";
	my $host_record_ttl	= "60";
	my $host_ip			= "10.1.1.216";
	my $key_file		= "/mnt/bcc/dyndns/keys/Klinux_cluster.bcclab.provo.novell.com.+157+60303.private";

The above values should reflect the actual values for your environment. Once these modifications have been made, you can test the solution by invoking the Perl interpreter on the script via the following command

perl -w /tmp/bcc_dyn_dns.pl

This will execute the dynamic DNS script and modify your DNS server. You can test the results as outlined above in the section titled Testing the DNS Server above.

4 - Testing the Final Solution

We are almost ready to test the final solution of having BCC automate the dynamic DNS update process via the BCC Load scripts. Before this can be done, one final step must be taken care of. Up to this point, the dynamic DNS BCC Load script has created on the test resource in the context of the secondary cluster. This allows the DNS server to be updated when we failover the resource from the primary cluster to the secondary cluster. The same thing needs to be done on the primary cluster so the DNS sever will be updated when we failback from the secondary cluster to the primary cluster. With this in mind the steps in the Configuration section above should be repeated in the context of the primary cluster before continuing.

At this point, it is assumed that the dynamic DNS BCC Load script has been created on the test resource in the context of both the primary and the secondary cluster. The final solution can be tested by following the following steps.

  1. 1.Perform a BCC migrate (failover) of the test resource from the primary cluster to the secondary cluster. The dynamic DNS script will run before the cluster resource is onlined on the secondary cluster. If everything worked correctly the DNS server will be updated by the time the cluster resource comes online on the secondary cluster.

  2. 2.Test the results of the dynamic DNS update by following the steps outlined in the section titled Testing the DNS Server above.

  3. 3.Perform a BCC migrate (failback) of the test resource from the secondary cluster to the primary cluster. As in step 1, the dynamic DNS script will run before the cluster resource is onlined on the primary cluster. If everything worked correctly the DNS server will be updated by the time the cluster resource comes online on the primary cluster.

  4. 4.Once again, test the results of the dynamic DNS update by following the steps outlined in the section titled Testing the DNS Server above.

If things don't work quite right go back and review the Configuration section above. If everything worked as advertised, then congratulations on automating one more step in your disaster recovery process.

5 - Parting Thoughts

Before wrapping up this article, there are a few topics that need to be covered that don't nicely fit elsewhere in this document. This section is to provide you with some ?food for thought? for the implementation of BCC in your particular environment.

5.1 - DNS Record Time-to-live Values

Selecting the proper Time-to-live (TTL) value for the DNS records can be a bit tricky. If the values are too short then the DNS traffic on your network can increase dramatically. If the values are too long then the end users will not be able to reconnect to the cluster resources following a BCC migration until the DNS records expire. There is no perfect TTL value as 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.

5.2 - Configuring the Remaining BCC Resources

This article outlines how to enable dynamic DNS for a single resource. It is expected that the reader will enable dynamic DNS on all BCC resources in their BCC environment.

5.3 - Redundant DNS Servers

It is beyond the scope of this article to outline proper DNS design and implementation. However, it should be noted that any proper DR strategy would involve redundant DNS servers that make use of secure zone transfers. Furthermore, redundant DNS servers should be implemented at each individual DR site.

5.4 - Highly Available DNS Servers

Another option for your DNS servers is to put them in your NCS cluster. This creates a DNS service that is extremely resilient to failure. More information on configuring DNS with Novell Cluster Services can be found at http://www.novell.com/documentation/oes/ cluster_resource_lx/index.html?page=/documentation/oes/cluster_resource_lx/data/bpt02ho.html.

5.5 - What about NetWare?

This article has discussed implementing dynamic DNS in a BCC as a Linux only solution. Long time Novell users might be wondering about their faithful companion NetWare. The reason this solution cannot be implemented on NetWare is that the nsupdate and dig utilities this solution uses are not available on NetWare. However, the utilities are open source so technically it is possible for someone to port them to NetWare.

6 - Summary

This article has explained how to implement dynamic DNS on a single resource in a Novell Business Continuity Cluster. Armed with this knowledge, the reader should be able to implement dynamic DNS on all BCC resources in their environment, which will aid in solving the client reconnectivity problem that occurs in geographically dispersed disaster recovery solutions.

Appendix A: Definitions

The following are definitions of some of the terms and acronyms used in this article.

BCC
Novell Business Continuity Cluster. This is Novell's premier disaster recovery product. More information can be found at http://www.novell.com/products/businesscontinuity/.

CIM
Common Information Model. A standard published by the Distributed Management Task Force (DMTF) that provides a common definition of management information for systems, networks, applications and services. More information on CIM can be found at http://www.dmtf.org/standards/cim/

DNS
Domain Name System. There are thousands of really good references to DNS on the World Wide Web. I will leave it as an exercise for the reader to use their favorite search engine and search for information on the Domain Name System.

NCS
Novell Cluster Services. This is Novell's clustering product for Novell Open Enterprise Server on both Linux and NetWare. More information can be found at http://www.novell.com/products/clusters/ncs/.

Primary
Terminology in BCC that refers to the cluster that is currently hosting a particular resource. A resource can only be primary on one cluster at any given point in time.

Secondary
Terminology in BCC that refers to the cluster(s) that are not hosting a particular resource. A resource can be secondary on multiple clusters at any given point in time.

SMI-S
Storage Management Initiative Specification. A standard published by the Storage Networking Industry Association (SNIA) that standardizes interoperable storage management technologies. SMI-S is based on CIM. More information on SMI-S can be found at http://www.snia.org/smi/home.

TTL
Time-to-live. This is the time, in seconds, that a DNS record is considered valid. After a DNS record has expired it is considered stale and the client must refresh the DNS record information from an authoritative DNS server.

Appendix B: References

Dynamic Updates in the Domain Name System (DNS Update)
http://www.ietf.org/rfc/rfc2136.txt?number=2136

ISC Bind
http://www.isc.org/index.pl?/sw/bind/

Novell Business Continuity Cluster
http://www.novell.com/products/businesscontinuity/

Novell Cluster Services
http://www.novell.com/products/clusters/ncs/


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell