🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Secure Global DNS resolution: Introducing Route 53 Global Resolver (NET217)
In this video, AWS introduces Amazon Route 53 Global Resolver, a new DNS resolver service launched at re:Invent. The session covers three key challenges customers face: split DNS management across multiple locations, DNS exfiltration prevention, and maintaining consistent failover between regions. Global Resolver provides anycast DNS resolution with authentication via IP addresses or access tokens, supports DNS over HTTPS and DNS over TLS encryption, and includes DNS Firewall with managed domain categories to block malware, phishing, and advanced threats like DNS tunneling and domain generation algorithms. The service automatically routes queries to the closest available region and fails over seamlessly. A case study demonstrates how Just Walk Out stores migrated from custom DNS infrastructure across 300+ stores to Global Resolver, eliminating operational overhead while gaining enhanced security and dynamic IP support. The demo shows practical implementation using both restricted and open access views with different firewall rules and private hosted zones. The service is available in preview across 11 regions with no charges during the preview period.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction to Amazon Route 53 Global Resolver at NET217
Welcome everyone to NET217. I hope you're having a great re:Invent so far and that you caught the keynote this morning. My name is Adhish Bhobe, and I'm a Senior Product Manager with AWS. I have with me Matt Engskow, who is a Principal Engineer, and we are both from the Amazon Route 53 team. We're going to talk about a new launch that we just released a couple of days ago called Amazon Route 53 Global Resolver. Before we begin, I'd like to do a quick show of hands. How many of you are network administrators who work with DNS and DNS security? I see quite a few hands raised. Great! You're in the right session because we're going to talk about how you can achieve secure and anycast DNS resolution for your clients with Global Resolver.
Here's what we're going to cover today. We'll discuss the key challenges that led us to build Global Resolver and what we heard from our customers. We'll explain why you should use Global Resolver and the key benefits you'll gain from this service. Then I'll turn things over to Matt, who will walk you through how to get started and how to use the service optimally. There will also be a cool demo, so please stick around for that. We'll also share a case study about how Just Walk Out Stores uses Global Resolver and how they plan to scale it across all of their stores. For those unfamiliar, Just Walk Out is a technology built by Amazon for its stores, including Amazon Go and Amazon Fresh, that enables a cashierless and touchless user experience. I'll conclude by discussing where you can use this service, which regions it's available in, and provide you with pricing information.
Three Key Customer Challenges: Split DNS Management, DNS Exfiltration Prevention, and Multi-Region Complexity
Let me start by discussing the three key challenges we heard from our customers that led us to build Global Resolver. The first challenge was split DNS management. Our customers were maintaining forwarding rules for different customer locations, different data centers, different branch offices, and even for remote clients. They needed to enable split DNS between private domains and public domains on the internet. For AWS specifically, this meant managing split DNS for private hosted zones, which are containers of domains and subdomains used for private domains hosted on Amazon VPCs, while also splitting traffic to internet domains for internet applications. At the same time, there were requirements to have different DNS resolution views for different sets of clients. This added significant operational pain for many of our customers who had to maintain these configurations and ensure consistency across all their locations.
The second challenge we heard from our customers was the ability to prevent DNS exfiltration. DNS exfiltration is a mechanism used by attackers today to extract data over DNS. This is a key requirement for many of our customers who currently use appliances on premises or set up custom rules to ensure that clients are not resolving traffic to any malicious domains on the internet. At the same time, there are requirements to meet compliance and audit needs by having all logs in a single location for easy auditing and compliance verification.
Now, consider the setup of split DNS management and the maintenance of all your rules across multiple regions and multiple customer locations. This can become very tedious and cumbersome for your teams, especially when you have to replicate the same rules across multiple different locations, ensure that they're consistent and up to date, and verify that all your clients are resolving the same set of domain rules that you want them to. Additionally, ensuring failover between all of these regions was another key requirement we heard from our customers, especially for continued DNS resolution. You may have clients or applications that need high availability DNS resolution and resilience at all times.
Introducing Global Resolver: Anycast DNS Resolution with Authentication and Flexible DNS Views
With all of this in mind, we are launching Amazon Route 53 Global Resolver. This is available in preview today for you to use. Global Resolver is a new DNS resolver that provides you a way to resolve both private domains hosted on AWS as well as public domains hosted on the internet.
At the same time, it allows you to filter traffic to malicious domains, encrypt traffic in transit, and log all your queries across all your locations in a single place of your choice, making it easy for you to access those logs. Global Resolver is optimized for latency, so it will always route your traffic to the closest available region that you pick. It is also optimized for resilience, so if your clients are unable to reach a specific region, it will automatically fail over to the next available region. It is also built for data residency needs.
I want to give you a glimpse of how it all looks when it comes together. Here you can see that you may have multiple corporate data centers, remote locations, and branch offices. With Global Resolver, they can all point their traffic to a single anycast IP without you having to maintain separate forwarding rules in every location. Global Resolver will be available in the regions that you pick and will be able to process your queries for both private hosted zones as well as any queries going out to the internet based on the filtering rules that you set.
Next, I want to talk about some of the key reasons why you should be using Global Resolver. This goes back to the challenges that we discussed earlier. With Global Resolver, you can achieve split DNS management. You can resolve both public domains and private hosted zones from anywhere, from all your customer locations, wherever they are. This provides you an easy way to quickly resolve all your traffic and simplify all your rule management across all your customer locations without you having to manage forwarding rules in every single location.
Global Resolver anycast IPs are internet reachable, so you can reach them from anywhere, from all your authenticated clients. Global Resolver is not an open DNS resolver. It is only accessible by clients that you authenticate to use with Global Resolver. There are two ways that you can authenticate your clients. One is using IPs, which are IPs that are associated with your clients, such as your on-premises destinations, branch offices, or remote clients. You may also have clients that have dynamic IPs or IPs that may change over time. In that situation, we recommend that you use access token secrets that we will provide and that you can deploy in your clients. These will be more permanent so that even if your clients are roaming or changing IPs, they will stay authenticated with Global Resolver.
Once they are authenticated, all queries from your clients will be processed based on the rules that you create. I want to talk about another key notable feature of Global Resolver, which is the ability for you to have more flexibility in how you group your clients and your locations. You may have different DNS resolution requirements for different sets of clients. For example, for your roaming clients, you may want to have DNS filtering rules and the ability for them to resolve private hosted zones. You can create a separate DNS resolution view, which is a logical grouping of all your clients identified by access tokens or IP groups, and ensure that any traffic coming from those clients is treated based on the rules that you create.
You may also have a different DNS view for different sets of clients. With DNS views used with Global Resolver, this gives you an easy, flexible way of managing all your clients across different locations without you having to create different rules for each of them and managing them. Let's talk about how we can improve DNS security with Global Resolver.
Enhanced DNS Security: Managed Domain Categories, Advanced Threat Detection, and Encrypted Query Privacy
You will have access to multiple managed domain categories. These are preconfigured categories that are classified by both the type of DNS threats, which could be malware, command and control, spam, or phishing, or even based on the type of web content that domain hosts. You can choose to block, alert, or allow some of these depending on your clients' requirements. These are preconfigured, so there is no management from you. They are automatically updated, and as you distribute the rules to different clients, the automatic updates are automatically propagated to all your rules and clients.
I also want to discuss a key aspect of DNS protection, which is how you can improve DNS security for advanced DNS threats. There are two specific DNS threats I want to talk about. One is DNS tunneling, which is a way where an attacker can set up a DNS tunnel using malware that is already pre-propagated to the client's device. That malware is sending malicious DNS queries to the command and control server. Using a pattern of request and response, the DNS tunnel that is established allows the attacker to exfiltrate data over DNS requests from the client.
Another advanced DNS threat that we hear from customers is domain generation algorithms, also known as DGAs. This is where an attacker can create multiple bad domains, which could be in the hundreds, thousands, or sometimes even in the millions, with the objective of evading detection. Over time, even if threat intelligence feeds are able to catch these domains, the attackers move to the next possible domain and continue carrying out their attack. With Global Resolver, you can create DNS rules for these advanced DNS threats. These rules look at anomalies in your DNS queries such as length, the type of query, and query name to make a probabilistic determination of whether the query is associated with DNS tunneling or DGA.
These rules are also customizable, so you can set rules, for example, to block the most highly probabilistic DNS tunneling or DGA threats. Or you can set a rule at a low confidence level to only alert on these threats so that your security teams can investigate and make a determination of whether to block them. All the monitoring is done in real time and in line for all your queries.
Besides DNS exfiltration, you can also improve your DNS security by enhancing the privacy of your queries. With Global Resolver, you have the ability to use DoH, which is DNS over HTTPS, or DoT, which is DNS over TLS, both known DNS protocols, to encrypt traffic in transit between your client and Global Resolver. This ensures that any traffic cannot be sniffed by an attacker in transit.
A key requirement for many of our security operations teams is to have all their logging for all queries in a single place, which is also possible with Global Resolver. You can pick the region of your choice and an S3 bucket of your choice to store all those logs.
Latency Optimization, Automatic Failover, and Key Use Cases for Global Resolver
So we have talked about simplifying DNS resolution and DNS security access controls. Let's talk about another notable feature of Global Resolver. Global Resolver is optimized for latency and also for region failover. Queries from your clients are automatically routed to the closest available location that you pick with Global Resolver. We ask that you pick at least two regions so that whenever a region is not accessible from one of your clients, we will automatically fail over to the next available region so that all your queries are always answered with high resiliency.
You also have the flexibility to use Global Resolver.
Global Resolver addresses your data residency needs. For example, you may want to create a different anycast IP for a different set of regions or a country depending on your security mandates or organizational mandates. Based on the anycast IPs that you create, your clients will be directed to the ones that are mandated by your organization.
We've talked about the key challenges and the key benefits. Now let's discuss the key scenarios when it makes sense for you to use Global Resolver. There are three of them. First, Global Resolver is most optimal when you want to have consistent DNS resolution across multiple locations. You may have multiple data centers, multiple branch offices, or remote clients distributed across the world. If you want to have consistent DNS resolution and security for all of them, Global Resolver will provide you the necessary rules and flexibility to use them without having to spend the time to create your own rules.
You may also have disconnected sites. For example, you may have clients that are directly accessing the internet and may not be under the purview of your security teams or networking teams. Bringing them under a single anycast IP with the rules that your team creates ensures they're always bound to resolve to the same domains that your team has set without them having to egress to any DNS location that is outside the bounds.
Lastly, you may have critical clients or applications that need DNS resolution at all times. With Global Resolver, you have the ability to easily fail over between different regions without having to manage those failover options yourself.
Route 53 VPC Resolver vs. Global Resolver: Understanding the Differences and When to Use Each
I've covered Global Resolver so far, and I want to switch topics a bit. I want to ask everyone in the room: how many of you are familiar with Route 53 Resolver today? A lot of you, yes. As you all know, Route 53 Resolver is the default resolver that comes with all your VPCs. It allows you to resolve queries for your private domains, hosted zones, and any internet domains. You can also forward traffic between your VPCs and your hybrid clients that are connected to the VPC using resolver endpoints.
With the launch of Global Resolver, we are now renaming Route 53 Resolver to be Route 53 VPC Resolver for better architectural distinction and naming consistency. I do want to highlight that this changes nothing in terms of the API operations. You can continue using Route 53 Resolver the way it is. There will be no change there. But I do want to highlight the key differences and similarities between these two products and also talk about when you should use Global Resolver versus VPC Resolver.
Global Resolver is multi-regional and is reachable over the internet from anywhere as long as it's authenticated to use. VPC Resolver is the default resolver for your Amazon VPCs and for any clients connected to those VPCs using resolver endpoints. Both Global and VPC Resolvers support encryption. Global Resolver supports DoH and DoT protocols. VPC Resolver supports DoH protocol today for any traffic between your VPCs and your hybrid clients.
A key similarity of both these services is that both of them use DNS Firewall, which is a feature of Route 53 that is in use today for blocking any traffic to any malicious domains on the internet. In terms of positioning, we expect that you'll use Global Resolver for any remote networks, any remote clients, and hybrid networks with a multi-region footprint. You may have multiple regions and multiple locations that you want to manage without having to spend the time creating forwarding rules for each of those. VPC Resolver will continue serving all your clients within your VPCs and also any clients that may be connected to those VPCs using resolver endpoints.
We've covered a lot of ground. I'm going to turn it over to my colleague Matt, who will talk you through how you can get started with the service and also the best practices.
Getting Started with Global Resolver: CLI Setup, Best Practices, and Multi-Region Resilience
My name is Matt Engskow. I'm a principal engineer at AWS Route 53, and I'm incredibly excited to talk to you about Global Resolver today. The key takeaways that I want you to have for this section are first, I want to give you a leg up such that if you want to use this product you can quickly go back to your organization and put it into use. I want to get you familiar with the constructs that you'll be using under the hood to do that, and I want you to understand which you should use in which scenarios and how you might apply them for your network's very specific needs.
To get started, we're going to talk through how we might set up Global Resolver using the CLI. If you're more interested in the console flow, we'll be going over that too in just a little bit as part of our demo. The first thing that I want to do when I want to create my global resolver is define the regional scope. So as we mentioned, when you make this create resolver call, you're going to be passing in at least two AWS regions that are going to be used to serve your DNS traffic. Optionally, you can also configure an observability region where that observability region will be used to aggregate your logs such that you can review them later if you have compliance needs or you'd like to do some investigation about why DNS is working the way that it is.
Once I've created my global resolver, I'm going to be given back a set of IP addresses and a DNS name for my Global Resolver. These are going to be static for the lifetime of your resolver regardless of what other configuration you take, and they'll be useful when you start configuring your clients. Following the creation of my global resolver, I can start to define my DNS views. These DNS views are logical containers for all of my configuration policies and allow clients to access my global resolver. Now, by default, the Global Resolver has no access, regardless of how I try to throw packets at those IP addresses or that DNS name, they're not going to work.
So the next thing that I need to do is create a way for my clients to become authenticated. As Aish mentioned, I can do that in two ways. I can use access sources to take my known public IP addresses for my clients and configure them simply. If I have roaming clients, I might like to use access tokens and instead create these pre-shared secret keys that I'll then distribute to my clients later on. Now once I've created these, my clients can then start to use the individual views that have been mapped to these access tokens or sources, and it's going to be vanilla DNS, just a public DNS resolver, but I might want to do more than that.
So optionally I can also start customizing these views. I can create things like firewall rules. An example that we have on the screen here is something that maybe your spouses or your managers might like to do while you're here at re:Invent. I can block gambling for all of my clients. Additionally, I can associate things like hosted zones that allow me to customize DNS resolution for my own internal applications as I see fit. I can continue to layer these things on as needed and update DNS views later on as my policies change or additional private hosted zones become provisioned.
Now I've walked you through how to create your global resolver. I want to give you some best practices for those key focus areas that Aish mentioned earlier. So we're going to talk through some of the best practices for achieving split DNS resolution, securing your global access, improving your security, and failover and multi-regional resilience. First, let's start with achieving split DNS resolution. So as called out, a single global resolver can be responsible for many views. You can think of the global resolver as just those IP addresses and the networking setup, but how my clients actually get a DNS answer is a logical construct held by those views.
Those views can take many different forms and can be customized to fit your needs. So I may have some networks that are very open, right, clients that don't have very many restrictions, and I may have some clients that are maybe highly sensitive workloads where I need to lock down DNS and only allow them to resolve a very small set of domain names. I can put both of those into two different views and associate them to a single global resolver, and then map the clients through the sources or tokens appropriately to those views. How this might look under the hood, so maybe I start with DNS view A here on the left, and I might add in a couple of hosted zones. These could be the same private hosted zones that you already have for your VPCs or brand new ones. I may also create a firewall rule. I would then layer in my access source with the IPs as appropriate.
Now if I want to spin up a new view, maybe I have new resources or maybe I want to reuse some. You'll see in the example here, I'm reusing this top hosted zone. It has the same ID, but every other resource below it is a completely new one. This allows us to quickly get to consistent DNS resolution without needing to provision new networking infrastructure where I want it, but to specialize those views where I want it as well.
Next, let's talk about authentication. At a high level, we have those two same constructs: access tokens and access sources. Beneath those, there are individual protocol supports and some nuances that I want to talk through. When it comes to access tokens, you can use DNS over HTTPS, or DOH. When you're configuring DOH on your clients, you're going to be specifying a very specific DOH URI or URL that includes the access token to be passed upstream to Global Resolver.
One of the nice things about this option is that it's supported by common operating systems like Windows and macOS today, so you can configure those clients without ever installing new client software or doing much configuration. Another option for access tokens is DNS over TLS, or DOT. This is often supported by common DNS server software like Unbound and CoreDNS, and others, and is a really good option if you have a centralized DNS forwarder for an environment that your clients are forwarding to first before you want to egress into Global Resolver.
For DOT, we will be configuring that DOT client to inject an EDNS 0 option, or a DNS extension, that specifies a very specific DNS operation code and your access token, and can pass it upstream to Global Resolver. On the access sources side, we support all three of these protocols, but in a simpler way. You can choose to use DOH, DOT, or the more vanilla DO53 UDP TCP DNS, so long as you're willing to configure those source IPs. This is a really simple option if you have fixed IP sites where you've got that list of IPs readily available and you don't want to configure client devices in any way at all.
One important note here: your DNS views can use multiple access types as needed. In the example here, you can see that view A has both an access source and an access token configured at the same time, and view B has only an access source. That's absolutely okay. You can mix and match these as needed. Additionally, each view is meant to scale to handle thousands of potential tokens and sources. So if you have many roaming clients or many sites that you want to configure, you can do that all behind one view or many views as needed.
Next, let's talk about improving your DNS security. Because we've had DNS Firewall, the same service that's used on your VPC DNS today, we've seen a lot of learnings from customers over time in the ways that they configure this service. There's a lot of configuration that you can do and a lot of customization. You can build exemptions for your trusted domains and enable those advanced protections. We can support both fail open and fail closed if you're more concerned with availability or security, and you can do both allow and deny by default in case you want to operate in that walled garden mode where perhaps you only allow a very small set of names to be resolved.
I want to talk through how we've seen customers adopt DNS filtering and the safe way to do it. First, one of the things that we see many of our customers do that we recommend is to start with an allow list for your organization's highly trusted domains. These are the things that you know should never, ever, ever be blocked. If you're going to be using the advanced protections that we have that are backed by some very smart machine learning models, we still recommend that you allow list your trusted domains, just in case you happen to be doing anything that looks like tunneling or DGA traffic for those domains. It'll still be allowed.
We often also see customers who are willing to block for our most high confidence thresholds on those advanced protections, but maybe they still want to receive alerts for the lower thresholds. You'll see our priority values here allow us to do that. We can layer in our high confidence and then below that put our low confidence where maybe our security teams are going to be sifting through our logs and looking at those findings rather than blocking production traffic outright. Now as customers adopt these features, we see them work through a phased approach.
Log analysis on their DNS traffic is often where it starts. They're looking for those highly safe, trusted domains and things that might be suspicious, coming up with what they think might be reasonable rules. We highly recommend that customers start with alert rules where in phase two you build out what may eventually become your production rule set, but you enable it only in alert mode. You can then go back to your DNS logs and see what would have been blocked had you turned these rules on.
For many customers, they cycle back and forth between phase one of log analysis and phase two, where they fine-tune their policies over time and adjust them until the number of alerts they're seeing becomes very small, and they're confident they can move on to phase three. In phase three, you take a simple rule update and change your alert rules into actual block rules. At this point, your traffic starts to receive those DNS filtering policies and they become enforced.
We still recommend that customers continue to monitor their metrics and logs to look out for new spikes in blocks or spurious traffic that might be identified by the service. Your workloads are going to change. You're going to take on new dependencies and update your software over time, and there will be some maintenance required. That's all I have on DNS security. Finally, let's talk about failover and multi-region resilience.
Global Resolver is designed to offload the complexity of multi-region DNS deployments. The service works to protect your network from both internet routing and service impairments and automatically redirect traffic to maintain high availability. When you provision your Global Resolver, you get two IP addresses back. Behind the scenes, those two IPs are backed by separate redundant capacity, and we always recommend that clients are configured with both those IPs such that should there be an issue with one of those IPs, they can quickly retry and distribute traffic to the other. That's pretty standard in DNS to have your primary and secondary.
Let's talk about how the service works behind the scenes to maintain availability at an even higher standard. When routing into regions that you've configured for your Global Resolver, your traffic is first routed through AWS edge locations that are close to your client. There are more than 400 of these edge locations worldwide, and that ensures they're always close by to your clients regardless of where they reside. What happens if one of those edge locations has a network or service impairment? Global Resolver's anycast route announcements ensure that we are able to quickly fail away from an impaired edge location and onto one that can successfully process your traffic.
This same concept applies when it comes to our multi-region resilience story. Should AWS, in the rare case, be having an AWS service impairment in a given region, that secondary region that you've selected, or if you've selected more than two, your clients will again be rerouted to the next available region. We think this provides a really robust story and helps automatically solve for your disaster recovery and multi-region resilience requirements that you might have for your services.
Just Walk Out Stores Case Study: Simplifying DNS Architecture Across 300+ Retail Locations
That's all I have for best practices. I now want to talk about a case study covering Just Walk Out stores. Just Walk Out is a technology that simplifies shopping and has been delivered by Amazon. It helps customers get in and out of stores quickly where they can enter a store, grab what they want off the shelf, and get back to their day without ever having to queue or stop at a cashier. You might have used one of these locations at a sporting event, maybe at the airport, or even here at the conference center where our merch store over at the Venetian has one of these today.
The technology backing these uses a combination of cameras, RFID, and sensor fusion between those two things, fast checkout registers that scan your phone quickly for payment, and all of those things require a very robust network. All of those network devices need DNS to function. Behind the scenes today, Just Walk Out has a very large distributed DNS footprint. They have over 300 of these stores across Australia, Canada, Europe, and the US, and these result in over 550 million DNS requests per day. To handle these, they provisioned infrastructure in four AWS regions.
Now, pre-migration to Global Resolver, their footprint looks something like this, albeit a little bit simplified. On the left-hand side of the screen, you can see that they have a centralized DNS forwarder that's the first hop for all of those cameras and servers.
Those DNS forwarders then send traffic into four database regions, each equipped with custom DNS server software that performs several functions. First, it handles IP allow-list (IPLL) listing, sending queries over plain DO53 and maintaining IPLL entries for each store with fixed IP addresses. The software also applies conditional DNS zones with per-store DNS records and conditional DNS filtering rules that distinguish between front-of-house and back-of-house networks with different security requirements. Once these rules are applied, the traffic is forwarded to Route 53 resolver inbound endpoints to enable proper internet DNS resolution.
While this is a robust DNS infrastructure, the organization identified several areas for improvement. They wanted to stand up stores quickly without needing to know the fixed IP addresses in advance. They also wanted to reduce the operational effort required to maintain the system, as the DNS server software requires developers to patch, reconfigure, and load new IP data regularly, and the conditional filtering rules need constant updates.
After migration, the architecture changed significantly. Just Walk Out now uses access tokens that can be pre-provisioned well ahead of store buildout and assigned to stores as they come online. The stores communicate with Global Resolver using encrypted DNS via their access tokens. Each access token maps to store-specific views for both front-of-house and back-of-house networks, applying policies automatically without requiring any DNS server software on their end. This solution deploys to the same four regions that Just Walk Out uses today, but if they choose to expand to five or more regions tomorrow, they can do so with a simple configuration change on Global Resolver, gaining lower latency for clients near those new regions and additional failover capability.
The migration delivered substantial benefits. The organization gained enhanced security from DNS encryption, achieved a greatly simplified network architecture, gained support for dynamic IP addresses that may not be known in advance, and realized greatly reduced operational overhead by eliminating the need to maintain DNS server software.
Live Demo, Regional Availability, and Pricing: Getting Started with Global Resolver Preview
Next, I would like to walk you through a demo. I should caveat that this is a live demo, and we just launched this a couple of days ago, so please bear with me. Hopefully we won't have any issues with the Wi-Fi.
For this demo, I will be walking through a Global Resolver that I provisioned ahead of time and showing you how it works behind the scenes. I have some DNS commands on the right-hand side of the screen that I will use throughout the demo. Here is our Global Resolver console where I have created this demo Global Resolver. It is currently backed by two regions: one in US East 1 and the second in US West 2.
Behind my Global Resolver, I have two DNS views: an open-access view and a restricted-access view. They are configured as you would expect, where our open view can query and resolve anything, while our restricted-access view has some restrictions applied to it.
For our restricted-access view, let me discuss this one first. I have enabled DNS Firewall rules to block two categories: both travel and shopping. I have one private hosted zone that performs custom DNS resolution for globalresolver.com, which I will demonstrate in just a moment. I have two access sources configured—not access tokens, but two access sources. One is for a very specific EC2 instance IP, and the second is for the IP range we are using here at re:Invent today. If you happen to be sitting in the audience with a laptop open, you can try a DNS query like this today, and it should get resolved for you. Please feel free to try that out as I am talking if you would like. I will leave this here for just one second if anybody wants to take a screenshot.
Now I am going to show DNS resolution from two specific instances. The first, which I have called IP demo instance, has this public IP that you can see here, which corresponds to the same access source that I have configured. Let me go to that one first.
Let me start by reloading here. For this EC2 instance, I should be able to grab one of my sample queries. What you can see that I'm doing here is a simple dig or DNS lookup command towards the IPs that were allocated for my Global Resolver for amazonaws.com. I'm quickly getting back those IPs. Now I can also do some more interesting things. Let me go ahead and use that private hosted zone that I mentioned I configured earlier. Here I'm doing a lookup for a TXT record called view-name.globalresolver.com. You can see when I do this, I get back a restricted access view TXT record, so I can prove to you that I'm using the right view.
Now, because this is a restricted access view, I have some DNS policies that I've applied. For example, we're all here in the lovely Wynn Hotel here in Las Vegas. But because I've restricted access to travel as a domain category, that hotel domain is going to be blocked, and I'll show you that here. So as I look up wynnlasvegas.com, you can see that I got back this NXDOMAIN, which is the response that I configured when I set up my block rules.
Next up, let's talk about our open access view and show off access tokens. These are going to be a little more advanced because we have to embed the right metadata for the request to be resolved. So on this view, there are no firewall rules. Similarly, I have yet another private hosted zone with no access sources but one access token. For this instance, I have already shared my access token to this host and some environment variables, and I'll show you those here. You can use them while they're active if you like, if you're quick on the screen. Here are my access tokens. I'm going to go ahead and source these so that they're loaded in. Let's do some more fun DoH and DoT queries.
To start, I will do a DoH query for amazonaws.com. I'm going to use kdig, the Knot version of dig, which is a little bit more advanced and lets me do things like inject EDNS0 and do a DoH on demand. You'll see that here. I'm able to issue this DoH query with a very specific URL that passes in token equals my access token that I configured, and I'm able to get a response back for amazonaws.com. If I check the same thing for my view name, you will see that I'm now using the open access view which I configured in a separate hosted zone for that same DNS name. I'm giving you that split DNS resolution between your two views.
The last thing I want to show is a DoT query, which is again very similar. But instead of plus HTTPS, it's using the plus TLS flag that you can see, and it's adding this EDNS0 option. 65,440 is our predefined access token opcode, and then the open access token in string encoded format here, so that I can do my lookup for amazonaws.com again and get back my DNS resolution. So there you have it. We have a Global Resolver. We've configured a couple of views. I've shown you how we can use our client-side bits to go and configure those. We do have good examples in our documentation of how you might configure your clients, whether they're Windows or macOS devices, to do those DoH lookups if you're interested in that kind of configuration. I'd now like to hand it back to Adhish who's going to talk through some of our closing steps.
Thanks, Matt. Hopefully that was a fun demo. I don't know if you got to try it, but once you're out, you can definitely try it out and let us know what you think. I'd like to also talk about the next steps. What are the key regions that we are available in today and also give you a glimpse about the pricing. During preview, we will be available in 11 different regions across North America, Europe, Asia Pacific, and Australia. You can try out the new service in these regions and let us know what you think.
In terms of pricing, we'll be charging you based on two key dimensions. One is the number of regions that you create, and two is the number of queries or the query volume coming from your clients. We'll be charging you on a base rate for the first two regions combined, and then for every additional region, there will be an additional charge. For query-based pricing, for the first billion queries, there will be no charge. Everything above one billion is going to be charged. The good news is that you will not be charged a price during preview, so you are free to use this service with no additional financial constraints that you may have. With that, we have come to the end of the session. I hope you enjoyed it. Do feel free to provide your feedback through your app and I hope you have a great rest of re:Invent. Thank you.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)