---
title: "Best Practices, Limitations, and Known Issues of Infoblox Amazon Route 53 Integration"
canonical: "https://docs.infoblox.com/space/NAIG/37748947/Best%20Practices%2C%20Limitations%2C%20and%20Known%20Issues%20of%20Infoblox%20Amazon%20Route%2053%20Integration"
format: markdown
---
Some of the best practices you could use when using the Amazon Route 53 integration feature and the limitations and known issues of this feature are discussed in this topic.

## Best Practices

- Ensure that the time on the NIOS or vNIOS appliance is synchronized with the actual time so that AWS Route 53 synchronization functions properly.
- Depending on the number of hosted zones and resource records, the synchronization of Route 53 data could consume a significant amount of memory and database capacity.
  - When you configure the Grid member to pull the Amazon Route 53 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 hosted zones that you want to import into the NIOS database when you configure sync tasks. For information about how to configure sync tasks, see [Managing Amazon Route 53 Sync Groups](https://infoblox-docs.atlassian.net/wiki/spaces/NAIG/pages/37618426).
- Ensure that NIOS is able to reach the AWS endpoints. If the endpoints are not reachable, Amazon Route 53 DNS sync tasks will remain in an in-progress state for a long time and then time out.
- 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 *[Prerequisites for Amazon Route 53 Integration](https://infoblox-docs.atlassian.net/wiki/spaces/NAIG/pages/277546012)* topic.
- Amazon supports multiple values for a resource record set. After data synchronization, NIOS creates multiple records (one for each value that is specified in Route 53).

## Limitations

- NIOS does not support the use of special characters \ or " in the name of a Route 53 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 Route 53, the changes will be overwritten in subsequent synchronization. However, DNS records that are manually created in zones synchronized from Route 53 are not removed in subsequent synchronization.
- NIOS does not synchronize Route 53 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.
- Amazon Route 53 zones and records cannot be synchronized to NIOS database when a zone is signed, because signing a zone encrypts the records.
- NIOS does not import SOA records for Route 53 hosted zones. When you configure a primary and secondary name servers to serve Route 53 hosted zones, NIOS creates the NS records and use the default SOA records for these zones.
- SPF records from Route 53 are stored as TXT records in NIOS.
- To use the Route 53 integration feature on a vNIOS instance deployed with the NIOS 8.6.3 resizable image, you must ensure that the vNIOS instance is allocated with a minimum disk size of 500 GB or more. If not, the Cloud DNS Sync service will not work properly.
- Querying a CNAME ALIAS record synchronized through Amazon Route 53 returns the TTL value defined in the Grid DNS Properties instead of the value defined in its parent CNAME record.
- NIOS does not support the following Route 53 data:
  - Duplicate records (or records using the same name and same record type) in a hosted zone using "non-simple" routing policies
  - Duplicate Route 53 public hosted zones
  - "Tags" in Route 53 (similar to extensible attributes in NIOS)
- Creation of a Route 53 record with the special character **\** in its name, is not allowed.
- Route 53 Sync tasks that have executed successfully with a prior version of NIOS, may end with a warning state after an upgrade to NIOS 8.6.3 or 9.0.1.
- The Amazon Route 53 service does not support public or private IPv6 endpoints. Therefore, it is not possible to synchronize the Route 53 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.
- In NIOS, if you manually add a subzone to a zone that is synchronized from AWS Route 53, subsequent Route 53 synchronization may result in unexpected errors because, by default, NIOS moves all records of a parent zone to its subzone and the records are no longer available under the zone. Infoblox recommends that you do not manually add subzones in the DNS view that is set up for Route 53 Synchronization.

For other limitations related to vNIOS for AWS, see *[Limitations](https://infoblox-docs.atlassian.net/wiki/spaces/NAIG/pages/37585115)*.

## Known Issues

- NIOS does not support CAA alias records from Amazon Route 53.
- SPF ALIAS records synchronized to NIOS through Amazon Route 53 cannot be queried because NIOS does not support the SPF record type.
- The **Route 53** tab that shows the data retrieved from AWS, is not available in the editor window of the synchronized CAA and NAPTR records.
- 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 AWS for a Route 53 job, is currently not supported.
- In a 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-account Route 53 synchronization may cause a high CPU usage for some duration when synchronizing data from large number of accounts. The usage drops to normal levels 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 the AWS cloud.
- If you have configured a rotation of your credentials or access keys, some of the Route 53 synchronization tasks may fail with the error “Code:404 Message”.
- 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 **Account ID** column in the zones table (**Data Management** tab > **DNS** > Zones > *DNS_view*) in NIOS 8.6.3 does not support sorting of data in ascending or descending order.
- The Global Search function in Infoblox NIOS Grid Manager does not support filtering of data by using the AWS Account ID filter. You may use the **Quick Filter** option in 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.**