- 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 Resolver with its adaptation on each target. A dash means this row is not stated for that target.Infrastructure-only adaptation
On Google Cloud
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 Azure
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 OCI
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.
DNS controls
This mapping does not provide an OCI resolver DNS Firewall equivalent. Review domain filtering separately. Network Firewall URL rules inspect different traffic, and forwarding an unwanted domain to an unresponsive server produces a timeout; neither should be described as the same allow, block and alert behavior as AWS DNS Firewall. AWS-managed domain lists also require a replacement policy. 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
Resolver query logging uses OCI Logging. Configure the log destination, access and retention, then update searches and alerts for the OCI fields. Existing AWS log history stays in its original destination unless separately exported. Update on-premises conditional forwarders to the listening address. Test private views, forwarded domains, network failures and log collection before cutover. Resolver configuration is recreated; caches are not copied. External consumers of AWS endpoint IDs or rule ARNs need corresponding target configuration.On Private Kubernetes
How it works
The Private Kubernetes mapping uses CoreDNS in the appliance 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.