Page tree

Contents

When scheduling a full upgrade in NIOS, the Grid Master replicates the following to the Grid members, including those that have not been upgraded:

  • DNS resource records
  • DNS zones
  • DNS views
  • Name server groups
  • Shared record groups
  • IPv4 and IPv6 host addresses
  • Roaming hosts
  • IPv4 and IPv6 networks
  • IPv4 and IPv6 shared networks
  • Fixed addresses
  • DHCP ranges
  • DHCP failover association
  • DHCP option spaces
  • DHCP options
  • DHCP filters
  • MAC filter items
  • Blacklist & NXDOMAIN rules
  • DNSSEC key pairs
  • DNSSEC import keyset operation
  • Signed and unsigned zones
  • DNSSEC rollover KSK and ZSK operations.

The following tasks can be performed during an upgrade:

  • Upgrade a specific member during the scheduled Grid upgrade. For information about how to upgrade a single member during a scheduled Grid upgrade, see Upgrading a Single Member Immediately.
  • Revert a single member that has already been upgraded to troubleshoot issues, such as service outages, on that specific member. The upgrade of that member can then be rescheduled. For more information, see Reverting a Single Member.
  • Clear authentication cache and authentication records.
  • Perform AD (Active Directory) configurations. Note that the keytab file must be uploaded before the upgrade starts.

Note the below restrictions when scheduling a full upgrade:

  • Any action that requires a service restart for configuration changes to take effect are not recommended and can result in upgrade issues.
  • Do not add, modify, or delete an NS group.
  • Do not add, modify, or delete manually created NS records.
  • Do not add, modify, or delete a zone.
  • Do not assign or unassign an NS group to a zone.
  • Do not change the NS group assigned to a zone.
  • Do not change the host name of the Grid members that are assigned to a zone if the members have not been upgraded, have been reverted, or are in the revert time window.
  • Do not restart DNS and DHCP services or schedule a restart for these services on Grid members that have not been upgraded. For more information, see Restarting Groups.
  • Do not add, delete, or modify a DHCP range, filter, or fixed address.
  • Do not modify the settings for automated mitigation of phantom domain attacks using the CLI commands on a Grid member until the member has completed the upgrade.
  • During a staged upgrade, if the NIOS source version to be upgraded from is earlier than 8.5.3, RabbitMQ will continue to use the unsecure mode until the RabbitMQ password is toggled through the CLI after the Grid is completely upgraded to make it secure. If you run the set update_rabbitmq_password command on Grid Master, once ND members rejoin the Grid, RabbitMQ fails to establish connection with the ND members. Perform a product restart on the ND members for the RabbitMQ changes to be reflected.

The Grid Master and Upgrade Groups can be scheduled to upgrade at different times in order to limit service impact. However, upgrades needs to be performed within a limited window of time (i.e. within a couple of days). If an upgrade spans nine or more days, a warning is displayed in the NIOS UI.

NIOS does contain checks and rules to ensure data integrity that can cause undesirable results during the upgrade process. However, when scheduling a full upgrade, the following rules and behavior has to be noted and followed to ensure a seamless upgrade:

  • Do not modify member properties for the following: DNS, DHCP, TFTP/HTTP/FTP, bloxTools, Captive Portal, Reporting, and load balancing until the member has completed the upgrade and exited its revert time window.
  • Do not delete DNS views until the entire Grid upgrade is complete.
  • Do not delete DNS zones and IPv4 and IPv6 networks that are under Microsoft Management until the managing member of the Microsoft servers has completed its upgrade and exited its revert time window. 
  • Synchronization between load balancers and the appliance is disabled until the load balancer managing member has completed its upgrade. Do not change the managing member during the upgrade.

  • Do not add, modify, or delete network views, rulesets, and DNS64 synthesis groups until the entire Grid upgrade is complete.
  • Replication of Grid and member DNS and DHCP properties is not supported.
  • Do not create additional named Access Control Lists (ACLs) until after the entire Grid has been upgraded. For information about named ACLs, see Configuring Access Control.

During a scheduled full upgrade, the Grid Master skips Grid members that do not complete their NIOS upgrade within 10 minutes, the default upgrade policy time, and moves to the next Grid member within the upgrade schedule.

During a scheduled full upgrade, do not perform the following tasks on a Grid member that has not been upgraded yet:

  • Import the DHCP lease history file
  • Use the DHCP expert mode configuration feature
  • Clear the NAC authentication cache of a DHCP member
  • Set the time zone for a Grid member
  • View the capacity report of a Grid member
  • Test the email configuration settings of a Grid member
  • Check whether an IPv6 address is already configured on a Grid member

When scheduling a full upgrade from a previous NIOS release to a release that includes the DHCP fingerprint detection feature, the following rules apply until the entire Grid has been upgraded:

  • DHCP fingerprint detection is disabled
  • Do not add DHCP fingerprint filters
  • Do not apply DHCP fingerprint filters to any DHCP address range

When scheduling a full upgrade from a previous NIOS release to a release that includes the multi-primary zone feature, the following rules apply until the entire Grid has been upgraded:

  • Do not configure multiple primary servers for an authoritative zone or configure a name server group that contains multiple primary servers.
  • Do not assign or unassign a Grid member to an authoritative zone or name server group.
  • Do not change the stealth state of an authoritative zone or name server group.

When scheduling a full upgrade from a previous NIOS release to a release that includes the Infoblox Threat Protection feature, do not perform the following on a Grid member until the member has completed the upgrade:

  • Start or stop the Threat Protection and DNS services.
  • Activate a ruleset.
  • Perform any threat protection related tasks such as adding custom rules and activating rulesets.

Before scheduling a full upgrade from a previous NIOS release to a release that supports IPv6, the following rules apply:

  • If the Grid has an HA Master or HA member and if it is configured with IPv6 VIP address, IPv6 addresses must be configured for both node 1 and node 2.
  • Both the Grid Master and the Grid Master Candidate must have the same type of network connectivity.
  • The current configuration and database must be backed up.
  • If the subscriber site has HA and the HA passive node is the first to upgrade, the data repository connectivity uses the IPv4 protocol for the site members. If you want the data repository to be connected over the IPv6 protocol, you must stop and restart the subscriber service in the upgraded Grid. You may lose subscriber cache data after stopping and restarting the subscriber service. Therefore, perform the stop and restart one one member at a time.

When scheduling a full upgrade from a previous NIOS release to a release that includes the Secure Dynamic Updates feature, the following rules apply until the Grid has completed the upgrade:

  • All dynamic updated records are labelled as static records. Infoblox suggests to enable this feature only after all records are changed to Dynamic.
  • NIOS tags the RRsets that are not auto-generated as static records. For information about Secure Dynamic Updates, see Secure Dynamic Updates.

When scheduling a full upgrade that includes the DNS Traffic Control feature, the following rules apply until the entire Grid has been upgraded:

  • Do not add an SNMP health monitor.
  • Do not configure the All available load balancing method for a DTC pool.
  • The record types are reset to default record types (A and AAAA records) and do not modify the record types for an LBDN.

Upgrading Parental Control at DNS Cache Acceleration

Upgrading Infoblox subscriber services parental control at DNS Cache Acceleration using cached domain and subscriber data has the following restrictions:

  • Upgrade subscriber services using a staged upgrade. This does not affect subscriber data.
  • You must update parental control category data download credentials after the upgrade.
  • During a staged upgrade, you cannot apply the latest ruleset. Therefore, if all the subscriber site members are dual-mode and the threat protection service is running, then replication of subscriber data takes place only if the Collect on the MGMT interface only checkbox is selected. For more information, see Infoblox Subscriber Services.
  • During a staged upgrade to NIOS 8.5.5, you cannot add, update, or delete the following subscriber site attributes: policy management addresses, content proxy addresses, NAS gateways.

  • When you upgrade, designate a few members per site to run garbage collection as subscriber services does not perform garbage collection.
  • Any domain that categorizes as 0 is considered “fail open” irrespective of whether the database is running or expired. Unknown or dummy domains fail even if Proxy-All is set. “Fail open”means getting a regular response and allowed on the Internet.

  • Restrictions when upgrading subscriber sites:
    • You cannot add or remove members from a site during an upgrade.
    • You cannot stop or start a subscriber secure service during an upgrade.
    • You cannot change any subscriber service configuration during an upgrade.

Microsoft Management Rules

On a member that synchronizes data with Microsoft DNS and DHCP servers, the following functions are deactivated during an upgrade:

  • Synchronization of Microsoft DNS and DHCP data
  • Rotation of Microsoft logs
  • Start and stop of Microsoft servers
  • Releases of DHCP leases from a Microsoft DHCP server

Note

The deactivation of these functions does not affect any data on the Microsoft servers. After the upgrade, the member automatically restarts the synchronization of Microsoft data.

On a member that synchronizes data with Microsoft DNS and DHCP servers, the following rules apply:

  • Do not modify the managing member if the old and new members have not been upgraded and have not exited their revert time windows.
  • Do not add, modify, or delete zones, IPv4 DHCP ranges, and IPv4 networks until the managing member has been upgraded and exits the revert time window.
  • Do not add, modify, or delete DNS resource records if the associated zone is managed by a Microsoft server and the managing member is still in its revert time window.
  • Do not add, modify, or delete fixed addresses that are assigned to a Microsoft server and the managing member is still in its revert time window.
  • Wait until the new managing member is upgraded to configure it as a DNS primary or secondary.

DHCP Expert Mode Upgrade

Enabling DHCP expert mode allows administrators to directly manipulate sections of the DHCP configuration file. In this mode, all built-in protections and error checking normally provided by Infoblox are bypassed.  

Because these protections are removed, Infoblox is unable to provide support for DHCP while in the DHCP expert mode except to confirm that administrator changes to the configuration file were written.  The integrity of the configuration file when the DHCP expert mode is enabled is entirely the responsibility of the administrator. If Infoblox support for DHCP is required, first disable the DHCP expert mode and then reproduce the issue.

Infoblox strongly discourages the use of DHCP expert mode. Consider using it only after discussing the situation with Infoblox Support.