You can edit the name and settings for the xHA pair. Editing an xHA pair is similar to editing a single server.
Note: You can't delete an xHA pair. You must first
break xHA then delete the standalone servers. For details, refer to Breaking an xHA pair.
To edit an xHA pair:
- Select the Servers tab. Tabs remember the page you last worked on, so select the tab again to ensure you're on the Configuration information page.
- From the configuration drop-down menu, select a configuration.
- Under Servers, click the name of the xHA pair. The Details tab for the xHA pair opens.
- Click the menu beside the xHA pair name and select Edit.
- Under xHA IP Address Settings, edit the name for the pair in the Name field.
-
Under xHA Communication Interface, edit the
following:
- Enable xHA Backbone Communication—select or
deselect this check box to enable or disable xHA data replication
through the xHA/eth1 ports on the servers in the xHA pair. When
selected, the IP address and netmask/prefix fields for the active and
passive servers appear:Note: If you added an xHA backbone IP address when initially adding your DNS/DHCP Server to Address Manager, that value will be used to populate the fields for the active and passive servers. If desired, you can edit the IP addresses and netmasks/prefixes to overwrite the initial xHA backbone settings.Attention: Make sure to configure the IP addresses of the xHA interfaces (eth1) on a different subnet than any other interfaces. This is the recommended best practice for direct xHA backbone connections and connections over switches or wide area networks (WAN), but is not mandatory if you're using a direct connection to the eth1 interface on each DNS/DHCP Server. In addition, if the DNS/DHCP Servers are not connected by a direct ethernet xHA backbone connection, the xHA interfaces should be separated onto a different LAN segment to prevent the xHA interfaces from receiving layer-2 broadcast traffic intended for other interfaces. This can be achieved by separate VLANs for each interface, private networks (for virtual appliances), or separate physical switches. For information and help on running xHA with switches, contact BlueCat Customer Care. For details on creating an xHA pair in Address Manager, refer to Managing xHA.Note: When configuring an IPv6 address for the xHA backbone, the prefix must be set between the accepted CIDR range of 64 to 127.
- Active Server IPv4 / IPv6 Address (eth1)—edit the IP address of the xHA interface for the active server.
- Active Server IPv4 Netmask / IPv6 Prefix (eth1)—edit the IP netmask of the xHA interface for the active server.
- Passive Server IPv4 / IPv6 Address (eth1)—edit the IP address of the xHA interface for the passive server.
- Passive Server IPv4 Netmask / IPv6 Prefix (eth1)—edit the IP netmask of the xHA interface for the passive server.
- Enable xHA Backbone Communication—select or
deselect this check box to enable or disable xHA data replication
through the xHA/eth1 ports on the servers in the xHA pair. When
selected, the IP address and netmask/prefix fields for the active and
passive servers appear:
-
Under Deployment Validation Options, edit the validation
options for DNS and DHCP deployment zone files:
- Override configuration level DHCP deployment validation settings—select/deselect the check box to permit/deny the server to inherit the deployment validation settings set at the configuration level. If selected, the Check DHCP configuration on deployment check box appears.
- Check DHCP configuration on deployment—select the check box to check the syntax of the dhcpd.conf file and validate data deployed from Address Manager.
- Override configuration level DNS deployment validation settings—select/deselect the check box to set deployment validation options that are specific to the server. If selected, the Check DNS configuration on deployment and Check DNS zones on deployment check boxes appear:
- Check DNS configuration on deployment—select/deselect the check box to check the syntax of the named.conf file and validate data deployed from Address Manager.
- Check DNS zones on deployment—select the check box to check the syntax of each DNS zone file and validated data deployed from Address Manager. This is equivalent to setting the -i switch for the named-checkzone tool. When selected, the DNS Zones Deployment Validation Setting section opens on the page.
-
Under DNS Zones Deployment Validation Setting,
complete the following:
- Post-load zone integrity
validation—performs syntax checks based on the mode
you select for this option. Select one of the following
modes:
- Full—checks for the following
conditions:
- If MX records refer to A or AAAA records, for both in-zone and out-of-zone hostnames.
- If SRV records refer to A or AAAA records, for both in-zone and out-of-zone hostnames.
- If Delegation NS records refer to A or AAAA records, for both in-zone and out-of-zone hostnames
- If glue address records in the zone match those specified by the child.
- Local—checks for the following
conditions:
- If MX records refer to A or AAAA records, for in-zone hostnames.
- If SRV records refer to A or AAAA records, for in-zone hostnames.
- If Delegation NS records refer to an A or AAAA record, for in-zone hostnames.
- If glue address records in the zone match those specified by the child.
- Full-sibling—performs the same checks as in Full mode but does not check the glue records.
- Local-sibling—performs the same checks as in Local mode but does not check the glue records.
- None—disables all post-load zone integrity checks.
- Full—checks for the following
conditions:
- Check names—Checks names. Select Ignore, Warn, or Fail to determine how Address Manager handles conditions found by this check.
- Check if MX records are IP addresses—checks if MX records point to an IP address rather than an A or AAAA record. This is equivalent to setting the -M switch for the named-checkzone tool. Select Ignore, Warn, or Fail to determine how Address Manager handles conditions found by this check.
- Check if MX records point to CNAME records—checks if MX records point to a CNAME record rather than an A or AAAA record. This is equivalent to setting the -M switch for the named-checkzone tool. Select Ignore, Warn, or Fail to determine how Address Manager handles conditions found by this check.
- Check if NS records are IP addresses—checks if NS record point to an IP address rather than an A or AAAA record. This is equivalent to setting the -n switch for the named-checkzone tool. Select Ignore, Warn, or Fail to determine how Address Manager handles conditions found by this check.
- Check if SRV records point to CNAME records—checks is SRV record point to a CNAME record rather than A or AAAA record. This is equivalent to setting the -S switch for the named-checkzone tool. Select Ignore, Warn, or Fail to determine how Address Manager handles conditions found by this check.
- Check for non-terminal wildcards—checks for wildcards in zone names that don't appear as the last segment of a zone name: for example, mail.*.example.com. Non-terminal wildcards are permissible, but you may want to be alerted to their presence. This is equivalent to setting the -W switch for the named-checkzone tool. Select Ignore or Warn to determine how Address Manager handles conditions found by this check.
For the preceding options, Ignore, Warn, or Fail have the following effects:- Ignore—Ignores the condition, so it isn't logged in the Zone Validation server log. Deployment proceeds with the zone data containing the condition.
- Warn—Logs the condition in the Zone Validation server log. Deployment proceeds with the zone data containing the condition.
- Fail—Logs the condition in the Zone Validation server log. Deployment fails. The existing DNS data is left in place and the new data isn't deployed.
- Post-load zone integrity
validation—performs syntax checks based on the mode
you select for this option. Select one of the following
modes:
-
Under Kerberos Service Principal, set the DNS and DHCP
service principals:
- Enable DNS Service Principal—select to specify the security credential for the DNS service to use to authenticate keys requested by the GSS-TSIG protocol. When you select this check box, Realm and Principal fields appear. Select a Kerberos realm and service principal from the Realm and Principal drop-down menus.
- Enable DHCP Service Principal—select this check box to specify the security credential for the DHCP service to use to authenticate keys requested by the GSS-TSIG protocol. When you select this check box, Realm and Principal fields appear. Select a Kerberos realm and service principal from the Realm and Principal drop-down list.
- Under Additional Information, enter the new user-defined value for the active server in the xHA pair. This section only appears if you have added optional user-defined fields for the server object type.
- Under Change Control, add comments, if required.
- Click Update.