Securing hybrid workloads using Amazon Route 53 Resolver DNS Firewall

Since its launch in 2021, Amazon Route 53 Resolver DNS Firewall has enabled Amazon Web Services (AWS) users to monitor and control outbound DNS queries originating from their Amazon Virtual Private Cloud (Amazon VPC) resources. Configuring domain filtering rules in Route 53 Resolver DNS Firewall helps you mitigate security threats such as data exfiltration through DNS tunneling, access to malicious domains used for phishing and malware distribution, and accidental exposure to unauthorized or non-compliant destinations. Moreover, AWS Firewall Manager enables you to centrally configure and manage Route 53 Resolver DNS Firewall rules across multiple VPCs and accounts in your AWS Organization at scale. But what if you need to extend the DNS protection scope to also cover your on-premises workloads in a hybrid AWS environment? This post shows you how to extend AWS DNS Firewall protection to your on-premises workloads, giving you a unified and consistent security policy across your hybrid AWS environment. We show you how to strengthen your security posture, maintain compliance, and reduce your operational overhead with a single, consolidated DNS filtering solution.

Extend your DNS protection scope for a hybrid AWS environment

After configuring Route 53 Resolver DNS Firewall to protect your AWS workloads and filter DNS queries based on your organization’s security policies, you can extend this protection to your hybrid AWS environment. To implement this extension, you must configure your on-premises DNS server to forward DNS queries to Amazon Route 53 Resolver inbound endpoints for any domains it doesn’t manage directly. These DNS queries can be forwarded either over the public internet or through a private network connection to your VPC containing the Route 53 Resolver inbound endpoint. The following sections detail these two connectivity options.

Private connectivity through AWS Direct Connect or AWS Site-to-Site VPN

When private connectivity is available between your on-premises environment and AWS, you can configure secure DNS query forwarding through private network connections. On-premises DNS servers forward DNS queries to your Route 53 Resolver inbound endpoint through either AWS Direct Connect or AWS Site-to-Site VPN. To further secure this communication channel, you may take more measures such as combining Direct Connect with Site-to-Site VPN, enabling MAC Security on your Direct Connect connection, etc.

Figure 1: Secure DNS queries over Site-to-Site VPN or Direct Connect

Figure 1 shows the flow of secure DNS queries over Direct Connect or Site-to-Site VPN:

1. Your corporate workstation initiates a DNS query to the internal DNS server located in your data center.
2. The corporate DNS server forwards the DNS query to your Route 53 Resolver inbound endpoint in AWS.
3. The DNS query is routed through your customer gateway and AWS virtual private gateway over either Direct Connect or Site-to-Site VPN.
4. The Route 53 Resolver inbound endpoint, which maintains the necessary DNS protocol standards, receives the DNS query.
5. The Route 53 Resolver DNS Firewall rules determine whether the DNS query is allowed to proceed or is blocked and log queries to suspicious domains.
6. Unless Route 53 Resolver DNS Firewall blocked the query, Route 53 Resolver processes the DNS query: for domains in Amazon Route 53 Private Hosted Zones (PHZs), the resolver handles the query directly using the configured PHZ. For external domains, the resolver forwards the query to external name servers to obtain the response. Then, the response is returned to the client through the same path in reverse.

Public connectivity through internet-facing AWS Network Load Balancer

For scenarios where private connectivity is not feasible, you can route DNS queries to the Route 53 Resolver inbound endpoints through an internet-facing AWS Network Load Balancer (NLB). The NLB forwards DNS queries from on-premises DNS servers to the inbound endpoint, with ingress traffic protected by source IP restrictions in the NLB’s security group. The NLB provides native DDoS protection against common attacks. For additional layers of protection, you can enable AWS Shield Advanced for your NLB resource.

Figure 2: Secure DNS queries over the public internet

Figure 2 shows the flow of secure DNS queries through an internet-facing NLB:

1. Your corporate workstation initiates a DNS query to the internal DNS server located in your data center (same as in private connectivity flow).
2. The corporate DNS server forwards the DNS query to the public IP addresses of your internet-facing NLB.
3. The DNS query is routed through your customer router Network Address Translation (NAT) IP address and Internet Gateway (IGW) over the public internet.
4. The internet-facing NLB receives the incoming DNS query and routes it to one of the Route 53 Resolver inbound endpoint’s Elastic Network Interfaces (ENIs) in private subnets, in different AWS Availability Zones (AZs), which are configured as IP targets in the target group (UDP/TCP port 53) of the NLB. Alternatively, the solution can be configured to use DNS over HTTPS (DoH) to provide web-based security controls.
5. The Route 53 Resolver Inbound endpoint, which maintains the necessary DNS protocol standards, receives the DNS query (same as in private connectivity flow).
6. The Route 53 Resolver DNS Firewall rules determine whether the DNS query is allowed to proceed or is blocked and log queries to suspicious domains (same as in private connectivity flow).
7. Unless Route 53 Resolver DNS Firewall blocked the query, Route 53 Resolver resolves the DNS query and returns the answer to the client through the same path in reverse (same as in private connectivity flow).

Design considerations for the hybrid-DNS protection solution

As you design your hybrid DNS protection solution, you encounter various architectural decisions that need balancing competing priorities across different aspects of your architecture.

Your solution needs to scale efficiently to handle DNS query volume. An NLB can process tens of millions of requests per second at ultra-low latency. A Route 53 Resolver endpoint should be configured with the appropriate number of ENIs based on your on-premises DNS query volume, keeping in mind the service quotas. Furthermore, DNS query performance varies based on factors such as query type, response size, target nameservers health, query response times, round trip latency, and the protocol used.

For high availability, first assess your workload requirements. You might need to limit the hybrid-DNS protection to end-user devices only, if your mission-critical on-premises workloads can’t tolerate the added external dependency. Distribute your NLB and Route 53 Resolver endpoint ENIs across multiple AZs, along with redundant Site-to-Site VPN or Direct Connect connectivity. The Route 53 Resolver DNS Firewall failure mode determines how it operates during failures. By default, it blocks queries when unable to evaluate them. Based on your specific availability requirements and risk assessment, you may need to adjust this setting. For the public connectivity option, consider enabling AWS Shield Advanced for enhanced DDoS protection, weighing its other costs against your availability requirements. To learn more about Route 53 Resolver endpoint high availability, go to How to achieve DNS high availability with Route 53 Resolver endpoints.

Performance requirements depend heavily on your geographical distribution. If you have globally distributed users or remote locations, then AWS Global Accelerator can improve DNS resolution performance (for the public connectivity option, go to Use AWS Global Accelerator to improve application performance), while Site-to-Site VPN Accelerator can help reduce latency for VPN connections. When using NLB with security groups, be aware that connections are tracked automatically (Amazon EC2 security group connection tracking), which can reduce the maximum queries per second per IP address (Quotas on Route 53 Resolver endpoints) and you must evaluate this performance impact against your security requirements. Your choice of DNS protocol (UDP, TCP, or DNS over HTTPS) also affects query performance and throughput. Tune DNS caching and TTL values on your on-premises DNS servers to balance between query response times and data freshness.

Implement security measures based on your threat model. When using security groups with NLB, you can protect ingress traffic through source IP restrictions, making sure that DNS queries are only accepted from authorized on-premises DNS servers. However, this configuration enables connection tracking automatically, which impacts DNS query throughput. If your performance requirements necessitate higher throughput and based on your risk assessment, then one mitigation option is to operate the NLB without security groups and implement VPC Network ACLs (Amazon VPC – Control subnet traffic with network access control lists) as compensating controls at the subnet level to restrict source IP addresses.

Your DNS security controls also present trade-offs that you need to balance. You may want to evaluate DNSSEC validation to protect your public queries against DNS spoofing, keeping in mind its operational overhead (Enabling DNSSEC validation in Amazon Route 53).

Your choice of DNS protocol presents another trade-off between security and performance, from basic UDP functionality to encrypted DNS over HTTPS.

Furthermore, when it comes to availability versus security, your Route 53 Resolver DNS Firewall failure mode configuration presents another key decision. Its default closed setting blocks queries when unable to evaluate them. This is a security setting you must balance against your availability requirements.

These architectural considerations help you balance your specific requirements across scalability, high availability, performance, and security when implementing your hybrid DNS protection solution.

Managing hybrid DNS protection at scale

As shown in Figure 3, you can use AWS Security Hub, Firewall Manager, and Route 53 Resolver DNS Firewall to centrally and consistently manage and govern DNS query protection at-scale in a multi-account AWS environment with multiple VPCs across your accounts. The following are some key aspects of this solution:

• A DNS Firewall rule group, containing all the necessary security policies, is created in the Security Tooling/Audit account.
• The Firewall Manager security policy enables central distribution and enforcement of DNS Firewall rule groups across VPCs in your AWS accounts.
• Security Hub provides a consolidated view of your security posture, integrating findings from various sources such as Firewall Manager regarding DNS Firewall policy compliance. When a VPC lacks the necessary DNS Firewall rule group association defined in your Firewall Manager policy, Security Hub surfaces this as a security finding, enabling centralized visibility of DNS protection gaps across your organization.
• DNS queries from AWS resources (such as Amazon Elastic Compute Cloud (Amazon EC2) instances) in your workload VPCs are routed to the VPC+2 IP address, where Route 53 Resolver applies the associated DNS Firewall rule groups.
• On-premises DNS queries are routed to the inbound endpoint in the Hybrid-DNS protection account’s VPC through either public internet, through NLB or private connections, using Direct Connect or Site-to-Site VPN. This is where Route 53 Resolver applies the same DNS Firewall rule groups.

Figure 3: Securing on-premises and VPC DNS queries in multi-account environment

Conclusion

In this post, we showed you how to extend your Amazon Route 53 Resolver DNS Firewall protection beyond your AWS environment to create a unified DNS security strategy across your hybrid infrastructure. Whether you choose private connectivity (using AWS Direct Connect or AWS Site-to-Site VPN) or public connectivity (using AWS Network Load Balancer), you can enforce consistent DNS filtering policies throughout your entire network footprint while maintaining operational efficiency.

The architecture we’ve shared gives you multiple strategic advantages: you get centralized DNS firewall management through AWS Firewall Manager, consistent policy enforcement across your AWS and on-premises workloads, flexible connectivity options, and enterprise-grade scalability supporting your multi-account AWS environments. DNS-based threats becoming increasingly sophisticated mean that this hybrid DNS protection solution can help your organization better defend against DNS tunneling, domain generation algorithms, and other DNS-based attacks. Following the architectural considerations we’ve outlined allows you to build a robust DNS security framework that aligns with your specific requirements for availability, performance, and security, ultimately strengthening your hybrid infrastructure’s security posture.

For questions, start a new thread on the Amazon Route 53 Resolver DNS Firewall re:Post or contact AWS support.

About the authors