# What is Route 53 Global Resolver?
Route 53 Global Resolver is an internet-reachable DNS resolver that provides easy, secure, and reliable DNS resolution for authorized clients in your organization across remote locations, branch offices, and on-premises environments. You can resolve queries for domains hosted on Amazon Route 53 private hosted zones or public domains on the internet, while maintaining high availability through global anycast architecture. Route 53 Global Resolver helps you protect your clients from DNS-based data exfiltration attacks, by filtering queries to potentially malicious domains.
Route 53 Global Resolver uses anycast IP addresses that automatically route DNS queries to the AWS Region closest to your source query location for optimal latency and availability. You can select the regions where your global resolver should provide DNS resolution from for your authorized clients, configure different views for the clients for the resolution of private and public domains, filter malicious domains, and monitor DNS activity across your organization.
**Topics**
+ [Why Route 53 Global Resolver?](#gr-why-global-resolver)
+ [Concepts and terminology](gr-concepts-terminology.md)
+ [How it works](gr-how-it-works.md)
+ [Use cases](gr-cloud-resolver-use-cases.md)
+ [Related services](gr-related-services.md)
+ [Accessing Global Resolver](gr-accessing-cloud-resolver.md)
+ [Supported AWS Regions](#regions)
+ [Opt-in Region considerations](gr-opt-in-regions.md)
+ [Setting up account access](gr-setting-up.md)
+ [Tutorial: Create your first Route 53 Global Resolver](gr-getting-started.md)
+ [Managing DNS views](gr-manage-dns-views.md)
+ [Managing access controls](gr-managing-access-controls.md)
+ [Securing DNS](gr-securing-dns.md)
+ [Configuring private hosted associations](gr-configuring-private-hosted-zone-associations.md)
+ [Monitoring DNS activity](gr-monitoring.md)
+ [Troubleshooting DNS issues](gr-troubleshooting-dns-issues.md)
+ [Quotas](gr-load-balancer-limits.md)
## Why Route 53 Global Resolver?
Route 53 Global Resolver provides centralized DNS security and filtering for remote and hybrid clients and workloads across multiple locations. Regardless of the location of your workloads, applications, or users, Route 53 Global Resolver ensures consistent DNS protection without requiring complex on-premises infrastructure.
Key benefits for remote and hybrid environments:
+ **Simplified management** - Configure private and public domain resolution using a single solution instead of managing multiple on-premises DNS servers
+ **Unified DNS security** - Apply consistent filtering policies across all remote clients and hybrid workloads
+ **Scalable protection** - Automatically scales to handle DNS queries from growing remote workforces and cloud workloads
+ **Reduced infrastructure** - Minimizes the need for DNS security appliances at each remote location
To get started, see:
+ [Key concepts and components for Route 53 Global Resolver](gr-concepts-terminology.md) - Core concepts for DNS security deployment
+ [How Route 53 Global Resolver works](gr-how-it-works.md) - How Route 53 Global Resolver protects remote and hybrid environments
+ [Tutorial: Create your first Route 53 Global Resolver](gr-getting-started.md) - Tutorial for your first DNS filtering setup
# Key concepts and components for Route 53 Global Resolver
Route 53 Global Resolver uses several key components that work together to provide split-traffic DNS resolution, high availability through global anycast architecture, and comprehensive DNS security for your organization. Understanding these Route 53 Global Resolver concepts helps you design and deploy solutions that enable seamless access to both private and public resources, help ensure service continuity across multiple Regions, and protect against DNS-based threats.
## DNS resolver for clients at on-premises and remote locations
To deploy Route 53 Global Resolver for your distributed workloads, customer locations, and users, configure these key components:
Global resolver
The main service instance that provides DNS resolution and filtering for your organization across multiple AWS Regions. Your *global resolver* uses anycast technology to automatically route DNS queries to the nearest available Region, ensuring fast response times for all clients regardless of their location.
Anycast IP addresses
Two unique IPv4 or IPv6 addresses assigned to your global resolver that you configure on client devices and network equipment. These *anycast IP addresses* are the same globally, which simplifies DNS configuration across all your locations. Anycast IP addressing enables automatic routing of DNS requests to the nearest global resolver, optimizing response times and improving service reliability.
DNS views
Configuration templates that let you apply different DNS policies to different groups of clients in your network. Use *DNS views* to implement split-horizon DNS—for example, apply strict filtering and token authentication for remote locations, while using IP-based access and different security policies for branch offices.
## DNS client authentication
Select the authentication method that works best for your deployment:
Token based authentication
Secure DNS connections using encrypted tokens for DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). You can generate unique access tokens for individual clients or device groups, set expiration periods, and revoke tokens as needed.
Access source-based authentication
Control access using IP address and CIDR range allowlists. You can configure your branch office public IP addresses or network ranges, then specify which DNS protocols (DNS-over-port-53, DoT, or DoH) each location can use based on your security requirements.
DNS protocol selection
Choose the appropriate *DNS protocol* based on your security and compatibility needs:
+ **DNS-over-port-53 (Do53)** - Use for maximum compatibility with existing network infrastructure
+ **DNS-over-TLS (DoT)** - Use when you need encrypted DNS with dedicated port separation for network monitoring
+ **DNS-over-HTTPS (DoH)** - Use when you need to bypass network restrictions, as traffic appears as regular HTTPS
## Split-traffic DNS resolution
Route 53 Global Resolver enables organizations to seamlessly resolve both private and public domains from any location, eliminating the need for complex VPN configurations or Region-specific DNS settings.
Hybrid DNS resolution
*Hybrid DNS resolution* allows Route 53 Global Resolver to simultaneously resolve queries from on-premises users and applications to private applications on AWS.
Global private zone access
*Global private zone access* extends the reach of Amazon Route 53 private hosted zones beyond VPC boundaries. Authorized clients anywhere on the internet can resolve private domain names, enabling distributed teams to access internal resources without traditional network connectivity requirements.
Seamless failover
*Seamless failover* ensures continuous access to both private and public resources even when individual AWS Regions become unavailable. The anycast architecture automatically routes queries to healthy regions while maintaining consistent resolution behavior.
## High availability and global presence
Route 53 Global Resolver provides enterprise-grade availability through distributed architecture and automatic failover capabilities.
Multi-region deployment
*Multi-region deployment* distributes Route 53 Global Resolver instances across at least 2 AWS Regions to help ensure high availability and allow failover during service outages. You can select specific Regions based on your geographic requirements and compliance needs.
Automatic geographic optimization
*Automatic geographic optimization* routes DNS queries to the nearest available AWS Region based on network topology and latency. This reduces response times and improves user experience for globally distributed organizations.
Built-in redundancy
*Built-in redundancy* helps maintain service continuity through automatic failover to alternate regions when primary regions become unavailable. Clients continue to use the same anycast IP addresses while traffic is transparently rerouted.
## DNS resolution and forwarding
Private hosted zone resolution
*Private hosted zone resolution* enables Route 53 Global Resolver to resolve DNS queries for Route 53 private hosted zones across AWS Regions. This allows authorized clients to resolve domains for applications and resources hosted by Route 53 from anywhere on the internet.
Split-horizon DNS
*Split-horizon DNS* provides different DNS responses based on the client making the query. Route 53 Global Resolver can resolve public domains on the internet while simultaneously resolving private domains, providing seamless access to both public and private resources.
DNSSEC validation
*DNSSEC validation* verifies the authenticity and integrity of DNS responses from public nameservers for DNSSEC-signed domains. This validation ensures DNS responses haven't been tampered with during transmission, providing protection against DNS spoofing and cache poisoning attacks.
EDNS Client Subnet (ECS)
*EDNS Client Subnet* is an optional feature that forwards client subnet information in DNS queries to authoritative nameservers. This enables more accurate geographic-based DNS responses, potentially reducing latency by directing clients to nearer content delivery networks or servers. For DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) connections, you can use EDNS0 to pass the client IP address information. When ECS is enabled on Global Resolver, the service automatically injects the client IP if not provided in the query.
## DNS filtering and domain lists
Route 53 Global Resolver provides domain-based filtering using domain lists managed by AWS to block or allow specific domains.
DNS filtering rules
*DNS filtering rules* define how Route 53 Global Resolver handles DNS queries based on domain matching criteria. Rules are evaluated in priority order and can specify actions (ALLOW, BLOCK, or ALERT) for queries to specific domains or domain categories.
Domain lists
*Domain lists* are collections of domains used in filtering rules. They can be:
+ **Custom domain lists** - Domain collections you create and maintain
+ **AWS managed domain lists** - Pre-configured threat lists and content categories maintained by AWS that leverage threat intelligence to identify malicious domains. Available threat lists include:
+ Malware domains - Domains known to host or distribute malware
+ Botnet command and control - Domains used by botnets for command and control communications
+ Spam - Domains associated with spam and unwanted email campaigns
+ Phishing - Domains used in phishing attacks to steal credentials and personal information
+ Amazon GuardDuty threat list - Domains identified by GuardDuty threat intelligence
Available content categories include social media, gambling, and other categories that help organizations control access to specific types of content.
Individual domain specifications in managed lists cannot be viewed or edited to protect intellectual property and maintain security effectiveness.
## Advanced DNS threat detection
Route 53 Global Resolver uses dynamic algorithmic analysis to detect advanced DNS threats such as DNS tunneling and Domain Generation Algorithms. Unlike domain lists that match known bad domains, algorithmic detection analyzes DNS query patterns in real-time to identify suspicious behavior.
DNS tunneling detection
DNS tunneling is used by attackers to exfiltrate data from the client by using the DNS tunnel without making a network connection to the client.
Domain Generation Algorithm (DGA) detection
Domain Generation Algorithms (DGAs) are used by attackers to create large numbers of domain names for its command-and-control servers.
Confidence thresholds
Each detection algorithm outputs a confidence score that determines rule triggering. Higher confidence thresholds reduce false positives but may miss sophisticated attacks. Lower thresholds increase detection sensitivity but require additional alert analysis to filter false positives.
Action limitations
Advanced threat protection rules support only `ALERT` and `BLOCK` actions. The `ALLOW` action is not supported because algorithmic detection cannot definitively classify benign traffic, only identify potentially malicious patterns.
## Monitoring and logging
Query logs
*Query logs* provide detailed information about DNS queries processed by Route 53 Global Resolver, including source IP, queried domain, response code, policy actions taken, and timestamps. Logs can be delivered to Amazon CloudWatch, Amazon Data Firehose, or Amazon Simple Storage Service for analysis and compliance reporting.
OCSF format
*Open Cybersecurity Schema Framework (OCSF) format* is a standardized logging format used by Route 53 Global Resolver for DNS query logs. This format provides consistent, structured data that integrates easily with security information and event management (SIEM) systems and other security tools.
Log destinations
*Log destinations* determine where DNS query logs are delivered, each with different characteristics:
+ **Amazon Simple Storage Service** - Cost-effective long-term storage ideal for compliance and batch analysis. Integrates with analytics tools like Amazon Athena and Amazon EMR.
+ **Amazon CloudWatch Logs** - Real-time monitoring and alerting with integration to Amazon CloudWatch alarms and dashboards. Supports log insights for ad-hoc queries.
+ **Amazon Data Firehose** - Real-time streaming to external systems with built-in data transformation capabilities. Supports automatic scaling and buffering.
Observability Region
The *Observability Region* determines where DNS query logs are delivered.
# How Route 53 Global Resolver works
Route 53 Global Resolver enables split-traffic DNS resolution between public and private domains, provides high availability through through the two or more AWS Regions you choose, and secures DNS queries by intercepting requests and applying DNS filtering policies. Understanding this process helps you troubleshoot issues and optimize your deployment for performance, availability, and security.
## What happens when clients make DNS queries
When someone at your location tries to query domain, Route 53 Global Resolver processes their DNS request through multiple security layers.
The DNS query processing involves these sequential steps:
1. **Query reception** - Client devices send DNS queries to Route 53 Global Resolver anycast IP addresses. The anycast routing automatically directs queries to the nearest AWS Region.
1. **Authentication** - Route 53 Global Resolver authenticates the client using configured authentication methods (token-based for DoH/DoT or IP Access Source for all protocols).
1. **Policy evaluation** - The service evaluates DNS queries against configured security policies and domain lists to determine the appropriate action (allow, block, or alert). For queries targeting private hosted zones, Route 53 Global Resolver checks if the client is authorized to access the private domain based on the DNS view rule managed by your administrator before proceeding with resolution.
1. **Resolution** - For allowed queries, Route 53 Global Resolver performs DNS resolution using public DNS resolvers or private hosted zone resolution as appropriate.
1. **Response delivery** - The service returns the DNS response to the client and logs the query details for monitoring and analysis.
## Global anycast architecture
Route 53 Global Resolver uses anycast IP addresses to provide global availability and automatic geographic routing.
Route 53 Global Resolver uses anycast IP addresses to provide:
+ **Automatic geographic routing** - DNS queries are automatically routed to the closest AWS Region for optimal performance.
+ **Built-in redundancy** - If a Region becomes unavailable, traffic automatically fails over to the next closest Region.
+ **Consistent IP addresses** - Clients use the same anycast IP addresses regardless of their location, simplifying configuration.
## DNS filtering and security
Route 53 Global Resolver provides comprehensive DNS filtering and security through multiple layers. The DNS filtering and security architecture diagram illustrates how queries are processed through authentication, policy evaluation, and resolution layers.
Route 53 Global Resolver provides comprehensive DNS security through:
+ **Domain-based filtering** - Block or allow queries based on domain names using custom or AWS managed domain lists.
+ **Threat intelligence integration** - Leverage AWS managed threat intelligence to automatically block known malicious domains.
+ **Advanced threat detection** - Detect and block DNS tunneling attempts and Domain Generation Algorithm (DGA) patterns.
+ **Real-time monitoring** - Generate alerts and logs for security events and policy violations.
# DNS security and split-horizon use cases for Route 53 Global Resolver
Route 53 Global Resolver addresses three primary DNS challenges for organizations:
Enabling split-traffic between public and private DNS resolution
Enable global access to private hosted zones (PHZs) on Amazon Route 53 from any location while simultaneously resolving public domains on the internet. Allow remote locations and branch offices to resolve internal application names without complex VPN configurations or Region-specific forwarding. Implement split-horizon DNS to provide different DNS responses based on the client making the query, helping remote clients resolve queries for private and public domains.
Securing DNS traffic from DNS exfiltration attacks
Protect remote locations and branch offices from DNS-based data exfiltration attacks by filtering queries to malicious domains. Improve privacy by encrypting DNS traffic in-transit using DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) so that only authorized clients can access your DNS services. Apply security policies to block threats like DNS tunneling and Domain Generation Algorithms (DGAs). Validate DNS response authenticity using DNSSEC (Domain Name System Security Extensions) for DNSSEC-signed domains to protect against DNS spoofing and cache poisoning attacks.
High availability and global presence
Achieve high availability through global deployment and maintain consistent DNS configuration worldwide from a single management interface. Route 53 Global Resolver runs across the AWS Regions you choose, using anycast IP addresses that automatically route queries to the nearest available Region for optimal performance and reliability. Global enterprises can configure and manage DNS policies centrally while providing clients with a single set of IP addresses that work globally with automatic geographic optimization. Built-in redundancy is designed to help maintain service continuity even if individual Regions become unavailable.
Additional capabilities support these primary use cases:
Implementing DNS filtering and content policies
Govern internet access across multiple locations by creating custom domain lists or using AWS Managed Domain Lists. To help you implement filtering and content policies according to your needs, Managed Domain Lists include multiple categories of DNS threats that cover several domains. Configure Access Source using IP allowlists or Access Tokens, and set up different filtering policies for different office locations or client groups.
Flexible authentication for different deployment scenarios
Choose the authentication method that works best for your deployment: token-based authentication or IP based authentication using the source CIDR range allowlists.
Maintaining visibility and compliance
Monitor DNS activity across your organization by delivering logs to Amazon CloudWatch, Firehose, or Amazon Simple Storage Service. Choose a single destination Region for centralized log storage to support security audits, compliance requirements, and threat investigation.
# AWS services that integrate with Route 53 Global Resolver for enhanced DNS security
Route 53 Global Resolver integrates seamlessly with other AWS services to provide comprehensive DNS security and management capabilities. These integrations enhance Route 53 Global Resolver's core functionality and enable advanced use cases:
Amazon Route 53
Route 53 Global Resolver integrates with Amazon Route 53 to resolve private hosted zones globally. For more information, see the [Amazon Route 53 Developer Guide](https://docs.aws.amazon.com/route53/latest/developerguide/).
Amazon CloudWatch
Route 53 Global Resolver can deliver query logs to Amazon CloudWatch for monitoring and analysis. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/cloudwatch/).
Amazon Simple Storage Service
Route 53 Global Resolver can store query logs in Amazon Simple Storage Service buckets for long-term storage and analysis. For more information, see the [Amazon S3 User Guide](https://docs.aws.amazon.com/s3/).
Amazon Data Firehose
Route 53 Global Resolver can stream query logs to Amazon Data Firehose for real-time processing. For more information, see the [Amazon Data Firehose Developer Guide](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html).
Route 53 Resolver DNS Firewall
Route 53 Global Resolver complements Route 53 Resolver DNS Firewall by providing global DNS filtering capabilities. For more information, see the [Route 53 Resolver DNS Firewall documentation](https://docs.aws.amazon.com/route53/latest/developerguide/resolver-dns-firewall.html).
AWS Global Accelerator
Route 53 Global Resolver works with AWS Global Accelerator to provide optimized global network performance for DNS resolution. For more information, see the [AWS Global Accelerator Developer Guide](https://docs.aws.amazon.com/global-accelerator/).
# How to access and manage Route 53 Global Resolver through AWS interfaces
Route 53 Global Resolver provides multiple access methods to accommodate different management preferences and automation requirements. You can manage Route 53 Global Resolver through these interfaces:
AWS Management Console
The AWS Management Console provides a web-based interface for Route 53 Global Resolver. You can use the console to configure DNS filtering policies, manage authentication settings, and monitor query logs.
AWS Command Line Interface (AWS CLI)
The AWS CLI provides direct access to Route 53 Global Resolver API operations. You can use the AWS CLI to automate Route 53 Global Resolver tasks and integrate them into your scripts and workflows.
AWS SDKs
AWS provides SDKs for many programming languages. You can use the SDKs to integrate Cloud Resolver functionality into your applications.
REST API
Route 53 Global Resolver provides a REST API that you can use to programmatically manage your DNS resolution and filtering policies.
## Supported AWS Regions
Route 53 Global Resolver is available in the following AWS Regions:
+ US East (N. Virginia)
+ US East (Ohio)
+ US West (N. California)
+ US West (Oregon)
+ Europe (Frankfurt)
+ Europe (Ireland)
+ Europe (London)
+ Asia Pacific (Mumbai)
+ Asia Pacific (Singapore)
+ Asia Pacific (Tokyo)
+ Asia Pacific (Seoul)
+ Asia Pacific (Sydney)
+ Africa (Cape Town)
+ Asia Pacific (Hong Kong)
+ Asia Pacific (Taipei)
+ Asia Pacific (Osaka)
+ Asia Pacific (Hyderabad)
+ Asia Pacific (Jakarta)
+ Asia Pacific (Melbourne)
+ Asia Pacific (Malaysia)
+ Asia Pacific (Thailand)
+ Canada (Central)
+ Canada West (Calgary)
+ Europe (Zurich)
+ Europe (Stockholm)
+ Europe (Milan)
+ Europe (Spain)
+ Europe (Paris)
+ Mexico (Central)
+ South America (São Paulo)
# Opt-in Region considerations for Route 53 Global Resolver
Some AWS Regions are active by default for your AWS account. Certain Regions are activated only when you manually select them. This document refers to those Regions as opt-in Regions. In contrast, Regions that are active by default, as soon as your AWS account is created, are referred to as commercial Regions, default Regions, or simply, Regions.
AWS Regions introduced after March 20, 2019 are deployed as opt-in Regions. In an opt-in Region, your account is not enabled within that Region. Your Route 53 Global Resolver data is not replicated to the Region unless you choose to opt into use of that Region. For more information about opt-in Regions, see [Managing AWS Regions](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html).
When using Route 53 Global Resolver in opt-in Regions, here are some considerations to keep in mind.
+ To select an opt-in Region for your Global Resolver deployment, your account must be opted-in to the Region.
+ You can select any set of default or opt-in Regions for your Global Resolver.
+ If you have selected an AWS opt-in Region for a Global Resolver, when you opt-out your account from that Region, the service will stop propagating your global resolver data to that Region. It will also trigger deletion of all your resources in that Region. This will cause impairment to your DNS traffic destined to that Region as resources get cleaned up, but traffic will eventually direct away to your other selected Regions.
+ Similarly, if you have selected only a set of opt-in Regions for your Global Resolver and you opt-out your account from all the Regions, it will effectively delete your Global Resolver.
+ You might also select any default or opt-in Region for your Observability Region where your DNS logs will be delivered. If you choose to opt-out your account, the service will stop sending DNS logs to your destinations in that Region. To prevent impairment of log delivery, we recommend setting up a new log delivery destination in a separate Region and update the observability Region in your Global Resolver accordingly.
+ Global Resolver does not support expanding and contracting Regions in your Global Resolver at this time. We recommend you plan ahead which Regions you intend to opt-in and select before creating a Global Resolver.
# Setting up account access for Route 53 Global Resolver
Before you start using Route 53 Global Resolver, you need an AWS account and the appropriate permissions to access Route 53 Global Resolver resources. This includes creating IAM users and roles with the necessary permissions.
This section guides you through the steps required to configure users and roles to access Route 53 Global Resolver.
**Topics**
+ [Sign up for an AWS account](#sign-up-for-aws)
+ [Create a user with administrative access](#create-an-admin)
+ [Creating policies and roles](#gr-setting-up-permissions)
+ [Network considerations](#gr-setting-up-network)
## Sign up for an AWS account
If you do not have an AWS account, complete the following steps to create one.
**To sign up for an AWS account**
1. Open [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup).
1. Follow the online instructions.
Part of the sign-up procedure involves receiving a phone call or text message and entering a verification code on the phone keypad.
When you sign up for an AWS account, an *AWS account root user* is created. The root user has access to all AWS services and resources in the account. As a security best practice, assign administrative access to a user, and use only the root user to perform [tasks that require root user access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).
AWS sends you a confirmation email after the sign-up process is complete. At any time, you can view your current account activity and manage your account by going to [https://aws.amazon.com/](https://aws.amazon.com/) and choosing **My Account**.
## Create a user with administrative access
After you sign up for an AWS account, secure your AWS account root user, enable AWS IAM Identity Center, and create an administrative user so that you don't use the root user for everyday tasks.
**Secure your AWS account root user**
1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/) as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password.
For help signing in by using root user, see [Signing in as the root user](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) in the *AWS Sign-In User Guide*.
1. Turn on multi-factor authentication (MFA) for your root user.
For instructions, see [Enable a virtual MFA device for your AWS account root user (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) in the *IAM User Guide*.
**Create a user with administrative access**
1. Enable IAM Identity Center.
For instructions, see [Enabling AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) in the *AWS IAM Identity Center User Guide*.
1. In IAM Identity Center, grant administrative access to a user.
For a tutorial about using the IAM Identity Center directory as your identity source, see [ Configure user access with the default IAM Identity Center directory](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) in the *AWS IAM Identity Center User Guide*.
**Sign in as the user with administrative access**
+ To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email address when you created the IAM Identity Center user.
For help signing in using an IAM Identity Center user, see [Signing in to the AWS access portal](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) in the *AWS Sign-In User Guide*.
**Assign access to additional users**
1. In IAM Identity Center, create a permission set that follows the best practice of applying least-privilege permissions.
For instructions, see [ Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) in the *AWS IAM Identity Center User Guide*.
1. Assign users to a group, and then assign single sign-on access to the group.
For instructions, see [ Add groups](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) in the *AWS IAM Identity Center User Guide*.
## Creating policies and roles
Configure AWS Identity and Access Management (IAM) permissions so your team can deploy and manage Route 53 Global Resolver resources. You can use administrative permissions for full access or read-only permissions for monitoring and viewing configurations.
All Route 53 Global Resolver API operations require appropriate IAM permissions. If you don't have the required permissions, API calls will return `AccessDeniedException` (401) or `UnauthorizedException` (401) errors.
### Administrative permissions
If you're setting up Route 53 Global Resolver for the first time or managing all aspects of the service, you need administrative permissions. You can use these AWS managed policies:
+ `AmazonRoute53GlobalResolverFullAccess` - Provides full access to Route 53 Global Resolver resources, including creating, updating, and deleting global resolvers, DNS views, firewall rules, and domain lists
+ `AmazonRoute53FullAccess` - Required if you plan to use private hosted zone forwarding
+ `CloudWatchLogsFullAccess` - Required if you plan to send logs to Amazon CloudWatch
+ `AmazonS3FullAccess` - Required if you plan to import firewall domain lists from Amazon S3 or send logs to Amazon S3
### Read-only permissions
If you only need to view Route 53 Global Resolver configurations and logs, you can use these AWS managed policies:
+ `AmazonRoute53GlobalResolverReadOnlyAccess` - Provides read-only access to Route 53 Global Resolver resources, including viewing global resolvers, DNS views, firewall rules, domain lists, and access sources
+ `AmazonRoute53ReadOnlyAccess` - Required to view private hosted zone associations
+ `CloudWatchReadOnlyAccess` - Required to view logs in Amazon CloudWatch
+ `AmazonS3ReadOnlyAccess` - Required to view firewall domain list files stored in Amazon S3
## Network considerations
Before implementing Route 53 Global Resolver, consider the following network requirements:
Client IP ranges
This is only required when using access source-based authentication. Identify the IP address ranges (CIDR blocks) for all clients that will use Route 53 Global Resolver. You'll need these for configuring rules for your access source.
DNS protocols
Determine which DNS protocols your clients will use:
+ **Do53** - Standard DNS over port 53 (UDP/TCP)
+ **DoH** - DNS-over-HTTPS for encrypted queries
+ **DoT** - DNS-over-TLS for encrypted queries
Firewall and security groups
Ensure your network firewalls and security groups allow outbound traffic to Route 53 Global Resolver anycast IP addresses on the appropriate ports (53 for Do53, 443 for DoH, 853 for DoT).
# Tutorial: Create your first Route 53 Global Resolver
This getting started guide demonstrates the basic components of Route 53 Global Resolver and optionally creating a simple DNS filtering setup. This tutorial covers the core concepts but doesn't include production requirements like client configuration, logging, or private domain resolution.
When you're finished, you'll have a basic Route 53 Global Resolver setup that can filter DNS queries and block malicious domains.
The following sections describe how to quickly get started with DNS security and filtering using Route 53 Global Resolver.
## Prerequisites
Before you can use Route 53 Global Resolver, you need an AWS account and the appropriate permissions to access, view, and edit Route 53 Global Resolver components. Your system administrator must complete the steps in [Setting up account access for Route 53 Global Resolver](gr-setting-up.md), and then return to this tutorial.
## Step 1: Create a global resolver
First, create a global resolver instance and select the AWS Regions where it will operate.
1. Open the Route 53 Global Resolver console at [https://console.aws.amazon.com/route53globalresolver/](https://console.aws.amazon.com/route53globalresolver/).
1. Choose **Create global resolver**.
1. For **Name**, enter a descriptive name for your global resolver.
1. For **Description**, optionally enter a description.
1. For **Regions**, select two or more AWS Regions where you want to instantiate the global resolver. Choose Regions closest to your clients for optimal performance.
1. For **IP address type**, choose the IP address type for this resolver.
+ **IPv4** - Includes only IPv4 addresses.
+ **Dualstack** - Includes IPv4 and IPv6 addresses.
1. Optionally, add tags to help organize and manage your resources.
1. Choose **Create global resolver**.
You'll receive anycast IPv4 addresses immediately that your clients can use to reach the resolver. The global resolver creation process takes a few minutes to complete before the addresses become functional.
## Step 2: Create a DNS view and configure authentication
Create a DNS view to organize your clients and configure authentication using IP Access Sources. This tutorial uses IP-based authentication. You can also use access tokens for DoH/DoT protocols.
1. In the Route 53 Global Resolver console, choose your global resolver.
1. Choose **Create DNS view**.
1. For **Name**, enter a descriptive name for your DNS view.
1. For **Description**, optionally enter a description.
1. Choose **Create DNS view**.
1. After the DNS view is created, choose **Access source** and then **Create access source**.
1. For **CIDR block**, enter the IP address range for your clients (for example, `203.0.113.0/24`).
1. For **Protocol**, choose **Do53** (DNS over port 53) for basic setup.
1. Choose **Create Access Source rule**.
## Step 3: Configure DNS filtering rules (optional)
Set up basic DNS filtering rules to block access to malicious domains.
1. In your DNS view, choose **Firewall rules** and then **Create firewall rule**.
1. For **Name**, enter a descriptive name for the rule.
1. For **Priority**, enter `100` (lower numbers have higher priority).
1. For **Action**, choose **Block**.
1. For **Domain list type**, choose **AWS Managed Domain List**.
1. For **Managed domain list**, choose **AmazonGuardDutyThreatList** and **Malware and Botnet Command and Control** to block known malicious domains (you can add other managed lists or create custom lists later).
1. Choose **Create firewall rule**.
## Step 4: Test your configuration
Test that your Route 53 Global Resolver configuration is working correctly.
1. From a client machine within your configured CIDR range, test DNS resolution using the anycast IP addresses provided by your global resolver:
```
nslookup example.com
```
1. Verify that legitimate domains resolve correctly.
1. Test that blocked domains are properly filtered. You can create a custom domain list with a test domain to verify your firewall rules are working correctly. For more information about Managed Domain Lists, see [Managed Domain Lists](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html).
1. Check the Route 53 Global Resolver console for query logs and filtering activity.
For comprehensive testing procedures and troubleshooting, see *Troubleshooting Route 53 Global Resolver*.
## Step 5: Monitoring DNS activity
Configure logging for your DNS activity.
1. Choose an Observability Region.
1. Select the destination for query logs.
For comprehensive testing procedures and troubleshooting, see *Testing and troubleshooting Route 53 Global Resolver*.
## Step 6: Clean up (optional)
If you created this configuration for testing purposes and don't want to continue using Route 53 Global Resolver, clean up the resources to avoid ongoing charges.
1. In the Route 53 Global Resolver console, delete any firewall rules you created.
1. Delete any Access Source rules you created.
1. Delete the DNS view.
1. Delete the global resolver.
**Important**
Deleting these resources will stop DNS resolution for any clients configured to use them. Update your client configurations before deleting the resolver or removing access rules.
## Next steps
Now that you have a basic Route 53 Global Resolver configuration, you can explore additional features:
+ Configure client devices to use your resolver (required for production). Update your client DNS settings to use the anycast IP addresses provided by your global resolver.
+ Set up logging for monitoring and compliance (recommended for production). Configure logging to Amazon CloudWatch, Amazon S3, or Amazon Data Firehose for monitoring and analysis. For more information, see [Monitoring DNS activity and performance with Route 53 Global Resolver](gr-monitoring.md).
+ Configure private hosted zone forwarding for internal domains (required if you have private AWS resources). For more information, see *Working with private hosted zones*.
+ Set up encrypted DNS connectivity using DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). For more information, see *Configuring encrypted DNS*.
+ Create custom domain lists and advanced filtering rules. For more information, see *DNS filtering*.
# Managing DNS views with Route 53 Global Resolver
You can manage ongoing Route 53 Global Resolver operations including updating DNS views to control which client device groups can resolve to internal resources and what domains to filter.
## Managing DNS views
After creating DNS views, you can update their configuration, enable or disable them, and manage their lifecycle.
### Creating DNS views for client device groups
A DNS view is a logical grouping defines security policies for a group of client devices, such as remote workers, branch office devices, or on-premises equipment. Each view has its own authentication requirements, filtering rules, and private hosted zone associations.
**To create a DNS view**
1. Open the console at [https://console.aws.amazon.com/route53globalresolver/](https://console.aws.amazon.com/route53globalresolver/).
1. Choose your global resolver from the list.
1. Choose the **DNS views** tab.
1. Choose **Create DNS view**.
1. In the **DNS view details** section:
1. For **DNS view name**, enter a descriptive name for your DNS view (up to 128 characters).
1. (Optional) For **Description**, enter a description for your DNS view (up to 255 characters).
1. In the **DNS query handling** section, configure the following settings:
+ **DNSSEC validation** - Choose **Enable** or **Disable**. DNSSEC validation enables the Global Resolver to verify the authenticity of DNS responses.
+ **Firewall rules fail open behavior** - Choose **Enable** to allow queries to proceed when DNS Firewall cannot evaluate them, or **Disable** to block such queries.
+ **EDNS0 client subnet** - Choose **Enable** to improve client location accuracy for traffic routing to nearby resources and efficient caching, or **Disable** to turn off this feature.
1. Choose **Create DNS view**.
After creating the DNS view, you can configure access controls, firewall rules, and private hosted zone associations.
### Editing DNS views
You can modify DNS view settings after creation, including DNS query handling options and associated resources.
**To edit a DNS view**
1. In the console, navigate to your global resolver.
1. Choose the **DNS views** tab.
1. Select the DNS view you want to edit and choose **Edit**.
1. Modify the DNS view settings as needed and choose **Save changes**.
### Enabling and disabling DNS views
You can temporarily disable a DNS view without deleting it. When disabled, the global resolver stops serving requests for client devices associated with that DNS view.
**Warning**
Disabling a DNS view immediately stops DNS resolution for all client devices associated with that view. Ensure you have alternative DNS resolution configured for affected client devices.
### Deleting DNS views
Before you can delete a DNS view, you must first delete all associated resources, including Access Source rules, access tokens, firewall rules, and private hosted zone associations.
**Warning**
Deleting a DNS view is irreversible and will immediately stop DNS resolution for all client devices associated with that view.
## Managing private hosted zone associations
You can view, update, and remove private hosted zone associations as needed to control which client device groups have access to internal resources.
### Viewing associations
To view all private hosted zone associations for a DNS view, navigate to your DNS view and check the **Private hosted zones** section to see all associated zones with their status and association details.
### Updating associations
You can update the name of a private hosted zone association by selecting the association, choosing **Edit**, updating the association name, and saving changes.
### Removing associations
When you remove a private hosted zone association, Route 53 Global Resolver stops using that zone to resolve DNS queries for the associated DNS view.
**Warning**
Removing a private hosted zone association immediately affects DNS resolution. Queries for domains in the disassociated zone will be resolved using public DNS instead of the private zone records.
# Configure settings for DNS views in Route 53 Global Resolver
Route 53 Global Resolver allows you to configure different DNS policies and access controls for different groups of client devices based on their security requirements and access needs. Set up DNS policies and access controls in Route 53 Global Resolver for different groups of client devices based on their security requirements and access needs.
## Configuring DNS settings for client groups
Each DNS view has several settings that control how DNS queries are processed and resolved for different client device groups.
### DNSSEC validation
DNSSEC validation helps ensure that DNS responses for public domains are authentic and haven't been tampered with. When you enable DNSSEC validation, Route 53 Global Resolver checks DNSSEC signatures and returns SERVFAIL for domains with invalid signatures.
**Consider enabling DNSSEC validation if:**
+ Your organization needs cryptographic verification of DNS responses
+ You want protection against DNS spoofing and cache poisoning attacks
+ You have compliance requirements that require DNSSEC validation
**Note**
DNSSEC validation only applies to public domains. Private hosted zones use their own authentication mechanisms.
### EDNS Client Subnet (ECS)
EDNS Client Subnet includes information about the client's network location in DNS queries sent to authoritative servers. This allows content delivery networks and geographically distributed services to provide location-appropriate responses.
**ECS can help you:**
+ Get better performance from geographically distributed services
+ Improve content delivery network routing accuracy
+ Better comply with regional content restrictions
**Privacy considerations:**
+ ECS reveals partial client IP information to authoritative servers (maximum /24 for IPv4 and /48 for IPv6)
+ Consider your organization's privacy requirements before enabling
### Firewall fail open
The firewall fail open setting determines what happens when DNS firewall rules cannot be evaluated due to service impairment or configuration issues.
Disabled (default)
DNS queries are blocked when firewall rules can't be evaluated. This gives you maximum security but might affect availability during service issues.
Enabled
DNS queries are allowed when firewall rules can't be evaluated. This prioritizes availability over security during service issues.
## Best practices for organizing client device groups
Follow these best practices when designing DNS views for different client device groups:
### View organization strategies
+ **Separate by security requirements** - Create different views for client devices with different security clearances or access levels
+ **Organize by location** - Use separate views for different geographic locations or network segments
+ **Group by device type** - Create dedicated views for servers, workstations, mobile devices, or IoT devices
+ **Use descriptive names** - Choose names that clearly indicate the view's purpose and target client devices
### Security considerations
+ **Principle of least privilege** - Configure each view with the minimum access required for its client devices
+ **Default deny** - Start with restrictive firewall rules and add exceptions as needed
+ **Regular review** - Periodically review and update DNS view configurations
+ **Monitor usage** - Use DNS query logs to monitor and analyze DNS view usage patterns
# Managing access controls with access sources and tokens in Route 53 Global Resolver
Route 53 Global Resolver provides two primary methods for controlling client device access: access sources for IP-based authentication and access tokens for token-based authentication. This chapter covers both approaches, helping you choose the right authentication method for your environment and implement comprehensive access controls.
**Topics**
+ [Access control methods](gr-understanding-access-control-methods.md)
+ [Configuring access sources](gr-configuring-access-sources.md)
+ [Managing access tokens](gr-managing-access-tokens.md)
+ [Best practices](gr-access-control-best-practices.md)
# Understanding access control methods in Route 53 Global Resolver
Route 53 Global Resolver offers two distinct authentication methods to control client access to your DNS infrastructure. Each method serves different use cases and environments.
IP-based access sources
You configure access source rules that allow or deny DNS queries based on client IP addresses. This method works well for environments with predictable IP ranges, such as branch offices or VPN connections. Access sources support all DNS protocols (Do53, DoT, and DoH) and provide straightforward configuration for network administrators.
Token-based authentication
Access tokens provide secure authentication for DoH and DoT protocols using encrypted, time-limited credentials. This method suits mobile clients and environments where IP addresses change frequently. You can renew tokens before expiration and they offer enhanced security through encryption.
Consider these factors when selecting your authentication approach:
## Choosing the right authentication method
| Factor | Access sources | Access tokens |
| --- | --- | --- |
| Best for | Fixed IP ranges, office networks, VPN users | Mobile devices, dynamic IPs, remote workers |
| Security level | Network-based, relies on IP trust | Encrypted credentials, time-limited |
| Management complexity | Simple IP range management | Token lifecycle and distribution |
| Protocol support | Do53, DoT, DoH | DoT, DoH only |
You can use both methods simultaneously to create layered security. For example, use access sources for office networks and tokens for remote workers.
# Configuring access sources and access source rules
Access sources control client access based on IP addresses. You create access source rules that specify which IP ranges can query your DNS infrastructure and which protocols they can use.
## Creating access source rules
Follow these steps to create an access source rule that allows specific IP ranges to query your DNS infrastructure.
1. Open the Route 53 Global Resolver console and navigate to your DNS view.
1. In the **Access source** section, choose **Create access source rule**.
1. For **Rule name**, enter a descriptive name that identifies the purpose of this rule, such as `office-network` or `vpn-users`.
1. For **IP address type**, choose **IPV4** or **IPV6**.
1. For **CIDR block**, specify the IP addresses that should have access. You can use CIDR notation for IP ranges: `203.0.113.0/24` or `2001:db8::/112`, or individual IP addresses: `203.0.113.5/32` or `2001:db8::1/128`.
1. For **Protocol**, select the DNS protocols this rule applies to:
+ **Do53** - Standard DNS over UDP/TCP (port 53)
+ **DoT** - DNS over TLS (port 853)
+ **DoH** - DNS over HTTPS (port 443)
1. Choose **Create access source rule**.
Client devices from the specified IP ranges can now query your DNS infrastructure using the selected protocols.
## Understanding rule evaluation and priority
Route 53 Global Resolver evaluates access source rules when identifying the correct view to use.
+ Rules are processed from most specific to least specific IP ranges, where the most-specific matching rule takes precedence.
+ If no rules match, the request is denied by default.
Test your access source configuration by querying from different IP addresses to ensure the rules work as expected.
# Managing access tokens for encrypted authentication
Access tokens provide encrypted authentication for DoH and DoT protocols. Unlike IP-based access sources, tokens work regardless of client location and offer enhanced security through encryption and expiration controls.
## Creating access tokens
Follow these steps to create access tokens to authenticate client devices that use DoH or DoT protocols.
1. Open the Route 53 Global Resolver console and navigate to your DNS view.
1. In the **Access source** section, choose **Create access token**.
1. For **Name**, enter a descriptive name that identifies the token's purpose, such as `mobile-devices` or `remote-workers-q4`.
1. For **Expiration**, set when the token should expire. We recommend 90 days or less for security. Consider your token distribution and renewal capabilities when setting the expiration period.
1. Choose **Create access token**.
1. Distribute the token securely to your client devices using your organization's secure communication channels.
## Configuring client devices with access tokens
Configure client devices to use access tokens for authentication with your Route 53 Global Resolver infrastructure.
**DoH configuration**
To configure DoH with access tokens, you need your global resolver's DNS name or IP addresses:
1. Use the GetGlobalResolver API to retrieve connectivity details for your resolver.
1. Note the `ipv4Addresses` (for example, 3.3.3.3, 3.3.3.4) and `dnsName` (for example, a1bc234567890a.route53globalresolver.global.on.aws).
1. Include the token as a URL parameter in the DoH endpoint using the DNS name:
```
https://a1bc234567890a.route53globalresolver.global.on.aws/dns-query?token=
```
Replace `` with the actual token that you generated.
**DoT configuration**
For DoT queries with access tokens, include the token in an EDNS0 option with the following specifications:
+ **Option Code:** `0xffa0`
+ **Option Data:** The access token in string format
The specific implementation depends on your DoT client software and how it handles EDNS0 options.
## Token lifecycle management
Manage token expiration and renewal to maintain secure access for your client devices.
+ **Monitor expiration dates** - Track token expiration dates and plan renewals in advance.
+ **Renew before expiration** - Create new tokens before old ones expire to avoid service interruption.
+ **Rotate tokens regularly** - Replace tokens periodically even before expiration for enhanced security.
+ **Revoke compromised tokens** - Delete tokens immediately if you suspect they have been compromised.
Consider implementing automated token renewal processes for large deployments to reduce administrative overhead.
# Platform configuration examples
Use these platform-specific examples to configure client devices with your Route 53 Global Resolver access tokens and connection details.
## Windows configuration
Follow these steps to configure Windows clients to use DoH with access tokens using the netsh command.
1. Open Command Prompt as an administrator.
1. Enable the global DoH setting:
```
netsh dns add global doh=yes
```
1. Register DoH servers with access tokens. Replace the example values with your actual resolver details:
```
netsh dns add encryption server=3.3.3.3 dohtemplate=https://a1bc234567890a.route53globalresolver.global.on.aws/dns-query?token= autoupgrade=yes
netsh dns add encryption server=3.3.3.4 dohtemplate=https://a1bc234567890a.route53globalresolver.global.on.aws/dns-query?token= autoupgrade=yes
```
1. Flush the DNS cache:
```
ipconfig /flushdns
```
1. Verify the configuration:
```
netsh dns show global
```
## macOS configuration
Follow these steps to configure macOS clients using a mobile configuration profile for DoH with access tokens.
Create a mobile configuration profile with the following structure:
```
PayloadContent
DNSSettings
DNSProtocol
HTTPS
ServerAddresses
3.3.3.3
3.3.3.4
ServerURL
https://a1bc234567890a.route53globalresolver.global.on.aws/dns-query?token=
PayloadType
com.apple.dnsSettings.managed
```
Install the profile through System Settings > Device Management.
# Access control best practices and security considerations
Follow these best practices to maintain secure and effective access controls for your Route 53 Global Resolver infrastructure.
## Security best practices
Implement these security measures to protect your DNS infrastructure:
+ **Use layered authentication** - Combine access sources for trusted networks with tokens for mobile users. This approach provides defense in depth and accommodates different client scenarios.
+ **Implement least privilege access** - Grant access only to the IP ranges and protocols that clients actually need. Avoid overly broad access source rules that could expose your infrastructure to unauthorized use.
+ **Rotate tokens regularly** - Replace access tokens on a regular schedule, even before they expire. This practice limits the impact of compromised tokens and maintains security hygiene.
+ **Monitor access patterns** - Review DNS query logs to identify unusual access patterns or potential security issues. Set up alerts for queries from unexpected IP ranges or using expired tokens.
## Operational best practices
Follow these operational practices to maintain reliable access controls:
+ **Document your access control strategy** - Maintain clear documentation of which access sources and tokens serve which client groups.
+ **Test access controls regularly** - Verify that your access source rules and tokens work correctly from different client locations and scenarios.
+ **Plan for token renewal** - Establish processes for distributing new tokens before old ones expire to avoid service disruptions.
+ **Review access controls periodically** - Remove unused access source rules and expired tokens to maintain a clean configuration.
# Securing DNS for clients with Route 53 Global Resolver
The following sections describe how to create rules to secure DNS queries made by your clients.
**Topics**
+ [Configure and manage DNS Firewall rules](gr-configure-manage-firewall-rules.md)
+ [Managed Domain Lists](gr-managed-domain-lists.md)
+ [Build domain lists](gr-build-domain-lists.md)
+ [DNS Firewall Advanced protections](gr-dns-firewall-advanced-protections.md)
+ [Manage security policies](gr-manage-dns-security-policies.md)
# Configure and manage DNS Firewall rules
## Creating and viewing firewall rules
Firewall rules define how Route 53 Global Resolver handles DNS queries based on domain lists, managed domain lists, content categories, or advanced threat protection. Each rule specifies a priority, target domains, and an action to take.
**Best practices for rule priority:**
+ Use priority 100-999 for high-priority allow rules (trusted domains)
+ Use priority 1000-4999 for block rules (known threats)
+ Use priority 5000-9999 for alert rules (monitoring and analysis)
+ Leave gaps between priorities to allow for future rule insertion
**To create a DNS Firewall rule**
1. In the Route 53 Global Resolver console, navigate to your DNS view.
1. Choose the **Firewall rules** tab.
1. Choose **Create firewall rule**.
1. In the **Rule details** section:
1. For **Rule name**, enter a descriptive name for the rule (up to 128 characters).
1. (Optional) For **Rule description**, enter a description for the rule (up to 255 characters).
1. In the **Rule configuration** section, choose the **Rule configuration type**:
+ **Customer managed domain lists** - Use a domain list that you create and manage
+ **AWS managed domain lists** - Use domain lists provided by Amazon that you can utilize
+ **DNS Firewall Advanced protections** - Choose from a range of managed protections and specify a confidence threshold
1. For **Rule action**, choose the action to take when the rule matches:
+ **Allow** - The DNS query is resolved
+ **Alert** - Allows the DNS query but creates an alert
+ **Block** - The DNS query is blocked
1. Choose **Create firewall rule**.
Use the following procedure to view the rules assigned to them. You can also update the rule and rule settings.
**To view and update a rule**
1. In the Route 53 Global Resolver console, navigate to your DNS View.
1. Choose the **DNS Firewall rules** tab.
1. Choose the rule you want to view or edit, and choose **Edit**.
1. In the **Rule** page, you can view and edit settings.
For information about the values for rules, see [Rule settings in DNS Firewall](#gr-rule-settings-dns-firewall).
**To delete a rule**
1. In the Route 53 Global Resolver console, navigate to your DNS View.
1. Choose the **DNS Firewall rules** tab.
1. Choose the rule you want to delete, and choose **Delete**, and confirm the deletion.
## Rule settings in DNS Firewall
When you create or edit a DNS Firewall rule in your DNS View, you specify the following values:
Name
A unique identifier for the rule in the DNS View.
(Optional) Description
A short description that provides more information about the rule.
Domain list
The list of domains that the rule inspects for. You can create and manage your own domain list or you can subscribe to a domain list that AWS manages for you.
A rule can contain ether a domain list or a DNS Firewall Advanced protection, but not both.
Query type (domain lists only)
The list of DNS query types that the rule inspects for. The following are the valid values:
+ A: Returns an IPv4 address.
+ AAAA: Returns an Ipv6 address.
+ CAA: Restricts CAs that can create SSL/TLS certifications for the domain.
+ CNAME: Returns another domain name.
+ DS: Record that identifies the DNSSEC signing key of a delegated zone.
+ MX: Specifies mail servers.
+ NAPTR: Regular-expression-based rewriting of domain names.
+ NS: Authoritative name servers.
+ PTR: Maps an IP address to a domain name.
+ SOA: Start of authority record for the zone.
+ SPF: Lists the servers authorized to send emails from a domain.
+ SRV: Application specific values that identify servers.
+ TXT: Verifies email senders and application-specific values.
A query type you define by using the DNS type ID, for example 28 for AAAA. The values must be defined as TYPE`NUMBER`, where the `NUMBER` can be 1-65334, for example, TYPE28. For more information, see [List of DNS record types](https://en.wikipedia.org/wiki/List_of_DNS_record_types).
You can create one query type per rule.
DNS Firewall Advanced protection
Detects suspicious DNS queries based on known threat signatures in DNS queries. You can choose protection from:
+ Domain Generation Algorithms (DGAs)
DGAs are used by attackers to generate a large number of domains to launch malware attacks.
+ DNS tunneling
DNS tunneling is used by attackers to exfiltrate data from the client by using the DNS tunnel without making a network connection to the client.
In a DNS Firewall Advanced rule you can choose to either block, or alert on a query that matches the threat.
For more information, see DNS Firewall Advanced protections.
A rule can contain ether a DNS Firewall Advanced protection or a domain list, but not both.
Confidence threshold (DNS Firewall Advanced only)
The confidence threshold for DNS Firewall Advanced. You must provide this value when you create a DNS Firewall Advanced rule. The confidence level values mean:
+ High – Detects only the most well corroborated threats with a low rate of false positives.
+ Medium – Provides a balance between detecting threats and false positives.
+ Low – Provides the highest detection rate for threats, but also increases false positives.
For more information, see Rule settings in DNS Firewall.
Action
How you want DNS Firewall to handle a DNS query whose domain name matches the specifications in the rule's domain list. For more information, see [Rule actions in DNS Firewall](#gr-rule-actions-dns-firewall).
Priority
Unique positive integer setting for the rule within the DNS View that determines processing order. DNS Firewall inspects DNS queries against the rules in a DNS View starting with the lowest numeric priority setting and going up. You can change a rule's priority at any time, for example to change the order of processing or make space for other rules.
## Rule actions in DNS Firewall
When DNS Firewall finds a match between a DNS query and a domain specification in a rule, it applies the action that's specified in the rule to the query.
You are required to specify one of the following options in each rule that you create:
+ **Allow** – Stop inspecting the query and permit it to go through. Not available for DNS Firewall Advanced.
+ **Alert** – Stop inspecting the query, permit it to go through, and log an alert for the query in the Route 53 Resolver logs.
+ **Block** – Discontinue inspection of the query, block it from going to its intended destination, and log the block action for the query in the Route 53 Resolver logs.
Reply with the configured block response, from the following:
+ **NODATA** – Respond indicating that the query was successful, but no response is available for it.
+ **NXDOMAIN**– Respond indicating that the query's domain name doesn't exist.
+ **OVERRIDE**– Provide a custom override in the response. This option requires the following additional settings:
+ **Record value** – The custom DNS record to send back in response to the query.
+ **Record type**– The DNS record's type. This determines the format of the record value. This must be `CNAME`.
+ **Time to live in seconds**– The recommended amount of time for the DNS resolver or web browser to cache the override record and use it in response to this query, if it is received again. By default, this is zero, and the record isn't cached.
# Managed Domain Lists for Route 53 Global Resolver
Managed Domain Lists contain domain names that are associated with malicious activity or other potential threats. AWS maintains these lists to enable Route 53 Global Resolver customers to check internet-bound DNS queries against them when using DNS Firewall.
Keeping up to date on the constantly changing threat landscape can be time consuming and expensive. Managed Domain Lists can save you time when you implement and use DNS Firewall on Global Resolver. AWS automatically updates the lists when new vulnerabilities and threats emerge.
Managed domain lists are categorized into Threat and Content categories, designed to help protect you from common web threats and also block query resolution to domain not safe-for-work.
As a best practice, before using a Managed Domain List in production, test it in a non-production environment, with the rule action set to `Alert`. Evaluate the rule using Amazon CloudWatch metrics combined with DNS Firewall sampled requests or Global Resolver logs. When you're satisfied that the rule does what you want, change the action setting as needed.
## Available AWS Managed Domain Lists
This section describes the Managed Domain Lists that are currently available for Global Resolver. AWS provides the following Managed Domain Lists, for all users of Global Resolver, classified by **Threat** or **Content** Type.
**Threat Categories**
| |
| --- |
| Malware |
| Botnet/Command and Control |
| Aggregate Threat List |
| Amazon GuardDuty Threat List |
| Phishing |
| Spam |
**Content Categories**
| |
| --- |
| Violence and Hate Speech |
| For Kids |
| Online Ads |
| Science |
| Family and Parenting |
| Pets |
| Career and Job Search |
| Religion |
| Lifestyle |
| Home and Garden |
| Criminal and Illegal Activities |
| Sports and Recreation |
| Vehicles |
| Financial Services |
| Real Estate |
| Hobbies and Interests |
| Travel |
| Food and Dining |
| Government and Legal |
| Education |
| Fashion |
| Health |
| Shopping |
| Adult and Mature Content |
| Technology and Internet |
| Business and Economy |
| News |
| Search Engines and Portals |
| Arts and Culture |
| Entertainment |
| Military |
| Social Networking |
| Proxy Avoidance |
| Redirect |
| Email |
| Translation |
| Child Abuse |
| Abortion |
| Gambling |
| Hacking |
| Marijuana |
| Cryptocurrency |
| Dating |
| Artificial Intelligence and Machine Learning |
| Parked Domains |
| Private IP Address |
Managed Domain Lists cannot be downloaded or browsed. To protect intellectual property, you can't view or edit the individual domain specifications within the Managed Domain Lists. This restriction also helps to prevent malicious users from designing threats that specifically circumvent published lists.
# Build lists of domains to block or allow
You can create your own domain lists to specify domain categories that you either don't find in the managed domain list offerings or that you prefer to handle on your own.
In addition to the procedures described in this section, in the console, you can create a domain list in the context of DNS Firewall rule management, when you create or update a rule.
Each domain specification in your domain list must satisfy the following requirements:
+ It can optionally start with `*` (asterisk).
+ With the exception of the optional starting asterisk and a period, as a delimiter between labels, it must only contain the following characters: `A-Z`, `a-z`, `0-9`, `-` (hyphen).
+ It must be from 1-255 characters in length.
**To create a domain list**
1. In the Route 53 Global Resolver console, navigate to your Global Resolver.
1. Choose the **Domain lists** tab.
1. Choose **Create domain list**.
1. Provide a name and optional description for your domain list, along with any tags, and select **Create domain list**.
1. Once created and operational, you can begin adding domains to your domain list by selecting **Add domains**.
1. If you choose to **Upload a list of domains from an Amazon S3 bucket**, enter the URI of the Amazon S3 bucket where you created a domain list. This domain list should have one domain name per line.
1. Otherwise, enter your domain specifications in the text box, one per line.
1. Choose **Add domains**.
**To delete a domain list**
1. In the Route 53 Global Resolver console, navigate to your Global Resolver.
1. Choose the **Domain lists** tab.
1. Select the domain list that you want to delete, then choose **Delete**, and confirm the deletion.
# DNS Firewall Advanced protections
DNS Firewall Advanced detects suspicious DNS queries based on known threat signatures in DNS queries. You can specify a threat type in a rule that you use in a DNS Firewall rule, associated with a DNS View.
DNS Firewall Advanced works by identifying suspicious DNS threat signatures by inspecting a range of key identifiers in the DNS payload including the timestamp of requests, frequency of request and responses, the DNS query strings, and the length, type or size of both outbound and inbound DNS queries. Based on the type of threat signature, you can configure policies to block, or simply log and alert on the query. By using an expanded set of threat identifiers, you can protect against DNS threats from domain sources that may yet be unclassified by threat intelligence feeds maintained by the broader security community.
Currently, DNS Firewall Advanced offers protections from:
+ Domain Generation Algorithms (DGAs)
DGAs are used by attackers to generate a large number of domains to launch malware attacks.
+ Dictionary DGA
Detect DGA attacks that use domain names associated with dictionary words in large numbers to perform malicious command and control DNS communications.
+ DNS tunneling
DNS tunneling is used by attackers to exfiltrate data from the client by using the DNS tunnel without making a network connection to the client.
To learn how to create rules, see [Configure and manage DNS Firewall rules](gr-configure-manage-firewall-rules.md).
## Mitigating false positive scenarios
If you are encountering false-positive scenarios in rules that use DNS Firewall Advanced protections to block queries, perform the following steps:
1. In the Global Resolver logs, identify the rule and DNS Firewall Advanced protections that are causing the false positive. You do this by finding the log for the query that DNS Firewall is blocking, but that you want to allow through. The log record lists the DNS View, the rule, rule action, and the DNS Firewall Advanced protection.
1. Create a new rule in the DNS View that explicitly allows the blocked query through. When you create the rule, you can define your own domain list with just the domain specification that you want to allow. Follow the guidance for rule management at [Configure and manage DNS Firewall rules](gr-configure-manage-firewall-rules.md).
1. Prioritize the new rule inside the rule so that it runs before the rule that's using the managed list. To do this, give the new rule a lower numeric priority setting.
When you have updated your rules, the new rule will explicitly allow the domain name that you want to allow before the blocking rule runs.
# Manage DNS security policies in Route 53 Global Resolver
## Managing global resolvers
After creating a global resolver, you can view its details, edit its configuration, and manage associated resources from the Global Resolvers page.
### Viewing resolver details
The Global Resolvers page displays a list of all your resolvers with key information including resolver name, deployed regions, associated DNS views, observability region, and operational status.
### Editing global resolvers
You can modify the resolver name and description after creation. You cannot modify the regions where a global resolver is deployed after creation.
## Managing firewall rules
After creating firewall rules, you can modify their priority, update their configuration, or delete them as needed.
### Rule priority and evaluation order
Firewall rules are evaluated in priority order, with lower numbers processed first. When a query matches multiple rules, only the first matching rule's action is applied.
### Updating firewall rules
You can update most aspects of a firewall rule after creation, including its priority, action, and target domains.
# Configuring private hosted zone associations with Route 53 Global Resolver
Route 53 Global Resolver enables you to resolve records associated with your Route 53 private hosted zones from your authorized clients. You can associate the Route 53 private hosted zones with the DNS view that your clients authorized with the DNS view is allowed to resolve.
**Topics**
+ [Manage private hosted zone associations](gr-private-hosted-zone-associations.md)
# Manage private hosted zone associations with Route 53 Global Resolver
## Creating private hosted zones for internal applications
Before you can associate a private hosted zone with a DNS view, you must first create the zone using the Amazon Route 53 console or API.
**To create a private hosted zone**
1. Open the Amazon Route 53 console at [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. In the navigation pane, choose **Hosted zones**.
1. Choose **Create hosted zone**.
1. For **Domain name**, enter the domain name for your private zone (for example, `internal.example.com`).
1. For **Type**, choose **Private hosted zone**.
1. For **VPCs to associate with the hosted zone**, choose the VPCs you want to associated with the hosted zone. Optionally, you can use the `CreateHostedZone` API operation to skip entering a value since you'll be associating the zone with Route 53 Global Resolver instead.
1. Choose **Create hosted zone**.
After creating the private hosted zone, add the DNS records you need for your internal services.
## Associating private hosted zones with DNS views
To enable Route 53 Global Resolver to resolve queries for your private hosted zone, you must associate the zone with one or more DNS views.
**To associate a private hosted zone with a DNS view**
1. In the Route 53 Global Resolver console, navigate to your global resolver.
1. Choose the DNS view where you want to associate the private hosted zone.
1. In the **Private hosted zones** section, choose **Associate hosted zone**.
1. For **Hosted zone**, select the private hosted zone you want to associate.
1. For **Association name**, enter a descriptive name for this association.
1. Choose **Associate hosted zone**.
The association process typically takes a few minutes to complete. Once complete, Route 53 Global Resolver will use the records in the private hosted zone to answer DNS queries from client devices associated with the DNS view.
# Monitoring DNS activity and performance with Route 53 Global Resolver
Route 53 Global Resolver provides comprehensive visibility into DNS activity across your organization, enabling you to identify security threats, analyze client device behavior, and maintain compliance. This chapter covers both the monitoring tools available and detailed procedures for setting up DNS monitoring, configuring logging destinations, and analyzing DNS data to investigate threats and optimize performance.
AWS provides these monitoring tools to help you maintain secure, reliable DNS service:
+ *Amazon CloudWatch Logs* enables you to monitor, store, and access your log files from Amazon EC2 instances, CloudTrail, and other sources. Route 53 Global Resolver can deliver DNS query logs directly to CloudWatch Logs for real-time monitoring and analysis. You can also archive your log data in highly durable storage. For more information, see the [Amazon CloudWatch Logs User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
+ You can use metric filters to search and filter log data coming into CloudWatch Logs and create CloudWatch metrics from the log events. Use these metrics to track DNS query volumes, response times, and security events. You can also create dashboards to monitor DNS performance across locations and set up alarms to notify you when query volumes spike or response times increase. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ *Amazon EventBridge* can be used to automate your AWS services and respond automatically to system events, such as application availability issues or resource changes. Events from AWS services are delivered to EventBridge in near real time. You can write simple rules to indicate which events are of interest to you and which automated actions to take when an event matches a rule. For more information, see [Amazon EventBridge User Guide](https://docs.aws.amazon.com/eventbridge/latest/userguide/).
+ *AWS CloudTrail* captures API calls and related events made by or on behalf of your AWS account and delivers the log files to an Amazon S3 bucket that you specify. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred. For more information, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
**Topics**
+ [Gain DNS visibility](gr-gain-visibility-into-dns-activity.md)
+ [Configure DNS monitoring](gr-configure-dns-monitoring.md)
# Gain visibility into DNS activity with Route 53 Global Resolver
Route 53 Global Resolver provides comprehensive DNS query logging capabilities to monitor client device activity and identify security threats. Enable DNS query logging in Route 53 Global Resolver to see what websites client devices access, identify potential security threats, and analyze DNS resolution patterns. Logs capture comprehensive information about each query, including which security policies were applied.
## What information is captured in DNS logs
Each DNS query log entry provides detailed information about client device activity and security policy enforcement:
+ **Query information** - Domain name, query type, query class, and protocol used
+ **Client device information** - Source IP address, DNS view, and authentication method
+ **Response information** - Response code, answer records, and response time
+ **Security actions** - Firewall rule matches, threat detection results, and actions taken
+ **Metadata** - Timestamp, global resolver ID, Region, and trace information
## OCSF format for security integration
DNS query logs use the Open Cybersecurity Schema Framework (OCSF), which provides a standardized format for security event data. This format enables:
+ **Standardized analysis** - Consistent schema across different security tools
+ **Improved interoperability** - Easy integration with SIEM and analytics platforms
+ **Enhanced correlation** - Ability to correlate DNS events with other security data
+ **Future compatibility** - Support for evolving security analysis requirements
### OCSF log format examples
Route 53 Global Resolver DNS query logs follow the OCSF schema structure, providing detailed information about each DNS query, response, and security action. The following examples show the log format for allowed and denied queries.
#### Route 53 Global Resolver DNS log - Access allowed example
This example shows a DNS query that was allowed through firewall rules. The log includes query details, response information, and enrichment data with Route 53 Global Resolver-specific identifiers.
```
{
"action_id": 1,
"action_name": "Allowed",
"activity_id": 6,
"activity_name": "Traffic",
"category_name": "Network Activity",
"category_uid": 4,
"class_name": "DNS Activity",
"class_uid": 4003,
"cloud": {
"provider": "AWS",
"region": "us-east-1",
"account": {
"uid": "123456789012"
}
},
"connection_info": {
"direction": "Inbound",
"direction_id": 1,
"protocol_name": "udp",
"protocol_num": 17,
"protocol_ver": "",
"uid": "db21d1739ddb423a"
},
"duration": 1,
"end_time": 1761358379996,
"answers": [{
"rdata": "3.3.3.3",
"type": "A",
"class": "IN",
"ttl": 300
},
{
"rdata": "3.3.3.4",
"type": "A",
"class": "IN",
"ttl": 300
}],
"src_endpoint": {
"ip": "3.3.3.1",
"port": 56576
},
"enrichments": [{
"name": "global-resolver",
"value": "gr-a1b2c3d4fexample",
"data": {
"dns_view_id": "dnsv-a1b2c3d4fexample",
"firewall_rule_id": "fr-a1b2c3d4fexample",
"token_id": "t-a1b2c3d4fexample",
"token_name": "device-123456",
"token_expiration": "1789419206",
"access_source_cidr": "3.3.3.0/24",
}
}],
"message": "",
"metadata": {
"version": "1.2.0",
"product": {
"name": "Global Resolver",
"vendor_name": "AWS",
"feature": {
"name": "DNS"
}
}
},
"query": {
"hostname": "example.com.",
"class": "IN",
"type": "A",
"opcode": "Query",
"opcode_id": 0
},
"query_time": 1761358379995,
"rcode": "NOERROR",
"rcode_id": 0,
"response_time": 1761358379995,
"severity": "Informational",
"severity_id": 1,
"src_endpoint": {
"ip": "3.3.3.3",
"port": 28276
},
"start_time": 1761358379995,
"status": "Success",
"status_id": 1,
"time": 1761358379995,
"type_name": "DNS Activity: Traffic",
"type_uid": 400306
}
```
#### Route 53 Global Resolver DNS log - Access denied example
This example shows a DNS query that was blocked by firewall rules. The log includes the denial action, empty answers array, and REFUSED response code indicating the query was not processed.
```
{
"action_id": 2,
"action_name": "Denied",
"activity_id": 6,
"activity_name": "Traffic",
"category_name": "Network Activity",
"category_uid": 4,
"class_name": "DNS Activity",
"class_uid": 4003,
"cloud": {
"provider": "AWS",
"region": "us-west-2",
"account": {
"uid": "123456789012"
}
},
"connection_info": {
"direction": "Inbound",
"direction_id": 1,
"protocol_name": "tcp",
"protocol_num": 6,
"protocol_ver_id": 4,
"uid": "9fdc6fbc09794d5e"
},
"duration": 1,
"end_time": 1761358379996,
"answers": [],
"src_endpoint": {
"ip": "3.3.3.3",
"port": 28276
},
"enrichments": [
{
"name": "global-resolver",
"value": "gr-a1b2c3d4fexample",
"data": {
"dns_view_id": "dnsv-a1b2c3d4fexample",
"firewall_rule_id": "fr-a1b2c3d4fexample",
"token_id": "t-a1b2c3d4fexample",
"token_name": "device-123456",
"token_expiration": "1789419206",
"access_source_cidr": "3.3.3.0/24",
}
}
],
"message": "",
"metadata": {
"version": "1.2.0",
"product": {
"name": "Global Resolver",
"vendor_name": "AWS",
"feature": {
"name": "DNS"
}
}
},
"query": {
"hostname": "example.com.",
"class": "IN",
"type": "A",
"opcode": "Query",
"opcode_id": 0
},
"query_time": 1761358379995,
"rcode": "REFUSED",
"rcode_id": 5,
"response_time": 1761358379995,
"severity": "Informational",
"severity_id": 1,
"start_time": 1761358379995,
"status": "Failure",
"status_id": 1,
"time": 1761358379995,
"type_name": "DNS Activity: Traffic",
"type_uid": 400306
}
```
# Configure DNS monitoring and logging with Route 53 Global Resolver
Configure DNS monitoring in Route 53 Global Resolver to capture detailed information about DNS queries, responses, and security actions. This section covers the steps to set up logging destinations and configure monitoring tools.
## Setting the observability Region
Before configuring DNS logging, you must set an observability Region where logs and metrics will be stored. This region determines where your monitoring data is processed and stored.
1. Open the Route 53 Global Resolver console at [https://console.aws.amazon.com/route53globalresolver/](https://console.aws.amazon.com/route53globalresolver/).
1. In the navigation pane, choose **Settings**.
1. In the **Observability region** section, choose **Set region**.
1. Select the AWS Region where you want to store monitoring data, then choose **Set region**.
After setting the observability region, you can configure log delivery destinations in that region.
# Troubleshooting DNS issues with Route 53 Global Resolver
Route 53 Global Resolver provides comprehensive DNS resolution capabilities, but occasionally you may need to troubleshoot connectivity, performance, or configuration issues. Use DNS logs, monitoring data, and diagnostic techniques to identify and resolve issues affecting client device DNS resolution with Route 53 Global Resolver. This chapter provides systematic approaches to troubleshooting common DNS problems and optimizing performance.
**Topics**
+ [Diagnose connectivity issues](gr-diagnose-connectivity-issues.md)
+ [Resolve performance issues](gr-resolve-performance-issues.md)
+ [Troubleshoot configuration](gr-troubleshoot-configuration-issues.md)
+ [Troubleshooting internal resource access](#gr-troubleshooting-internal-access)
# Diagnose DNS connectivity issues with Route 53 Global Resolver
Route 53 Global Resolver provides reliable DNS resolution, but connectivity issues can occasionally occur due to configuration, authentication, or network problems. When client devices cannot resolve domain names using Route 53 Global Resolver, use these systematic approaches to identify and resolve connectivity problems.
## Client devices cannot resolve domains
Follow these steps to diagnose resolution failures:
1. **Verify queries reach the global resolver**
+ Check DNS query logs for queries from the affected client device IP address
+ Confirm the client device is configured with the correct anycast IP addresses
+ Test network connectivity from the client device to the anycast IPs
1. **Check client device authentication**
+ Verify the client device is authenticated to the correct DNS view
+ Check Access Source rules for the client device's IP address or CIDR block
+ Confirm access tokens are valid and not expired (for token-based authentication)
1. **Review firewall rules**
+ Check if firewall rules are blocking the queries
+ Review rule priority and ensure allow rules have higher priority than block rules
+ Verify firewall fail-open behavior settings
1. **Confirm DNS view associations**
+ Verify private hosted zone associations for internal domains
+ Check that DNS records exist in the associated private hosted zones
+ Ensure domain names in queries exactly match zone names
## Intermittent resolution failures
For sporadic DNS resolution issues, investigate these potential causes:
Authentication issues
+ Check for access token expiration and renewal patterns
+ Review authentication logs for failed authentication attempts
+ Verify client device clock synchronization for token validation
Network connectivity
+ Monitor for network path changes or routing issues
+ Check for firewall or NAT device configuration changes
+ Verify consistent anycast routing to the nearest Region
Service health
+ Check AWS Service Health Dashboard for Route 53 Global Resolver issues
+ Review CloudWatch metrics for error rate spikes
+ Monitor private hosted zone association status
## Unexpected public resolution
When queries resolve to public DNS instead of private hosted zones:
1. **Verify private hosted zone configuration**
+ Confirm the private hosted zone contains the expected DNS records
+ Check that record names exactly match the queried domain
+ Verify record types match the query type (A, AAAA, CNAME, etc.)
1. **Check DNS view associations**
+ Verify the private hosted zone is associated with the correct DNS view
+ Confirm the client device is authenticated to the DNS view
+ Check association status in the console
1. **Review firewall rules**
+ Check for firewall rules that might be blocking private zone queries
+ Verify rule evaluation order and priority
+ Review DNS query logs for firewall actions
# Resolve DNS performance issues with Route 53 Global Resolver
Route 53 Global Resolver is designed for optimal performance with global anycast architecture, but various factors can affect DNS resolution speed. Address slow DNS resolution and optimize query response times for better client device performance using Route 53 Global Resolver.
## Slow DNS resolution
To diagnose and resolve slow DNS response times:
1. **Analyze query response times**
+ Use DNS query logs to identify queries with high response times
+ Compare response times across different domains and query types
+ Monitor response time trends over time
1. **Check for high query volumes**
+ Monitor CloudWatch metrics for query volume spikes
+ Identify client devices or DNS views generating excessive queries
+ Look for query patterns that might indicate misconfigurations
1. **Review cache performance**
+ Analyze cache hit rates for frequently queried domains
+ Review TTL settings for DNS records
+ Consider adjusting TTL values based on query patterns
1. **Verify optimal Region selection**
+ Ensure global resolver regions are close to client device locations
+ Monitor anycast routing to confirm queries reach the nearest Region
+ Consider adding regions if client devices are geographically distant
## Performance optimization strategies
Use these strategies to optimize DNS performance:
Cache optimization
+ Adjust TTL values based on query patterns and change frequency
+ Use longer TTLs for stable records, shorter TTLs for frequently changing records
+ Monitor cache hit rates and adjust TTLs accordingly
Region optimization
+ Deploy global resolver in regions closest to client device concentrations
+ Monitor query routing patterns and response times by region
+ Consider adding regions for better geographic coverage
Protocol optimization
+ Choose appropriate DNS protocols based on security and performance requirements
+ Consider DNS-over-HTTPS (DoH) for encrypted connections with caching benefits
+ Use DNS-over-TLS (DoT) for encrypted connections with lower overhead
Rule optimization
+ Review and optimize firewall rule priority and complexity
+ Place frequently matched rules higher in priority order
+ Simplify complex rule conditions where possible
# Troubleshoot configuration issues in Route 53 Global Resolver
Route 53 Global Resolver offers extensive configuration options for DNS views, authentication, and firewall rules, which can sometimes lead to configuration conflicts or mismatches. Identify and resolve common Route 53 Global Resolver configuration problems that affect DNS resolution.
## Authentication problems
Common authentication issues and solutions:
Access Source rule mismatches
+ Verify client device IP addresses match configured CIDR blocks
+ Check for NAT or proxy devices changing source IP addresses
+ Ensure Access Source rules cover all expected client device IP ranges
Token authentication failures
+ Verify tokens are correctly configured on client devices
+ Check token expiration dates and renewal processes
+ Ensure client device clocks are synchronized for token validation
Protocol mismatches
+ Verify client devices use protocols allowed by Access Source rules
+ Check that DoH and DoT configurations match token protocols
+ Ensure firewall rules don't block required protocols
## DNS view configuration issues
Common DNS view configuration problems:
Incorrect DNS view associations
+ Verify client devices are authenticated to the intended DNS view
+ Check that private hosted zones are associated with the correct DNS views
+ Review firewall rules applied to each DNS view
DNS settings conflicts
+ Review DNSSEC validation settings for compatibility with client devices
+ Check EDNS Client Subnet settings for privacy and performance balance
+ Verify firewall fail-open behavior aligns with security requirements
## Firewall rule issues
Common firewall rule configuration problems:
Rule priority conflicts
+ Review rule evaluation order and ensure correct priority assignment
+ Check for block rules with higher priority than intended allow rules
+ Test rule changes in a controlled environment before production deployment
Domain list mismatches
+ Verify domain specifications in custom domain lists
+ Check wildcard patterns for correct syntax and coverage
+ Ensure domain lists are updated and synchronized
## Troubleshooting internal resource access
Common issues and solutions when managing internal resource access:
Client devices not resolving to private zone records
+ Verify the private hosted zone is associated with the correct DNS view
+ Check that the client device is authenticated to the correct DNS view
+ Ensure the domain name in the query exactly matches the zone name
+ Verify the DNS records exist in the private hosted zone
Intermittent resolution failures
+ Check the association status in the console
+ Review DNS query logs for error patterns
+ Verify network connectivity between Route 53 Global Resolver and Amazon Route 53
Unexpected public resolution
+ Confirm the private hosted zone contains the expected records
+ Check for firewall rules that might be blocking the query
+ Verify the query is coming from a client device associated with the DNS view
# Quotas for Route 53 Global Resolver
Your AWS account has default quotas, formerly referred to as limits, for each AWS service. Unless otherwise noted, each quota is Region-specific. You can request increases for some quotas, and other quotas cannot be increased.
To view the quotas for Route 53 Global Resolver, open the [Service Quotas console](https://console.aws.amazon.com/servicequotas/home). In the navigation pane, choose **AWS services** and select **Route 53 Global Resolver**.
To request a quota increase, see [Requesting a Quota Increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in the *Service Quotas User Guide*. If the quota is not yet available in Service Quotas, use the [limit increase form](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase).
Your AWS account has the following quotas related to Route 53 Global Resolver.
## Soft quotas
The following table describes quotas in Route 53 Global Resolver that can be increased. For information about changing quotas, see [Requesting a Quota Increase](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) in the *Service Quotas User Guide*.
For some customers, your account quota might be below these published quotas. If you believe that you encountered a *Resource limit exceeded* error wrongfully, use the [Service Quotas console](https://console.aws.amazon.com/servicequotas/home) to request quota increases.
| Resource | Default quota | Adjustable |
| --- | --- | --- |
| Global resolvers per account | 2 | Yes |
| DNS views per global resolver | 5 | Yes |
| DNS views per account | 50 | Yes |
| Domain lists per account | 1,000 | Yes |
| Domains per domain list | 100,000 | Yes |
| Domains per account | 100,000 | Yes |
| Domains in a file imported from S3 | 10,000 | Yes |
| Number of domains referenced across all Firewall Rules | 1,000,000 | Yes |
| Firewall rules per DNS view | 100 | Yes |
| Access tokens per global resolver | 5,000 | Yes |
| Access Sources per global resolver | 1,000 | Yes |
| Access Sources CIDR size per global resolver | 65,000 | No |
| Private hosted zones per DNS view | 1,000 | Yes |