Setting Up Route53 Global Resolver

Domain expertise for setting up a Route 53 Global Resolver instance: an anycast DNS endpoint that on-premises and remote clients use to resolve both public domains and Route 53 private hosted zones, without per-location DNS infrastructure. Covers the resource hierarchy and ordering, the multi-Region requirement, the per-DNS-view authentication choice, optional DNS firewall, and private hosted zone access.

Does not cover integration with resolver endpoints for hybrid networks (a separate skill) or hosted zone and record management.

All Global Resolver API calls are made in us-east-2 regardless of which Regions the resolver itself is deployed to. The control plane runs in US East (Ohio); calls without --region us-east-2 fail with a confusing endpoint or authorization error.

Execute commands using the AWS MCP server when connected (sandboxed execution, audit logging, observability). Fall back to the AWS CLI otherwise.

Table of Contents

• Overview
• Workflow
• Resource hierarchy and order
• Decision: which Regions to deploy to
• Decision: token-based vs IP-based access (per DNS view)
• Token expiration and protocol scope
• Decision: one DNS view vs many
• Decision: firewall rule shape
• Decision: block action mode
• Troubleshooting
• Procedure
• Additional Resources

Workflow

To build a Global Resolver instance, follow the procedure exactly. See the Procedure section below.

The procedure covers:

• Creating the resolver with the right Region set, observability Region, and IP address type
• Creating one DNS view per client group that needs distinct policy
• Adding access sources, access tokens, or both, per DNS view
• Adding firewall rules per view: domain-list rules (custom or AWS-managed lists) or advanced threat protection rules (domain generation algorithm (DGA) detection, including dictionary DGA, and DNS tunneling detection)
• Associating private hosted zones to a DNS view
• Pointing clients at the two anycast IPs and surfacing the console link to verify

Resource hierarchy and order

Global Resolver resources are nested. Create them outside-in:

Firewall domain lists live at the Global Resolver level, not on a DNS view. One custom list can be referenced from rules on multiple views. AWS-managed lists are pre-existing and do not need to be created; reference them by ID directly from a rule. Two types are available:

• THREAT: Malware, Botnet command-and-control, Spam, Phishing, Amazon GuardDuty threat intelligence
• CONTENT: content categories such as social media and gambling

Constraints:

• You MUST create resources in this order: Global Resolver, then any custom firewall domain lists, then DNS views, then per-view access sources and tokens (and any firewall rules or hosted zone associations), then point clients at the anycast IPs. A domain-list firewall rule cannot be created until both its DNS view and the firewall domain list it references exist
• You MUST add at least one access source or one access token to each DNS view that needs to serve clients. A view with neither authorizes nothing
• create-global-resolver returns two anycast IPv4 addresses (and two IPv6 addresses if --ip-address-type DUAL_STACK was set). You MUST configure clients with both, not just one
• Each Create call returns status: CREATING. You MUST poll the corresponding get-* call until status is OPERATIONAL before using the resource downstream

Decision: which Regions to deploy to

Constraints:

• You MUST select at least two Regions for any production setup
• You MUST set --observability-region at create time. It names the Region that query logs are delivered from, and is needed even if logging is not configured yet, so the customer can enable it later without recreating the resolver
• update-global-resolver accepts a new --regions set, but adding a Region is a time-consuming operation because the new Region has to provision and replicate state before serving traffic. Pick the initial set deliberately

Decision: token-based vs IP-based access (per DNS view)

Authentication is configured on the DNS view, not on the resolver as a whole. A view can have access sources, access tokens, or both, so a single resolver can serve roaming clients (token) on one view and branch offices (IP) on another, or mix both kinds on the same view.

Constraints:

• You MUST help the customer pick correctly per population. IP-based for roaming clients behind shared network address translation (NAT) leaks access to anyone sharing the NAT IP; token-based for a large fixed fleet creates token-rotation pain across thousands of devices
• Access source --protocol is DO53, DOT, or DOH (uppercase). For multiple CIDRs or multiple protocols on one view, create one access source per (CIDR, protocol) pair
• You SHOULD recommend DoT or DoH over Do53 for every client population that can support it, to encrypt queries in transit. Do53 transmits queries and responses in plaintext, exposing the queried domain names to on-path observers; reserve it for clients that genuinely cannot use an encrypted protocol

Token expiration and protocol scope

Two access-token traps surface as silent or partial failures.

Constraints:

• Access tokens authenticate DoT and DoH connections only, not Do53. A client resolving over Do53 will fail no matter what token it presents. For a Do53 population on the view, you MUST add an IP-based access source instead
• Access token expiration is bounded between 30 and 365 days from creation. You MUST set --expires-at within that window. The token value returned in the create response is the secret the client uses and is not retrievable later, so capture it at create time

Decision: one DNS view vs many

Constraints:

• You SHOULD set up DNS views during initial configuration. Retrofitting a second view after a flat policy is in production, with clients already pointed at it, requires re-issuing tokens or re-allocating CIDRs and is much more expensive

Decision: firewall rule shape

A firewall rule on a DNS view is one of two shapes. The shape decides what the rule matches and which actions are valid.

Constraints:

• Rules within a view are evaluated in priority order, lowest first; first match wins
• Advanced threat protection rules reject ALLOW. The API enforces this; algorithmic detection cannot definitively classify benign traffic
• Advanced rules carry --confidence-threshold (LOW, MEDIUM, HIGH). You SHOULD start at HIGH in ALERT mode, measure false positives, then lower or move to BLOCK from there

Decision: block action mode

A blocked query can be answered three ways. The wrong choice creates support cases that look like generic resolution failures.

Constraints:

• You MUST confirm the block mode with the customer rather than defaulting silently. The mode changes application behavior on a block
• For OVERRIDE, you MUST also supply --block-override-domain, --block-override-dns-type (the API only supports CNAME), and --block-override-ttl. The API rejects an OVERRIDE rule without all three

Troubleshooting

CLI command fails with an endpoint or authorization error

Missing --region us-east-2. Every Global Resolver API call goes to US East (Ohio) regardless of where the resolver is deployed.

DNS view exists but rejects every query

No access source and no access token on the view. A view authorizes nothing until at least one of either is created.

Token works for some clients but not others

Tokens authenticate DoT and DoH only, not Do53. Add an IP-based access source for the Do53 population, or move them to DoT or DoH.

Roaming clients intermittently lose access

IP-based access source used for clients with changing IPs. Switch the roaming population to a token-based access token; IP and token can coexist on the same view for a mixed population.

Clients cannot connect over the chosen protocol

The access source’s --protocol does not match the client operating system. Update with update-access-source --protocol DO53|DOT|DOH, or recreate if you also need to change the CIDR or IP address type. For DoT and DoH clients, also check the SNI entry below; a TLS handshake failure surfaces here too.

Private hosted zone records do not resolve

No hosted zone association on the DNS view. Associate the hosted zone to the view’s ARN and wait for status OPERATIONAL.

Firewall rule does not block the expected domains

A higher-priority rule on the same view halted inspection first, the rule references the wrong domain list, or the rule is on a different DNS view than the queries are coming through. Read the rule and the list contents to confirm:

DoT or DoH client fails to connect with a TLS error

The client is connecting to the anycast IP without setting the resolver’s dnsName as TLS server name indication (SNI). The certificate is bound to dnsName, not to the anycast IP. Set the SNI to the value of dnsName returned by get-global-resolver.

Application breaks confusingly after a firewall block

Block mode does not match how the application should fail. Recreate with NXDOMAIN, NODATA, or OVERRIDE per the block-mode decision.

IPv6 anycast addresses missing

The resolver was created without --ip-address-type DUAL_STACK. Update via update-global-resolver --ip-address-type DUAL_STACK to add the IPv6 anycast addresses.

Procedure

Overview

This procedure sets up a Route 53 Global Resolver instance: an anycast DNS endpoint for on-premises and remote clients. It creates the resolver, selects Regions and the observability Region, creates one or more DNS views, adds access sources and access tokens per view, optionally adds firewall rules and private hosted zone associations, points clients at the two anycast IPs, and surfaces the console link to verify.

Parameters

• resolver_name (required): A name for the Global Resolver instance.
• regions (required): The AWS Regions the resolver runs in. At least two for production.
• observability_region (required): The Region that query logs are delivered from. Must be one of the Regions in regions.
• ip_address_type (optional, default: IPV4): IPV4 or DUAL_STACK. DUAL_STACK adds two anycast IPv6 addresses alongside the two IPv4 addresses.
• dns_views (required): One or more DNS views, each with:
  • name
  • dnssec_validation: ENABLED or DISABLED
  • edns_client_subnet: ENABLED or DISABLED
  • firewall_rules_fail_open: ENABLED or DISABLED
  • access_sources: zero or more {cidr, protocol} pairs
  • tokens: zero or more {name, expires_at}
  • firewall_rules (optional): domain-list or advanced-threat rules, each with a priority
  • hosted_zone_associations (optional): private hosted zone IDs

Constraints for parameter acquisition:

• You MUST ask for all required parameters upfront in a single prompt
• You MUST confirm the Regions list, observability Region, and IP address type before any write operation
• You MUST confirm, per DNS view, which client populations it serves and whether each one needs IP-based access, token-based access, or both

Steps

1. Verify dependencies

Constraints:

• You MUST confirm credentials with aws sts get-caller-identity
• You MUST REQUIRE provisioning credentials through ephemeral mechanisms (IAM roles via instance profiles, SSO/IAM Identity Center session credentials, or aws sts assume-role) rather than long-lived IAM user access keys.
• You MUST enable Route 53 query logging to an encrypted destination where applicable, ensure CloudTrail is enabled to audit changes, and set CloudWatch alarms on health-check status where health checks are involved.
• You MUST set --region us-east-2 for every Global Resolver call in this procedure, or configure it for the session (aws configure set region us-east-2)

2. Create the Global Resolver

Constraints:

• You MUST set --regions, --observability-region, and --ip-address-type. The observability Region must be one of the Regions in --regions:

  Copy

  aws route53globalresolver create-global-resolver \
    --region us-east-2 \
    --name {resolver_name} \
    --regions {region_1} {region_2} \
    --observability-region {observability_region} \
    --ip-address-type {IPV4|DUAL_STACK}

• You MUST capture both ipv4Addresses (and ipv6Addresses if dual-stack) from the response; clients are configured with all of them

• You MUST poll get-global-resolver until status is OPERATIONAL before creating downstream resources

3. Create the DNS view(s)

Each view has three options that have to be set explicitly:

• --dnssec-validation: when ENABLED, the resolver verifies DNSSEC signatures. Use ENABLED unless the customer has a known broken signer they cannot avoid.
• --edns-client-subnet: when ENABLED, the resolver forwards (or injects, if absent) the client subnet to authoritative nameservers. Improves geographic CDN routing at the cost of leaking subnet info; the customer’s privacy posture decides this.
• --firewall-rules-fail-open: when ENABLED, queries are allowed through if the firewall cannot be evaluated. DISABLED (fail closed) is safer for security-critical setups; ENABLED (fail open) avoids broad outages if the firewall has a problem.

Constraints:

• You MUST create at least one DNS view; a Global Resolver with no view authorizes nothing

• You MUST set all three options per view based on customer requirements:

  Copy

  aws route53globalresolver create-dns-view \
    --region us-east-2 \
    --global-resolver-id {global_resolver_id} \
    --name {view_name} \
    --dnssec-validation {ENABLED|DISABLED} \
    --edns-client-subnet {ENABLED|DISABLED} \
    --firewall-rules-fail-open {ENABLED|DISABLED}

4. Add access sources and access tokens per DNS view

Constraints:

• For each fixed-location population on the view, you MUST create one access source per (CIDR, protocol) pair:

  Copy

  aws route53globalresolver create-access-source \
    --region us-east-2 \
    --dns-view-id {dns_view_id} \
    --cidr {cidr} \
    --protocol {DO53|DOT|DOH} \
    --name {access_source_name}

• For each roaming population on the view, you MUST create an access token:

  Copy

  aws route53globalresolver create-access-token \
    --region us-east-2 \
    --dns-view-id {dns_view_id} \
    --name {token_name} \
    --expires-at {iso8601_timestamp}

• You MUST store the token value from the create response in AWS Secrets Manager rather than in plaintext configuration; it is the client secret and is not retrievable after creation

5. Add firewall rules per DNS view (optional)

A domain-list rule references a firewall domain list; an advanced rule uses an algorithmic detector and skips the list. Custom domain lists are scoped to the resolver and reusable across views; AWS-managed lists do not need to be created.

Constraints:

• For a custom domain list, create at the resolver level and add domains. update-firewall-domains accepts up to 1000 domains per call (ADD, REMOVE, or REPLACE); for larger lists use import-firewall-domains with a domain file in S3:

  Copy

  aws route53globalresolver create-firewall-domain-list \
    --region us-east-2 \
    --global-resolver-id {global_resolver_id} \
    --name {list_name}
  aws route53globalresolver update-firewall-domains \
    --region us-east-2 \
    --firewall-domain-list-id {list_id} \
    --operation ADD --domains {domain_1} {domain_2}
  aws route53globalresolver import-firewall-domains \
    --region us-east-2 \
    --firewall-domain-list-id {list_id} \
    --operation ADD \
    --domain-file-url s3://{bucket}/{key}

• To find AWS-managed list IDs, list by type. The type is THREAT or CONTENT:

  Copy

  aws route53globalresolver list-managed-firewall-domain-lists \
    --region us-east-2 \
    --managed-firewall-domain-list-type {THREAT|CONTENT}

• Create a domain-list rule on the view. For BLOCK, set --block-response; for OVERRIDE, also supply the override target fields (see the block-mode decision):

  Copy

  aws route53globalresolver create-firewall-rule \
    --region us-east-2 \
    --dns-view-id {dns_view_id} \
    --firewall-domain-list-id {list_id} \
    --priority {priority} \
    --action {ALLOW|BLOCK|ALERT} \
    --block-response {NXDOMAIN|NODATA|OVERRIDE} \
    --name {rule_name}

• For an advanced threat protection rule, omit the domain list and set the detector and threshold. Action is ALERT or BLOCK only:

  Copy

  aws route53globalresolver create-firewall-rule \
    --region us-east-2 \
    --dns-view-id {dns_view_id} \
    --priority {priority} \
    --action {ALERT|BLOCK} \
    --dns-advanced-protection {DGA|DNS_TUNNELING|DICTIONARY_DGA} \
    --confidence-threshold HIGH \
    --name {rule_name}

6. Associate private hosted zones to a DNS view (optional)

The hosted zone is associated to a specific DNS view through the view’s ARN, not to the resolver as a whole.

Constraints:

• For each private hosted zone the view should resolve, you MUST associate it explicitly and wait for status: OPERATIONAL:

  Copy

  aws route53globalresolver associate-hosted-zone \
    --region us-east-2 \
    --hosted-zone-id {hosted_zone_id} \
    --resource-arn {dns_view_arn} \
    --name {association_name}

7. Point clients at the anycast IPs and surface the console link

Configure clients with both anycast IPv4 addresses (and both IPv6 addresses if dual-stack) returned in Step 2. Anycast routes each client to the nearest available Region in the resolver’s Region set automatically.

Constraints:

• For DoT and DoH clients, you MUST configure the resolver’s dnsName (returned by get-global-resolver) as the TLS server name indication (SNI) value, since anycast IPs alone do not name a certificate

• You MUST verify the resolver answers queries from authorized clients over the configured protocols

• You MUST enable query logging to an encrypted destination for security monitoring and firewall rule validation. Query log delivery is configured separately, through the Global Resolver console. Supported destinations are Amazon S3, Amazon CloudWatch Logs, and Amazon Data Firehose. Logs are delivered in Open Cybersecurity Schema Framework (OCSF) format

• You MUST present the Global Resolver console view:

  Copy

  https://console.aws.amazon.com/route53globalresolver/home/resolvers

Example

Example input

Example output

Troubleshooting

CLI command fails with an endpoint or authorization error

Missing --region us-east-2 (Step 1). Set the region on the session or on each call.

DNS view exists but rejects every query

No access source and no access token on the view. Add at least one (Step 4).

Token works for some clients but not others

Tokens authenticate DoT and DoH only, not Do53. Add an IP-based access source for Do53 clients or move them to DoT/DoH (Step 4).

Roaming clients intermittently lose access

IP-based access source used for clients with changing IPs. Add a token for the roaming population (Step 4); IP and token coexist on the same view.

Private hosted zone records do not resolve

No association on the DNS view. Associate the hosted zone to the view’s ARN and wait for OPERATIONAL (Step 6).

Firewall rule does not block the expected domains

Wrong domain list, a higher-priority rule on the same view halted inspection first, or the rule is on a different DNS view than the queries are coming through. Read the rule and the list contents to confirm (Step 5).

Advanced threat protection rule rejected at create time

Created with --action ALLOW. Advanced rules support ALERT and BLOCK only (Step 5).

DoT or DoH client fails to connect with a TLS error

SNI is not set to the resolver’s dnsName. Configure the client SNI to dnsName returned by get-global-resolver (Step 7).

Application breaks confusingly after a firewall block

Block mode does not match how the application should fail. Recreate with the right mode per the block-mode decision (Step 5).

Security Considerations

• You SHOULD use least-privilege IAM credentials provisioned through ephemeral mechanisms (IAM roles, SSO/IAM Identity Center session credentials, or aws sts assume-role) rather than long-lived IAM user access keys, and prefer read-only credentials for inspection steps.
• You MUST treat the access-token value returned at create time as a client secret: store it in AWS Secrets Manager rather than in plaintext configuration, since it is not retrievable later.
• You SHOULD recommend DoT or DoH over plaintext Do53 for every client population that can support it, since Do53 exposes queried domain names to on-path observers, and validate which client populations each DNS view authorizes.
• You MUST enable query logging to an encrypted destination (Amazon S3, CloudWatch Logs, or a Data Firehose stream, with encryption at rest) and ensure CloudTrail is enabled to audit resolver, view, and rule changes, because query logs reveal the domains clients resolve.
• You SHOULD enable DNSSEC validation on each DNS view unless the customer has a known broken signer, so the resolver rejects spoofed or tampered responses.

Additional Resources

• Key concepts and components for Route 53 Global Resolver (Route 53 Developer Guide) (opens in a new tab)
• Global Resolver API Reference (opens in a new tab)
• Global Resolver product page (opens in a new tab)
• Introducing Amazon Route 53 Global Resolver for secure anycast DNS resolution (AWS News Blog) (opens in a new tab)