DNS agent notes

The DNS agent has the following notes:

High availability fire drill

The high availability fire drill detects discrepancies between the VCS configuration and the underlying infrastructure on a node; discrepancies that might prevent a service group from going online on a specific node.

For DNS resources, the high availability drill performs the following, it:

For more information about using the high availability fire drill see the Veritas Cluster Server User's Guide.

Monitor scenarios

Depending on the existence of the Online lock file and the defined Resource Records (RR), you get different status messages from the Monitor function.

Monitor scenarios for the Online lock file

Online lock file exists

Expected RR mapping

Monitor returns

NO 

N/A 

OFFLINE 

YES 

NO 

OFFLINE 

YES 

YES 

ONLINE 

Sample Web server configuration

Take the former Veritas corporate web server as an example. A person using a web browser specifies the URL www.veritas.com to view the Veritas Web page. Where www.veritas.com maps to the canonical name mtv.veritas.com, which is a host in Mountain View running the web server. The browser, in turn, retrieves the IP address for the web server by querying the domain name servers. If VCS One fails the web server for www.veritas.com from Mountain View to Heathrow, the domain name servers must be updated with the new canonical name mapping. This update occurs so that the web browsers are directed to Heathrow instead of Mountain View. The DNS agent should update the name server to change the mapping of www.veritas.com. From mtv.veritas.com to the canonical name of the standby system in Heathrow, hro.veritas.com, in case of a failover.

Secure DNS update

The DNS agent expects that the zone's allow-update field contains the IP address for the hosts that can dynamically update the DNS records. This functionality is default for the DNS agent. Since a competent black hat can, however, spoof IP addresses, consider TSIG as an alternative.

TSIG (Transaction Signature) as specified in RFC 2845, is a shared key message authentication mechanism, which is available in DNS. A TSIG key provides the means to authenticate and verify the validity of exchanged DNS data. It uses a shared secret key between a resolver and either one or two servers to provide security.

Secure DNS update for BIND 9

The DNS agent expects that the zone's allow-update field contains the IP address for the hosts that can dynamically update the DNS records. This functionality is default for the DNS agent. Since a competent black hat can, however, spoof IP addresses, consider TSIG as an alternative.

TSIG (Transaction Signature) as specified in RFC 2845, is a shared key message authentication mechanism, which is available in DNS. A TSIG key provides the means to authenticate and verify the validity of exchanged DNS data. It uses a shared secret key between a resolver and either one or two servers to provide security.

Setting up secure updates using TSIG keys for BIND 9

In the following example, the domain is example.com.

To use secure updates using TSIG keys

  1. Run the dnssec-keygen command with the HMAC-MD5 option to generate a pair of files that contain the TSIG key:

    # dnssec-keygen -a HMAC-MD5 -n HOST example.com.

    Kexample.com.+157+00000

  2. Open the Kexample.com.+157+00000.key file. After you run the cat command, the contents of the file resembles:

    # cat Kexample.com.+157+00000.key

    example.com. IN KEY 512 3 157 +Cdjlkef9ZTSeixERZ433Q==

  3. Copy the shared secret (the TSIG key), which looks like:

    +Cdjlkef9ZTSeixERZ433Q==

  4. Configure the DNS server to only allow TSIG updates using the generated key. Open the named.conf file and add these lines.

    key example.com. {

    algorithm hmac-md5;

    secret "+Cdjlkef9ZTSeixERZ433Q==";

    };

    Where +Cdjlkef9ZTSeixERZ433Q== is the key.

  5. In the named.conf file, edit the appropriate zone section and add the allow-updates sub-statement to reference the key:

    allow-update { key example.com. ; } ;

  6. Save and restart the named process.
  7. Place the files containing the keys on each of the nodes that is listed in your group's SystemList. The DNS agent uses this key to update the name server.

    Copy both the private and public key files on to the node. A good location is in the /var/tsig/ directory.

  8. Set the TSIGKeyFile attribute for the DNS resource to specify the file containing the private key.

    DNS www (

    Domain = "example.com"

    ResRecord = {www = north}

    TSIGKeyFile a= "/var/tsig/Kexample.com.+157+00000.private"

    )