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 in the sidebar, then select Servers.
- Select the row actions button (⋮) for an xHA pair, then select Edit.
-
Under General, set the following parameters:
- Name—edit the name for the xHA pair.
-
To enable/disable backbone communication: On the xHA
backbone tab, set the following parameters:
- Enable xHA backbone communication—select this
checkbox to enable xHA backbone communication. Additional fields appear
to configure the backbone IP addresses and netmasks/prefixes for the
active and passive nodes. If you previously configured the xHA backbone
when adding the DNS/DHCP Server or creating
xHA, the IP addresses and netmasks/prefixes for the active and passive
nodes will be pre-populated with the existing values. If this is your
first time configuring the xHA backbone connection, enter the IP
address and netmask/prefix lengths for the active and passive
servers.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.
- Enable xHA backbone communication—select this
checkbox to enable xHA backbone communication. Additional fields appear
to configure the backbone IP addresses and netmasks/prefixes for the
active and passive nodes. If you previously configured the xHA backbone
when adding the DNS/DHCP Server or creating
xHA, the IP addresses and netmasks/prefixes for the active and passive
nodes will be pre-populated with the existing values. If this is your
first time configuring the xHA backbone connection, enter the IP
address and netmask/prefix lengths for the active and passive
servers.
-
On the Validation options tab, set the following options to override
DHCP and DNS services configuration or DNS zones validation settings
configured at the configuration level:
- Override configuration level DHCP validation settings—select
the checkbox to set DHCP deployment validation options that are
specific to the server. If selected, the Enable DHCP
configuration validation checkbox appears.
- Enable DHCP configuration validation—select the checkbox to check the syntax of the dhcpd.conf file and validate data prior to deployment from Address Manager.
- Override configuration level DNS validation settings—select
the checkbox to set deployment validation options that are specific
to the server. If selected, the Enable DNS configuration
validation and Enable DNS zone validation checkboxes appear:
- Enable DNS configuration validation—select the checkbox to check the syntax of the named.conf file and validate data prior to deployment from Address Manager.
- Enable DNS zones validation—select the checkbox to
check the syntax of each DNS zone file and validated data
prior to deployment from Address
Manager. This is equivalent to setting the
-i switch for the
named-checkzone tool. If
selected, the DNS zones deployment validation settings are
displayed. If Enable DNS zone
validation is selected, configure the
following DNS zones validation settings:
- 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 doesn't check the glue records.
- Local-sibling—performs the same checks as in Local mode but doesn't 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.
- 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:
- Override configuration level DHCP validation settings—select
the checkbox to set DHCP deployment validation options that are
specific to the server. If selected, the Enable DHCP
configuration validation checkbox appears.
-
On the Kerberos service principal tab, set the DNS and DHCP service
principals:
- Enable DNS service principal—select this checkbox to specify the security credential for the DNS service to use to authenticate keys requested by the GSS-TSIG protocol. When you select this checkbox, the DNS Service Principal drop-down menu appears. Select a Kerberos service principal from the drop-down menu.
- Enable DHCP service principal—select this checkbox to specify the security credential for the DHCP service to use to authenticate keys requested by the GSS-TSIG protocol. When you select this checkbox, the DHCP Service Principal drop-down menu appears. Select a Kerberos service principal from the drop-down menu.
- On the Change control tab, add change control comments, if required.
- Select Save.