Supported environments
API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.
How the targets compare
Each row compares a capability of Route 53 Resolver with its adaptation on each target. A dash means this profile does not state the capability for that target.Cloud Adapter
On Akamai, DigitalOcean, and Private Kubernetes
Cloudflare DNS
How it works
The Private Kubernetes mapping uses CoreDNS in the Cloud Adapter deployment cluster for private and hybrid queries. Cloudflare authoritative DNS serves public zones, while Cloudflare Gateway filters DNS traffic that is routed through it. These services handle different query paths.Private names and conditional forwarding
CoreDNS answers the cluster’s local names and sends configured private domains to their DNS servers through theforward plugin. A source FORWARD rule supplies the domain, target IPs and ports. Configuration applies to workloads using that CoreDNS service.
On-premises clients need a reachable, access-controlled cluster DNS listening address. The customer must provide the network path in both directions. A standard internal Kubernetes DNS service is not automatically an inbound endpoint for another network. Cloudflare public authoritative DNS does not answer private queries in this arrangement.
The arrows show the direction of the DNS query.
DNS filtering
Custom DNS Firewall lists map to Gateway DNS policies with block or allow actions. Configure the query path through Gateway for those policies to apply. Queries answered locally or sent directly to an on-premises server do not pass through Gateway merely because the policy exists. Use query logging and alert rules for the source alert-only requirement. AWS-managed lists need an explicitly selected replacement. Gateway DNS filtering is separate from Cloudflare’s authoritative DNS Firewall product.DNSSEC and logs
Route 53 Resolver checks DNSSEC signatures on answers it receives. Signing a hosted zone adds signatures to that zone’s records; it does not enable recursive validation for the client network. This mapping does not translate the Resolver DNSSEC-validation setting. Public-zone analytics and Logpush report queries received by Cloudflare authoritative DNS. CoreDNS logs report private queries answered or forwarded by the cluster. Gateway activity logs cover traffic inspected by Gateway. Configure collection for the paths you use; public-zone analytics cannot substitute for private-query logs.Cutover and operations
The customer operates CoreDNS availability, capacity and network access within the cluster. Cloudflare operates its public DNS and Gateway services. Retain DNS access during a cluster change and test forwarded domains before moving on-premises clients to the new listening address. Recreate configuration and update external AWS endpoint IDs and rule ARNs. Resolver caches and existing query history are not transferred. Confirm private, public and filtered queries independently, including which log stream records each one. Provider references: Gateway DNS filtering and Gateway activity logs.On Azure
Azure DNS
How it works
Tensor9 translates Route 53 Resolver endpoints and rules into Azure Private DNS Resolver resources on the customer’s virtual network. An inbound endpoint accepts private-name queries from connected networks. An outbound endpoint and forwarding ruleset send matching queries to configured DNS servers. Azure operates the resolver.Endpoint placement
Each endpoint requires its own subnet delegated toMicrosoft.Network/dnsResolvers. The inbound endpoint has a private IP allocated from its subnet; a supported static-address request can select that address. Update on-premises conditional forwarders to use the new inbound IP.
The outbound endpoint is associated with a subnet but is not provisioned with an IP address like the inbound endpoint. A forwarding ruleset attaches to it. Azure manages service resilience; AWS per-zone interface placement does not translate into a matching set of Azure interfaces. Review target subnet access controls separately from the AWS endpoint security group.
The arrows show the direction of the DNS query.
Conditional forwarding
AFORWARD rule becomes a ruleset entry with the source domain_name and target_dns_servers. Each target keeps its IP and port, including a non-53 port. The ruleset’s virtual-network link activates forwarding for that VNet.
Multiple domains can have separate rules. Enabling or disabling a rule changes whether it forwards; removing a VNet link changes where the entire ruleset applies. Check that the selected network can reach every target DNS server.
DNS filtering and validation
DNS Firewall domain rules map to an Azure DNS resolver policy with domain lists and traffic rules. Allow, Block and Alert actions apply to queries from linked virtual networks. Custom lists transfer; AWS-managed lists require an explicitly chosen replacement. Microsoft threat intelligence is a different list, even when it serves the same security purpose. Route 53 Resolver checks DNSSEC signatures on answers it receives. Signing a hosted zone adds signatures to that zone’s records; it does not enable recursive validation for the client network. This mapping does not translate the Resolver DNSSEC-validation setting.Logging and cutover
Enable query logging on the DNS resolver policy and send its diagnostic logs to the selected Azure Monitor destination. Those DNS query logs are distinct from resource metrics. Update log queries and retention for the Azure format and confirm the policy is linked to each network whose queries must be recorded. Recreate forwarding and filtering configuration, then test private names, forwarded domains and policy actions before changing client DNS settings. Existing query history and resolver caches are not transferred. External AWS endpoint IDs and rule ARNs need target-specific replacements. Provider references: endpoints and rulesets and DNS query logs.On Google Cloud
Cloud DNS
How it works
Tensor9 translates Route 53 Resolver configuration into Cloud DNS policies and forwarding zones on the customer’s Google Cloud network. An inbound-forwarding policy lets on-premises resolvers query private names. A forwarding zone sends queries for a specified domain to the configured on-premises DNS servers. Google serves these queries directly.Inbound access and network placement
The inbound endpoint becomes agoogle_dns_policy with enable_inbound_forwarding. Google allocates the forwarding addresses; update on-premises conditional forwarders to use the addresses reported after deployment. The target network and hybrid connection must provide the required DNS reachability.
The AWS endpoint’s chosen IPs, subnet placement, security group and per-availability-zone network interfaces do not become corresponding Cloud DNS endpoint resources. Configure the target network’s access controls and redundancy for its actual forwarding path.
The arrows show the direction of the DNS query.
Conditional forwarding
An outbound endpoint and itsFORWARD rule become a forwarding managed zone. The rule’s domain becomes dns_name; target IPs become forwarding_config.target_name_servers, with the private forwarding path. The rule association becomes the zone’s network attachment.
Cloud DNS manages outbound forwarding without an endpoint IP that you can select. It forwards to port 53. A non-53 target port cannot be preserved and is reported for correction; changing only the destination IP would not make that rule equivalent.
DNS filtering and validation
Custom DNS Firewall domain lists map to Cloud DNS response-policy rules on the network. An allow rule uses bypass behavior. Blocking uses a configured local response, which differs from AWS DNS Firewall’s response options; do not assume an identical NXDOMAIN response. Response policies match DNS names and do not reproduce the full ordered AWS rule-group model. Query logging provides the record needed for alert-only behavior. Review which queries are logged and how alerts are selected. AWS-managed domain lists need replacement lists; a native Google list is not assumed to contain the same domains. Route 53 Resolver checks DNSSEC signatures on answers it receives. Signing a hosted zone adds signatures to that zone’s records; it does not enable recursive validation for the client network. This mapping does not translate the Resolver DNSSEC-validation setting.Logging and cutover
The network DNS policy enables query logging to Cloud Logging. Update collection, retention and queries for the Google log format. Existing AWS query history remains in its original destination unless separately exported. Before switching clients, test inbound private names and outbound forwarded names, including network failures and blocked domains. Replace external references to AWS endpoint IDs or rule ARNs that have no target equivalent. Forwarding configuration is recreated; cached answers and query history are not copied. Provider reference: Cloud DNS response policies.On OCI
OCI DNS
How it works
Tensor9 translates the Route 53 Resolver configuration into listening endpoints, forwarding endpoints and rules on the customer’s OCI VCN resolver. Listening endpoints receive queries for private names; forwarding endpoints send domain-matched queries to the configured DNS servers. Oracle operates the resolver.Endpoints and private names
An endpoint uses a virtual network interface in a supplied subnet. The listening address is the destination for on-premises conditional forwarders. Private views attached to the VCN resolver determine the private zones it can answer. OCI governs endpoint placement. AWS per-availability-zone IP assignments do not produce an identical set of target interfaces. Configure subnet access and any OCI network security group for the listening and forwarding traffic; the presence of an AWS endpoint security group does not by itself enforce the same policy on OCI.
The arrows show the direction of the DNS query.
Conditional forwarding
AFORWARD rule becomes an OCI resolver rule: qname_cover_conditions identifies the domain, destination_addresses lists target servers, and source_endpoint_name selects the forwarding endpoint. Adding the rule to the VCN resolver makes it apply to that resolver; there is no separate AWS-style rule-association resource.
Target IPs and the domain are retained. Forwarding uses port 53; OCI has no per-destination port setting in this mapping. A rule requiring another port needs a different arrangement and is reported for correction.