- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Azure
- On OCI
- On Private Kubernetes
- Service level agreements
- Debug this service
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.
Routing and remaining limits
Route 53 routing policies are omitted and reported while ordinary record data can still be applied. Cloudflare Load Balancing provides separate traffic-routing features; this DNS record mapping does not configure them. Health checks, delegation sets, private zones and Resolver resources are outside this mapping. It uses Cloudflare public authoritative zones; Cloudflare private-DNS products are not selected by this option. Subdomain zone setup has its own Cloudflare plan requirements and is distinct from 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.Service level agreements
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.Route53 to Route 53 (any cloud)
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to aws::1.0.0::route53. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.How the latency targets were chosen
DNS management reads: 8 ms monthly p99.GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution.
Bounded zone and record mutation: 20 ms monthly p99. ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.Example and diagnosis
ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Route53 to Azure DNS
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to azure::1.0.0::dns. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.How the latency targets were chosen
DNS management reads: 8 ms monthly p99.GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution.
Bounded zone and record mutation: 20 ms monthly p99. ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.Example and diagnosis
ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Route53 to Cloudflare DNS
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to cloudflare::1.0.0::dns. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.How the latency targets were chosen
DNS management reads: 8 ms monthly p99.GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution.
Bounded zone and record mutation: 20 ms monthly p99. ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.Example and diagnosis
ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Route53 to Cloud DNS
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to google::1.0.0::dns. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.How the latency targets were chosen
DNS management reads: 8 ms monthly p99.GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution.
Bounded zone and record mutation: 20 ms monthly p99. ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.Example and diagnosis
ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
Route53 to OCI DNS
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to oci::1.0.0::dns. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.How the latency targets were chosen
DNS management reads: 8 ms monthly p99.GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution.
Bounded zone and record mutation: 20 ms monthly p99. ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.Example and diagnosis
ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Usetensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.