---
title: "Best Practices, Limitations, and Known Issues of Google Cloud DNS Integration"
canonical: "https://docs.infoblox.com/space/vniosgcp/843481241/Best%20Practices%2C%20Limitations%2C%20and%20Known%20Issues%20of%20Google%20Cloud%20DNS%20Integration"
format: markdown
---
Some of the best practices that you can employ when using the Google Cloud DNS integration feature introduced in NIOS 9.0.5, the limitations, and the known issues of this feature are discussed in this topic.

## Best Practices

- Ensure that the time on the NIOS appliance is synchronized with the actual time so that the synchronization of DNS data functions properly.
- Depending on the number of zones and resource records, the synchronization of DNS data could consume a significant amount of memory and database capacity.
  - When you configure a Grid member to retrieve the DNS data, ensure that the Grid member has sufficient capacity to handle a bulk import of DNS data.
  - Infoblox suggests that you select a member that is not running other services and can handle the synchronization load for this feature.
- To reduce unnecessary data synchronization and to ensure optimal performance in your Grid, use filters to specify the managed zones that you want to import into the NIOS database when you configure sync tasks. For information about how to configure sync tasks, see the *[Managing Google Cloud DNS Sync Groups](https://infoblox-docs.atlassian.net/wiki/spaces/vniosgcp/pages/844300348)* topic.
- If you install a hotfix for the Cloud Sync service, you must manually stop the service and restart it for the hotfix to take effect. For steps, see the list of *[prerequisites](https://infoblox-docs.atlassian.net/wiki/spaces/vniosgcp/pages/844562479)*.
- Multiple values are supported for a resource record set. After the synchronization of DNS data, NIOS creates multiple records (one for each value that is specified in cloud).

## Limitations

- NIOS does not support the use of special characters \ or " in the name of a DNS sync task. A DNS sync task will fail if you use any of the unsupported characters in its name.
- In NIOS, if you modify DNS records synchronized from Google Cloud DNS, the changes will be overwritten in subsequent synchronization. However, DNS records that are manually created in zones synchronized from Google Cloud DNS are not removed in subsequent synchronization.
- NIOS does not synchronize the DNS data to a network view whose authority is delegated to another Grid member. When you configure a sync group, ensure that you select a network view that is not delegated.
- Managed zones and records cannot be synchronized to the NIOS database when a zone is signed because signing a zone encrypts the records.
- NIOS does not import SOA records for DNS zones. When you configure name servers to serve the DNS zones, NIOS creates the NS records and use the default SOA records for these zones.
- To use the Google Cloud DNS integration feature on a vNIOS instance deployed with the NIOS 9.0.5** **resizable image, you must ensure that the vNIOS instance is allocated with a minimum disk size of 250 GB or more. If not, the Cloud Sync service will not work properly.
- When running a scheduled upgrade from NIOS 8.6.x to 9.0.5 on a Grid that has members assigned to Google Cloud DNS sync groups, the Cloud Sync service on such members keeps restarting as the RabbitMQ password will not yet be updated. To update the password, wait for the upgrade to complete, and then run the `set update_rabbitmq_password` command on the Grid Master in the maintenance window.
- NIOS does not support synchronization of ALIAS records from Google Cloud DNS.
- NIOS does not support the following Google Cloud DNS data:
  - Duplicate records such as records using the same name, same record type, and same routing data in a zone using "non-simple" routing policies.
  - Duplicate public zones.
  - "Tags" in DNS resources (similar to extensible attributes in NIOS).
- NIOS does not support synchronization of DNS data to IPv6 NIOS Grids.
- For NS records synchronized through DNS synchronization, values are not populated in extensible attributes related columns such as Creation Time and Cloud Shared in the **Data Management** > **DNS** > **Zones** table because NIOS considers NS records as system records and therefore it cannot associate the extensible attribute values with the records.
- The default value of 'API Calls per minute per user' attribute set to 1200 by Google Cloud allows successful synchronization of DNS data for a maximum of 1000 zones of a Google Cloud project to NIOS. If the zone count exceeds 1000, Infoblox recommends that you request Google Cloud to raise the API call limit to ensure seamless operation.

## Known Issues

- The **Allow Deep Packet Inspection** option configured in NIOS for the proxy server to run a deep-packet inspection while fetching the DNS data from Google Cloud for a DNS sync task, is currently not supported.
- In an HA setup, if the Cloud Network Automation license is not installed in any of the two nodes, the HA status will not display a missing license message.
- Multi-project DNS synchronization may cause a high CPU usage for some duration when synchronizing data from large number of projects. The CPU usage returns to the normal level after the CPU-intensive processes are completed.
- If a DNS sync task is synchronizing large amount of data, some data may not synchronize due to the load on the server. Subsequent runs of the same task will eventually ensure that the synchronized data is consistent with the data in Google Cloud.
- If you have configured a rotation of your credentials, some of the DNS synchronization tasks may fail with an error.
- Infoblox recommends that you do not start the Cloud Sync service for an offline member although the **Manage Member Services** option allows you to start the service for an offline member.
- The Global Search function in Infoblox NIOS Grid Manager does not support filtering of data by using the Project ID filter. You may use the **Quick Filter** option on the **Zones** > *DNS_view* screen.
- If the “error:couldn't create memory pool" error is displayed during an vDiscovery job, it means that a restart of services has not been performed by clicking Restart Services on the Toolbar when the Restart Banner is displayed on top of Grid Manger. If a service restart is delayed for any reason, the error will not be resolved even after the restart. To resolve the error, run the set purge_restart_objects **Admin** **CLI command.**