- Coverage by target cloud
- How the backends compare
- On Google Cloud
- On Azure
- On OCI
- Debug this service
Coverage by target cloud
How the backends compare
Each row compares a capability of Route 53 Resolver with its adaptation on each backend. A dash means this row is not stated for that backend.Infrastructure-only adaptation
On Google Cloud
How it works
Tensor9 turns your 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 chosen domain to the on-premises DNS servers you name. Google answers these queries directly, and Tensor9 is not in the DNS query path.Inbound access and network placement
The inbound endpoint becomes agoogle_dns_policy with enable_inbound_forwarding on the appliance’s network. Google picks the forwarding addresses. After deployment, point your on-premises conditional forwarders at the addresses Google reports. The network and your hybrid connection must let DNS traffic through.
The AWS endpoint’s chosen IPs, subnets, security group and per-zone network interfaces have no Cloud DNS counterpart. Set up access controls and redundancy on the target network for the path DNS traffic actually takes.
The arrows show the direction of the DNS query.
Conditional forwarding
EachFORWARD rule becomes a private forwarding zone, together with the outbound endpoint it uses. The rule’s domain becomes the zone’s dns_name, its target IPs become forwarding_config.target_name_servers, and the rule association becomes the network the zone is attached to.
Cloud DNS forwards queries itself, with no outbound endpoint IP you can choose. It always forwards to port 53, so a target on another port cannot keep its port. The deployment reports such a rule for you to correct; changing only the target IP would not make it equivalent.
DNS filtering
Tensor9 does not create DNS Firewall rules on Google Cloud. The Cloud DNS counterpart for custom domain lists is response-policy rules on the network. An allow rule uses bypass. A block returns a local answer that you configure, which differs from AWS DNS Firewall’s response options, so do not expect an identical NXDOMAIN. Response policies match DNS names and do not reproduce the ordered AWS rule groups. For alert-only rules, use query logging and choose which queries raise alerts. AWS-managed domain lists need replacement lists; a Google list is not assumed to hold the same domains.Limitations
Where Route 53 Resolver and this target differ- You must set up DNS filtering and query logging yourself. The deployment creates the endpoints and forwarding rules only. Route 53 Resolver DNS Firewall, query logging and DNSSEC resources in your stack do not create anything on Google Cloud.
- DNSSEC validation is not supported. Route 53 Resolver can check DNSSEC signatures on the answers it receives; this mapping does not keep that setting. Signing a hosted zone is a different feature: it signs that zone’s records but does not validate answers for your network.
- Forwarding ports other than 53 are not supported. Cloud DNS has no port setting for forwarding targets. A non-53 port is dropped and the deployment reports it.
- IPv6 forwarding targets are not supported. Cloud DNS forwarding targets are IPv4 only. IPv6 targets are dropped and reported; a rule whose targets are all IPv6 gets a placeholder address you must replace.
- You must give forwarding targets as literal IP addresses. If a rule’s
target_ipis a variable or a reference, the deployment cannot read it. The rule gets a placeholder address and a warning, and you must replace it with the real DNS server before applying. - DNS over HTTPS is not supported. Cloud DNS answers and forwards over standard DNS only. A DoH protocol set on a Route 53 Resolver endpoint or forwarding target is dropped, and the deployment reports it.
Other considerations
Query logging. To record queries, enable logging on the network’s DNS policy, which sends them to Cloud Logging. Update collection, retention and queries for the Google log format. Existing AWS query history stays where it is unless you export it. Before switching clients. Test inbound private names and outbound forwarded names, including network failures and blocked domains. Moving from AWS. Resolver caches and query history are not transferred. Anything outside the stack that refers to AWS endpoint IDs or rule ARNs needs the target’s identifiers instead. Google reference: Cloud DNS response policies.On Azure
How it works
Tensor9 turns your Route 53 Resolver endpoints and forwarding rules into Azure Private DNS Resolver resources on the customer’s virtual network. An inbound endpoint answers private-name queries from connected networks, such as your on-premises resolvers. An outbound endpoint and a forwarding ruleset send queries for chosen domains to the DNS servers you name. Azure operates the resolver, and Tensor9 is not in the DNS query path.Endpoint placement
The endpoints are created in the appliance’s own virtual network, not in your AWS VPC subnets. Azure requires each endpoint to have its own subnet delegated toMicrosoft.Network/dnsResolvers. Azure assigns the inbound endpoint a private IP from its subnet. After deployment, point your on-premises conditional forwarders at that IP.
The outbound endpoint sits in a subnet but has no IP address for clients to call; the forwarding ruleset attaches to it. Azure handles the resolver’s resilience, so the AWS per-zone network interfaces have no matching set of Azure interfaces. The AWS endpoint security group is not kept: review the target subnet’s access controls yourself.
The arrows show the direction of the DNS query.
Conditional forwarding
EachFORWARD rule becomes a rule in the forwarding ruleset, with the same domain_name and target DNS servers (target_dns_servers). Each target keeps its IP and port, including a port other than 53. The ruleset is linked to the virtual network, which turns forwarding on for that network.
Each domain can have its own rule. Disabling a rule stops it forwarding; removing the virtual-network link stops the whole ruleset applying to that network. Check that the network can reach every target DNS server.
DNS filtering
Tensor9 does not create DNS Firewall rules on Azure. The Azure counterpart is a DNS security policy: domain lists and traffic rules whose Allow, Block and Alert actions apply to queries from linked virtual networks. Your custom domain lists can be copied into it. AWS-managed lists have no copy, so choose a replacement explicitly. Microsoft’s threat-intelligence list is a different list, even where it has the same purpose.Limitations
Where Route 53 Resolver and this target differ- You must set up DNS filtering and query logging yourself. The deployment creates the endpoints and forwarding rules only. Route 53 Resolver DNS Firewall, query logging and DNSSEC resources in your stack do not create anything on Azure.
- DNSSEC validation is not supported. Route 53 Resolver can check DNSSEC signatures on the answers it receives; this mapping does not keep that setting. Signing a hosted zone is a different feature: it signs that zone’s records but does not validate answers for your network.
- Static endpoint IPs are not kept. Azure assigns the inbound endpoint’s address from its subnet. IPs you pinned on the AWS endpoint, its subnets and its security group are not kept, and the deployment reports this.
- You must give forwarding targets as literal IP addresses. If a rule’s
target_ipis a variable or a reference, the deployment cannot read it. The rule gets a placeholder address and a warning, and you must replace it with the real DNS server before applying. - DNS over HTTPS is not supported. Azure Private DNS Resolver answers and forwards over standard DNS only. A DoH protocol set on a Route 53 Resolver endpoint or forwarding target is dropped, and the deployment reports it.
Other considerations
Query logging. To record queries, enable logging on an Azure DNS resolver policy linked to each network you need, and send its diagnostic logs to an Azure Monitor destination. DNS query logs are separate from resource metrics. Update log queries and retention for the Azure format. Before switching clients. Test private names, forwarded domains and policy actions before you change client DNS settings. Moving from AWS. Resolver caches and query history are not transferred. Anything outside the stack that refers to AWS endpoint IDs or rule ARNs needs the target’s identifiers instead. Azure references: endpoints and rulesets and DNS query logs.On OCI
How it works
Tensor9 turns your Route 53 Resolver configuration into listening endpoints, forwarding endpoints and rules on the resolver of the customer’s OCI VCN. A listening endpoint receives queries for private names, for example from your on-premises resolvers. A forwarding endpoint sends queries for chosen domains to the DNS servers you name. Oracle operates the resolver, and Tensor9 is not in the DNS query path.Endpoints and private names
Each endpoint is a virtual network interface in a subnet of the appliance’s network. Point your on-premises conditional forwarders at the listening endpoint’s address. The private views attached to the VCN resolver decide which private zones it can answer. OCI decides where endpoints run, so the AWS per-zone IP assignments do not produce a matching set of interfaces. The AWS endpoint security group is not kept: set up subnet access, and any OCI network security group, for listening and forwarding traffic yourself.
The arrows show the direction of the DNS query.
Conditional forwarding
EachFORWARD rule becomes an OCI resolver rule: qname_cover_conditions holds the domain, destination_addresses lists the target servers, and source_endpoint_name picks the forwarding endpoint. The rule is part of the VCN resolver, so it applies to that resolver without a separate rule-association resource.
The domain and target IPs are kept. OCI forwards to port 53 and has no per-target port setting here.
DNS filtering
This mapping has no OCI counterpart for DNS Firewall on the resolver; plan domain filtering separately. Network Firewall URL rules inspect different traffic. Forwarding an unwanted domain to a server that does not answer produces a timeout. Neither matches the allow, block and alert behaviour of AWS DNS Firewall. AWS-managed domain lists also need a replacement policy.Limitations
Where Route 53 Resolver and this target differ- DNS Firewall is not supported. OCI’s VCN resolver has no DNS firewall, and Tensor9 does not create one. Route 53 Resolver firewall rules, query logging and DNSSEC resources in your stack do not create anything on OCI.
- DNSSEC validation is not supported. Route 53 Resolver can check DNSSEC signatures on the answers it receives; this mapping does not keep that setting. Signing a hosted zone is a different feature: it signs that zone’s records but does not validate answers for your network.
- Forwarding ports other than 53 are not supported. A target on another port is sent queries on port 53, and the deployment does not flag it. Check your rules before deploying; a target that listens on another port needs a different setup.
- You must give forwarding targets as literal IP addresses. If a rule’s
target_ipis a variable or a reference, the deployment cannot read it. The rule gets a placeholder address and a warning, and you must replace it with the real DNS server before applying. - DNS over HTTPS is not supported. The OCI VCN resolver answers and forwards over standard DNS only. A DoH protocol set on a Route 53 Resolver endpoint or forwarding target is dropped, and the deployment reports it.