Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

When scheduling a full upgrade in NIOS, the Grid Master replicates the following features 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 and NXDOMAIN rules

  • DNSSEC key pairs

  • DNSSEC import keyset operation

  • Signed and unsigned zones

  • DNSSEC rollover KSK and ZSK operations.

You can perform the following tasks 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” in Upgrading NIOS Software.

  • 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” in Upgrading NIOS Software.

  • 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 a nameserver group.

  • Do not add, modify, or delete manually created nameserver records.

  • Do not add, modify, or delete a zone.

  • Do not assign or unassign an nameserver group to a zone.

  • Do not change the nameserver 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 information about restarting groups, see Restarting Services.

  • Do not add, delete, or modify a DHCP range, a filter, or a 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.

  • Due to new validation checks introduced in BIND 9.16, a few resource records that were invalid RDATA in BIND 9.11 are considered invalid in BIND 9.16. If you add such invalid Resource Records (RR) to a zone, the zone fails to load during an upgrade, or a Grid restore. An error message is displayed when you add invalid Resource Records (RR) or Resource Records (RR) with invalid RDATA under a zone.

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 have 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 includes the IPv6 Grid feature, 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. The subscriber data is lost when the service is stopped and restarted. It is recommended to stop/start the service of each member at a time to synchronize the subscriber cache with the next active member on the same site.

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.

  • When you upgrade, designate a few members per site to run garbage collection as subscriber services does not perform garbage collection.

  • 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

Deactivation of these functions does not affect 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.

  • No labels