- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Azure
- On OCI
- On Private Kubernetes
Coverage by target cloud
How the targets compare
Each row compares a capability of Route 53 with its adaptation on each target. A dash means this row is not stated for that target.Max adaptation
Infrastructure-only adaptation
On Google Cloud
How it works
Tensor9 translates Route 53 zones and records into Cloud DNS managed zones and record sets in the customer’s Google Cloud project. Google’s authoritative servers answer DNS queries. Applications use the Route 53 API through the adapter for supported runtime zone and record changes.
Record changes use the adapter; DNS queries go to the authoritative provider.
Zones and records
With Infrastructure-only adaptation, a declared zone becomes a managed zone; an explicit lookup uses an existing Cloud DNS managed-zone name, which can differ from the DNS domain. The infrastructure mapping supports private zones attached to the target VPC network. The runtime adapter manages its own public zones and reports Google-assigned authority and nameservers. Looking up an existing zone does not transfer its ownership to the adapter. Do not have another controller write the same zone; a missing or replaced previously observed zone requires explicit repair. The Max runtime supports A, AAAA, CAA, CNAME, DS, HTTPS, MX, NAPTR, NS, PTR, SOA, SPF, SRV, SSHFP, SVCB, TLSA and TXT, retaining all values in an ordinary record set. Publishing DNSSEC-related records does not configure signing or key management. Infrastructure-only adaptation converts deprecatedSPF declarations to TXT and defaults an unset TTL to 300 seconds.
Aliases and routing
An infrastructure alias follows a referenced resource to its target-cloud address. Cloud DNS also offers an apex ALIAS type for public zones, but that native capability is separate from resolving a resource reference during deployment. Route 53 target-health evaluation is not retained. RuntimeAliasTarget requests are unsupported.
Weighted, latency, failover, geolocation and related Route 53 routing policies are outside this mapping. Deployment can retain a record’s name, type and values while reporting the omitted policy. Cloud DNS has native routing policies, but the presence of a native feature does not configure the requested AWS behavior. Ordinary multiple-value records do not reproduce health-checked or weighted routing.
Runtime changes
Your application sends Route 53 API requests to the configured adapter. The adapter records the requested change and applies it with the provider credential it holds.ChangeResourceRecordSets returns a change receipt; GetChange reports PENDING until target application completes, then INSYNC.
Here, INSYNC reports target application. It does not guarantee that every authoritative server has observed the change or that recursive caches have expired. Keep polling for completion and allow for DNS caching during cutover.
Google applies a native Changes batch atomically. The adapter still observes target completion before finishing a receipt. Public-zone lifecycle, authority readback and record changes use the same managed zone; private-zone infrastructure support does not imply the same runtime lifecycle for private zones.
Remaining limits
Standalone Route 53 health checks are omitted and reported by the Cloud DNS infrastructure mapping. Delegation sets and Resolver resources are outside the zones-and-records mapping. The separate Resolver page describes hybrid DNS. Confirm network DNS access for a private zone and update external consumers of AWS zone IDs or nameservers. A new public zone requires delegation to its Google nameservers. Runtime reconciliation requires the native record inventory and change history to fit in one response each; it refuses paged native results. This limit is separate from pagination of the Route 53 record-list API. Keep Google’s assigned apex nameservers. Supported apex TTL and SOA updates do not permit reassignment of those nameservers or standalone deletion of apex authority records. DS records at the zone apex and SOA records below it are refused. Remove ordinary records before deleting the zone.Cutover and operations
Apply the required records, verify authoritative answers, and then update public nameserver delegation where the provider changes. Keep the previous zone available while cached records and delegation expire. This process applies declared records; it does not copy an entire existing zone or its query history. Record changes require the appliance and its provider credentials. Once applied, records remain available from the authoritative provider while the appliance is unavailable. Certificate-validation records are coordinated with certificate management; review external DNS controllers and any credentials they previously used.On Azure
How it works
Tensor9 applies Route 53 records to Azure DNS in the customer’s subscription and resource group. Azure serves authoritative queries. The adapter also provides the Route 53 public-zone lifecycle and record-change API, with Azure-assigned authority returned to the application.
Record changes use the adapter; DNS queries go to the authoritative provider.
Zones and record ownership
A deployment-time zone lookup requires an existing Azure DNS zone; it does not transfer that zone to runtime ownership. The runtime adapter can create and delete the public zone it manages; its subscription and resource group must already exist. Do not share write ownership of that zone with another controller. An unrelated zone with the same name is not automatically adopted. Two logical zones with the same DNS name need separate Azure placement. The runtime target supportsA, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV and TXT. It retains Azure-assigned apex nameservers and the SOA primary. Other supported SOA fields and authority TTLs can change. Standalone deletion of apex authority records is refused; remove ordinary records before deleting the hosted zone. Record types outside the selected API, private zones and native aliases remain outside this runtime contract.
Aliases and routing
Azure native aliases target supported Azure resources; they do not provide an arbitrary-hostname alias at a zone apex. This mapping does not reproduce Route 53 aliases or their target-health evaluation. A resolved infrastructure address can instead be an ordinary address record; that does not preserve ongoing alias behavior. Route 53 routing policies are outside this mapping. Deployment may retain ordinary record values while reporting the omitted policy. Traffic Manager provides separate Azure traffic-routing features and must be configured explicitly when that behavior is required. Multiple values alone do not reproduce a weighted or health-checked answer.Runtime changes
Your application sends Route 53 API requests to the configured adapter. The adapter records the requested change and applies it with the provider credential it holds.ChangeResourceRecordSets returns a change receipt; GetChange reports PENDING until target application completes, then INSYNC.
Here, INSYNC reports target application. It does not guarantee that every authoritative server has observed the change or that recursive caches have expired. Keep polling for completion and allow for DNS caching during cutover.
The requested change batch is recorded together, but Azure applies individual record sets separately. Intermediate answers can therefore contain part of a multi-record change. Conditional writes detect changes made by another writer. Plan related record changes so that this transition is acceptable.
Remaining limits
Health-check resources, delegation sets and Resolver resources are outside this zone-and-record mapping. Azure Private DNS is a separate target service; this public-zone lifecycle does not create a private zone. The runtime API rejects unsupported DNS types rather than changing their meaning. An infrastructureSPF-to-TXT conversion does not imply runtime SPF support.
Native record inventory must fit in one response. The adapter refuses incomplete inventory before destructive reconciliation. Runtime record names use bounded ASCII DNS labels; escaped or binary labels and non-UTF-8 TXT/CAA data are unsupported.
If a previously observed zone disappears, repair its association explicitly; the adapter does not automatically allocate new authority. Ownership markers help detect unrelated zones and records, but another writer can copy those markers. Keep write ownership exclusive to the adapter.
Cutover and operations
Apply the required records, verify authoritative answers, and then update public nameserver delegation where the provider changes. Keep the previous zone available while cached records and delegation expire. This process applies declared records; it does not copy an entire existing zone or its query history. Record changes require the appliance and its provider credentials. Once applied, records remain available from the authoritative provider while the appliance is unavailable. Certificate-validation records are coordinated with certificate management; review external DNS controllers and any credentials they previously used.On OCI
How it works
Tensor9 applies declared Route 53 records to an existing OCI DNS zone in the customer’s compartment. The appliance holds the OCI credential. OCI authoritative servers answer public DNS queries directly.
Record changes use the adapter; DNS queries go to the authoritative provider.
Zones, records and aliases
The zone is looked up by domain name and must already exist. The documented record types are A, AAAA, CAA, CNAME, DS, MX, NAPTR, NS, PTR, SPF, SRV, SSHFP, TLSA and TXT. All values in an ordinary record set are retained; an unset deployment TTL defaults to 300 seconds. OCI retains the deprecatedSPF type and maintains the zone’s SOA and assigned apex nameservers. HTTPS and SVCB are not included in this documented OCI mapping.
An infrastructure alias resolves a resource reference to its target-cloud address. OCI also offers a native public-zone ALIAS pseudo-type at the apex; that capability is distinct from resolving a deployment reference. Route 53 alias target-health evaluation is omitted. Multiple address values do not by themselves provide health-checked routing.
Runtime changes
Your application sends Route 53 API requests to the configured adapter. The adapter records the requested change and applies it with the provider credential it holds.ChangeResourceRecordSets returns a change receipt; GetChange reports PENDING until target application completes, then INSYNC.
Here, INSYNC reports target application. It does not guarantee that every authoritative server has observed the change or that recursive caches have expired. Keep polling for completion and allow for DNS caching during cutover.
Routing and unsupported resources
The record mapping does not configure OCI traffic-steering policies. Route 53 routing policies are omitted and reported while ordinary record data can still be applied. OCI has separate steering and health-check services, but their existence does not activate a matching AWS policy. A standalone Route 53 health-check resource stops the build for this target. Private zones, delegation sets and Resolver resources are also outside this zones-and-records mapping. OCI private DNS and the separate Resolver mapping have their own configuration; these limits do not mean OCI lacks private DNS.Cutover and operations
Apply the required records, verify authoritative answers, and then update public nameserver delegation where the provider changes. Keep the previous zone available while cached records and delegation expire. This process applies declared records; it does not copy an entire existing zone or its query history. Record changes require the appliance and its provider credentials. Once applied, records remain available from the authoritative provider while the appliance is unavailable. Certificate-validation records are coordinated with certificate management; review external DNS controllers and any credentials they previously used.On Private Kubernetes
Via Route 53 (any cloud)
How it works
Your workload can run in the customer’s Kubernetes environment while its public DNS zone remains in Route 53. Tensor9 applies declared records through the Route 53 API using an AWS credential supplied to the appliance. AWS continues serving the zone; nameserver delegation can remain unchanged.
Record changes use the adapter; DNS queries go to the authoritative provider.
Zone and record configuration
The hosted zone must already exist. The mapping resolves it by domain name, using an explicitly specified zone before the zone reference or deployment default domain. It writes the declared records into that zone; it does not create or copy the entire zone. Standard record types, including nativeSPF, and all values in an ordinary record set are retained. An unset deployment TTL defaults to 300 seconds. An infrastructure alias follows its referenced resource to the target-cloud address, but target-health evaluation is omitted.
Runtime changes
Your application sends Route 53 API requests to the configured adapter. The adapter records the requested change and applies it with the provider credential it holds.ChangeResourceRecordSets returns a change receipt; GetChange reports PENDING until target application completes, then INSYNC.
Here, INSYNC reports target application. It does not guarantee that every authoritative server has observed the change or that recursive caches have expired. Keep polling for completion and allow for DNS caching during cutover.
Limits of the record mapping
Keeping Route 53 as the provider does not preserve every Route 53 configuration feature. This mapping applies ordinary records and omits source traffic-routing policies with a reported warning. Multiple address values do not reproduce weighted, latency, failover or health-checked routing. Health-check resources, delegation sets and Resolver resources stop the build in this mapping. Private-zone lookup is also outside its contract: a domain-only lookup cannot safely distinguish public and private zones with the same name. These are mapping limits, not restrictions of Route 53 itself.Operations
Scope the appliance’s AWS credential to the intended zone and protect its renewal process. Application calls use the configured adapter endpoint; the application does not need the provider credential held by the appliance. Check records against the new workload addresses before cutover. AWS can continue answering applied records while the appliance is unavailable, but further changes require the appliance and working credentials. Preserve external controllers and certificate-validation behavior only where they remain compatible with the selected record ownership.Via Cloudflare DNS
How it works
Tensor9 applies declared Route 53 records to an existing Cloudflare zone. The appliance holds the Cloudflare credential and handles supported application record-change requests. Cloudflare’s authoritative DNS servers answer public queries.
Record changes use the adapter; DNS queries go to the authoritative provider.
Zones and records
Onboard the domain to Cloudflare and create the zone before deployment. The mapping looks it up by domain name. Standard record types and all values in an ordinary record set are retained; an unset deployment TTL defaults to 300 seconds. DeprecatedSPF declarations become TXT.
An infrastructure alias follows the referenced resource to its target-cloud address. Cloudflare CNAME flattening provides native apex-hostname resolution. Route 53 alias target-health evaluation is omitted, and ordinary multiple-value answers do not reproduce health-checked routing.
DNS-only and proxied records
Records are DNS-only by default. A Cloudflare proxied record sends supported application traffic through its edge, where the configured CDN, WAF and DDoS features apply. Enabling that proxy and choosing its protections are separate Cloudflare settings; creating an ordinary DNS record does not enable them.Runtime changes
Your application sends Route 53 API requests to the configured adapter. The adapter records the requested change and applies it with the provider credential it holds.ChangeResourceRecordSets returns a change receipt; GetChange reports PENDING until target application completes, then INSYNC.
Here, INSYNC reports target application. It does not guarantee that every authoritative server has observed the change or that recursive caches have expired. Keep polling for completion and allow for DNS caching during cutover.
A successful Cloudflare API write can complete without an asynchronous native change operation. That does not bypass DNS cache lifetimes or prove worldwide propagation.