Route 53 Private DNS and Resolver

Build private DNS, hybrid forwarding, and DNS Firewall inside a VPC.

Introduction

30 Second Summary

Every company has internal services that need names. A database server, an API endpoint, a microservice. These names should work inside the company network but remain completely invisible to the outside world.

In this project, you will build a private DNS environment inside a VPC where internal hostnames resolve to private IP addresses, extend it with Route 53 Resolver to forward queries for external domains, and layer DNS Firewall on top to block queries to known-bad domains.

What You'll Build

You will SSH into an EC2 instance, query internal hostnames that only exist inside your VPC, watch the same domain return different IPs depending on where you ask from, and see DNS Firewall silently kill a query to a suspicious domain in real time.

By the end of this project, you'll have:

  • A private hosted zone where EC2 instances resolve internal hostnames like db.corp.internal that the public internet cannot see.
  • A split-view DNS setup where the same domain name (example.com) returns different IP addresses depending on whether you query from inside or outside the VPC.
  • A Route 53 Resolver outbound endpoint with a forwarding rule that directs DNS queries for a specific domain to a designated target IP, simulating hybrid DNS resolution.
  • Secret Mission: Configure DNS Firewall to block queries to a suspicious domain list and verify the block works from within the VPC.

Are there any prerequisites?

You need an AWS account with Console access and familiarity with VPC, EC2, and Route 53 fundamentals. No registered domain is required for this project.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Set Up Your VPC and EC2 Instance

Private hosted zones only respond to DNS queries that originate from within an associated VPC. To test private DNS resolution later in this project, you need a VPC with the correct DNS settings and an EC2 instance inside it.

In this step, you will create a VPC, configure its subnets and internet access, and launch an EC2 instance you can SSH into. By the end, you will confirm the VPC Resolver is working by resolving a public domain from inside your instance.

In this step, get ready to:
  • Create a VPC with DNS settings enabled and two public subnets in different Availability Zones.
  • Attach an Internet Gateway and configure routing for internet access.
  • Launch an EC2 instance, SSH in, and verify DNS resolution works.
Create your VPC and subnets

You will create a dedicated VPC for this project with two subnets spread across different Availability Zones. Two AZs are required because Route 53 Resolver endpoints (used later) need ENIs in at least two zones.

  • Sign in to the AWS Management Console.
  • Confirm your region is set to US East (N. Virginia) us-east-1 in the top-right corner of the console.
  • Search for VPC in the top search bar and open the VPC console.
  • In the left navigation pane, choose Your VPCs.
  • Click Create VPC.
  • Select VPC only (not "VPC and more").
  • In the Name tag field, enter dns-lab-vpc.
  • In the IPv4 CIDR block field, enter 10.0.0.0/16.
  • Leave all other settings as default and click Create VPC.

You should see a green success banner confirming the VPC was created.

Why VPC only and not VPC and more?

The "VPC and more" wizard auto-creates subnets, route tables, and gateways with its own naming convention. Creating each resource manually gives you precise control over names and helps you understand how the pieces connect.

Now enable DNS hostnames on your new VPC. This setting defaults to disabled for non-default VPCs, but private hosted zones require both DNS attributes to be true.

  • Select dns-lab-vpc in the VPC list.
  • Click Actions, then choose Edit VPC settings.
  • Under the DNS settings section, check the box for Enable DNS hostnames.
  • Confirm that Enable DNS resolution is already checked (it is enabled by default).
  • Click Save.

Back on the VPC details page, you should now see both DNS hostnames and DNS resolution showing as Enabled.

Why are both DNS settings required?

Private hosted zones need enableDnsSupport set to true so the VPC Resolver (at the VPC CIDR +2 address, 10.0.0.2) can answer queries.

They also need enableDnsHostnames set to true so instances get DNS hostnames that Route 53 can route correctly. Without both enabled, your private hosted zone records will not resolve.

Next, create two subnets in different Availability Zones.

  • In the left navigation pane, choose Subnets.
  • Click Create subnet.
  • In the VPC ID dropdown, select dns-lab-vpc.
  • Under Subnet settings, enter dns-lab-subnet-1 as the Subnet name.
  • Select us-east-1a for the Availability Zone.
  • Enter 10.0.1.0/24 for the IPv4 subnet CIDR block.
  • Click Add new subnet to add a second subnet in the same creation flow.
  • Enter dns-lab-subnet-2 as the Subnet name.
  • Select us-east-1b for the Availability Zone.
  • Enter 10.0.2.0/24 for the IPv4 subnet CIDR block.
  • Click Create subnet.

You should see both subnets listed with state Available.

Don't see your VPC in the dropdown?

Make sure your region is set to us-east-1 in the top-right corner. VPCs are regional resources, so a VPC created in one region will not appear in another.

Help me troubleshoot my VPC not appearing

Configure internet access

Your subnets exist but have no route to the internet. You need an Internet Gateway attached to the VPC and a route table entry pointing outbound traffic to it.

  • In the left navigation pane, choose Internet gateways.
  • Click Create internet gateway.
  • Enter dns-lab-igw as the Name tag.
  • Click Create internet gateway.

You will land on the gateway detail page with the state showing Detached.

  • Click Actions, then choose Attach to VPC.
  • Select dns-lab-vpc from the Available VPCs dropdown.
  • Click Attach internet gateway.

The state changes to Attached, confirming the Internet Gateway is connected to your VPC.

Now add a route to the VPC's main route table so traffic can reach the internet.

  • In the left navigation pane, choose Route tables.
  • Find the route table associated with dns-lab-vpc (check the VPC column).
  • Select that route table, then click the Routes tab in the lower panel.
  • Click Edit routes.
  • Click Add route.
  • In the Destination field, enter 0.0.0.0/0.
  • In the Target dropdown, select Internet Gateway, then pick dns-lab-igw.
  • Click Save changes.

The Routes tab now shows two entries: the local route (10.0.0.0/16) and your new internet route (0.0.0.0/0 targeting dns-lab-igw).

Finally, enable auto-assign public IP on your first subnet so instances launched there get a public address.

  • In the left navigation pane, choose Subnets.
  • Select dns-lab-subnet-1.
  • Click Actions, then choose Edit subnet settings.
  • Check the box for Enable auto-assign public IPv4 address.
  • Click Save.
Launch your EC2 instance and verify DNS

With networking in place, you can launch an EC2 instance to test DNS from inside the VPC. This instance will be your tool for verifying every DNS configuration in the project.

  • Search for EC2 in the top search bar and open the EC2 console.
  • Click Launch instances.
  • In the Name field, enter dns-lab-ec2.
  • Under Application and OS Images, confirm Amazon Linux 2023 AMI is selected (it is the default).
  • Under Instance type, select t2.micro (free tier eligible).
  • Under Key pair (login), select an existing key pair or click Create new key pair to generate one.

Save your key pair file

If you create a new key pair, download the .pem file and save it somewhere you can find it. You will need this file to SSH into your instance.

  • Expand the Network settings section and click Edit.
  • In the VPC dropdown, select dns-lab-vpc.
  • In the Subnet dropdown, select dns-lab-subnet-1.
  • Confirm Auto-assign public IP is set to Enable.
  • Under Firewall (security groups), select Create security group.
  • Enter dns-lab-sg as the Security group name.
  • Confirm the rule shows Type as ssh, Port range as 22, and Source type as My IP.
  • Leave all other settings as default and click Launch instance.

You should see a success message with a link to your new instance. Click the instance ID to go to its details page.

  • Wait for the Instance state to show Running and the Status checks to show 2/2 checks passed (this takes 1-2 minutes).
  • Copy the Public IPv4 address from the instance details panel.

Now SSH into your instance. Open a terminal (PowerShell or Command Prompt on Windows) and connect using your key pair.

  • Connect to your instance by running this command (replace the placeholders with your values):
ssh -i [[PEMPATH="path/to/your-key.pem"]] ec2-user@[[EC2_PUBLIC_IP="your EC2 public IPv4 address"]]

What does this command do?

The -i flag specifies the private key file for authentication. ec2-user is the default username for Amazon Linux instances. The address after @ is your instance's public IP.

🙋‍♀️ Connection timed out or refused?

If you see a timeout, confirm your security group allows SSH from your current IP address. Your IP may have changed since you created the rule.

If you see a permissions error about the key file, run icacls your-key.pem /inheritance:r /grant:r "%USERNAME%:R" on Windows to restrict permissions on the file.

Help me troubleshoot my SSH connection

Once connected, you will see the Amazon Linux prompt. Before you run the DNS check, predict what will happen: do you think your instance can resolve public domain names through the VPC Resolver at 10.0.0.2?

  • Test DNS resolution by running this command:
nslookup amazon.com

You should see output showing the VPC Resolver address (10.0.0.2) as the server and one or more IP addresses for amazon.com. This confirms your VPC DNS is working correctly.

What is the 10.0.0.2 address?

Every VPC gets an Amazon-provided DNS server at the VPC's base CIDR address plus two. For a VPC with CIDR 10.0.0.0/16, that address is 10.0.0.2. This is the Route 53 Resolver, and it handles all DNS queries from within your VPC.

🙋‍♀️ nslookup returns connection timed out?

Go back to your VPC settings and confirm DNS resolution is enabled. Without this setting, the VPC Resolver at 10.0.0.2 will not answer queries.

Help me troubleshoot my DNS resolution issue

Your VPC networking is fully operational. Next up, you will create a private hosted zone that gives friendly internal names to resources inside this VPC.

Create a Private Hosted Zone and Internal DNS Records

Your VPC can resolve public DNS names like amazon.com, but you have no way to give friendly internal names to your private resources.

Without a private hosted zone, your EC2 instances must reference each other by IP address. In this step, you will create internal DNS records so that names like db.corp.internal and api.corp.internal resolve to private IPs only from inside your VPC.

In this step, get ready to:
  • Create a private hosted zone for corp.internal associated with your VPC.
  • Add A records for db.corp.internal and api.corp.internal pointing to private IP addresses.
  • Verify that internal names resolve inside the VPC but are invisible from the public internet.
Create the private hosted zone

A private hosted zone is a DNS container that only responds to queries originating from VPCs you associate with it. You will create one for the domain corp.internal and link it to your VPC.

  • In the AWS Management Console, open the Route 53 console at https://console.aws.amazon.com/route53/
  • In the navigation pane, choose Hosted zones.
  • Choose Create hosted zone.
  • In the Domain name field, enter corp.internal.
  • In the Type list, choose Private hosted zone.
  • In the Region dropdown, select us-east-1.
  • In the VPC ID list, choose your dns-lab-vpc.
  • Choose Create hosted zone.

The console redirects you into the new corp.internal hosted zone. You should see the default NS and SOA records already present.

What is a private hosted zone?

A private hosted zone tells Route 53 how to respond to DNS queries for a domain within one or more VPCs. Queries from inside the associated VPC get answers from this zone. Queries from outside the VPC (or the public internet) never see these records.

This requires enableDnsHostnames and enableDnsSupport both set to true on the VPC. You already confirmed this in Step 1.

🙋‍♀️ Don't see your VPC in the VPC ID list?

Make sure you selected us-east-1 as the Region first. The VPC list only shows VPCs in the selected region.

help me find my VPC when creating a private hosted zone

Create internal A records

Now you will add two A records inside the hosted zone. These represent a database server and an API server on your private network.

  • Inside the corp.internal hosted zone, choose Create record.
  • In the Record name field, enter db.
  • For Record type, choose A – IPv4 address.
  • In the Value field, enter 10.0.1.100.
  • For TTL (seconds), enter 300.
  • Choose Create records.

Now create the second record for your API server.

  • Choose Create record again.
  • In the Record name field, enter api.
  • For Record type, choose A – IPv4 address.
  • In the Value field, enter 10.0.1.200.
  • For TTL (seconds), enter 300.
  • Choose Create records.

The Records tab in your hosted zone should now display both A records alongside the default NS and SOA records.

Why these IP addresses?

The IPs 10.0.1.100 and 10.0.1.200 fall within your subnet's CIDR range (10.0.1.0/24). No actual server needs to be running at those addresses for DNS to resolve them. The records demonstrate how internal service discovery works on a real private network.

Verify DNS resolution inside and outside the VPC

The real test of a private hosted zone is that it answers queries from inside the VPC and stays invisible to everyone else. You will now verify both sides of this.

  • Return to your SSH session on the EC2 instance.
  • Run the following command to query your database record:
nslookup db.corp.internal

Before you check the output, what IP address do you expect this command to return?

You should see 10.0.1.100 in the response. The VPC Resolver at 10.0.0.2 answered using your private hosted zone.

  • Now query the API record by running:
nslookup api.corp.internal

This should resolve to 10.0.1.200.

What is the VPC Resolver?

Every VPC has a built-in DNS resolver at the VPC CIDR base address plus two. For your VPC (10.0.0.0/16), this is 10.0.0.2. EC2 instances use this resolver by default. It knows about your private hosted zones and routes queries accordingly.

Now verify that the same domain is invisible from outside the VPC.

  • On your local Windows machine (not inside the EC2 instance), open Command Prompt or PowerShell.
  • Run the following command:
nslookup corp.internal

What do you think will happen when you run this from your local machine?

The query fails with a Non-existent domain response. Public DNS has no record for corp.internal because it only exists inside your VPC's private hosted zone.

Why does this prove isolation?

When you query a private hosted zone from outside its associated VPCs, Route 53 does not answer. The query gets recursively resolved on the public internet instead, where corp.internal does not exist. This confirms your internal DNS records are completely invisible to external users.

🙋‍♀️ EC2 nslookup returning server can't find the domain?

Confirm that you created the private hosted zone with Type: Private hosted zone and associated dns-lab-vpc in the us-east-1 region.

Also verify that the record name you entered was db (not db.corp.internal). Route 53 automatically appends the zone name.

help me troubleshoot why my private hosted zone records are not resolving from EC2

Your private DNS is working. Internal names resolve inside the VPC while remaining completely hidden from the outside world. Next, you will explore how the same domain name can return different results depending on where the query originates, and learn how Route 53 Resolver extends DNS across hybrid environments.

Demonstrate Split-View DNS and Create a Resolver Outbound Endpoint

Your private hosted zone works perfectly inside the VPC, but it is completely invisible to the outside world. In the real world, you often need the same domain name to resolve differently for internal users versus external users.

In this step, you will demonstrate split-view DNS where the same domain returns a private IP from inside your VPC and a public IP from outside. You will also explore Route 53 Resolver architecture and create an outbound endpoint that enables hybrid DNS forwarding to on-premises servers.

In this step, get ready to:
  • Demonstrate split-view DNS where the same domain resolves to different IPs inside versus outside your VPC.
  • Understand Route 53 Resolver architecture, Profiles, and DNSSEC concepts for the SAA-C03 exam.
  • Create a Resolver outbound endpoint to enable hybrid DNS forwarding.
Create a split-view private hosted zone

Split-view DNS means the same domain name resolves to different IP addresses depending on where the query originates. You will create a private hosted zone named example.com associated with your VPC. Since example.com already exists in public DNS, the VPC Resolver will automatically prefer your private zone for queries originating inside the VPC.

What is split-view DNS?

When you create a private hosted zone with the same name as a domain that exists in public DNS, Route 53 uses the private zone to route DNS queries from within associated VPCs.

Queries from the public internet continue to hit the public DNS records as normal. This lets you serve internal IPs to your infrastructure while external users see the real public addresses. You do not need to own the domain to demonstrate this.

  • In the Route 53 console, choose Hosted zones in the left navigation pane.
  • Click Create hosted zone.
  • In the Domain name field, enter example.com.
  • Under Type, select Private hosted zone.
  • In the Region dropdown, select us-east-1.
  • In the VPC ID dropdown, select your dns-lab-vpc.
  • Click Create hosted zone.

Your private hosted zone for example.com now exists alongside the real public DNS records for that domain. Next, add an A record that points to a private IP.

  • Inside your new private hosted zone, click Create record.
  • In the Record name field, enter www.
  • Leave the Record type as A.
  • In the Value field, enter 10.0.1.50.
  • Set the TTL to 300 seconds.
  • Click Create records.

You now have a private hosted zone record for www.example.com pointing to 10.0.1.50. Time to prove it works differently inside and outside the VPC.

Before you test, what do you expect nslookup for www.example.com to return from inside the VPC versus from your local machine?

  • In your SSH session with dns-lab-ec2, run the following command:
nslookup www.example.com

The result shows 10.0.1.50 as the address. This is your private hosted zone responding from inside the VPC, overriding the real public IP for example.com.

  • Now open a terminal on your local machine (Command Prompt or PowerShell on Windows, Terminal on macOS) and run the same query:
nslookup www.example.com

From your local machine, the result shows the real public IP for example.com (something like 93.184.215.14). The same domain name returns completely different addresses depending on where the query originates.

Why do the results differ?

The VPC Resolver checks for a private hosted zone matching the query domain before forwarding to the public internet. Since your VPC is associated with the private zone for example.com, internal queries are answered by your private records.

Your local machine has no association with the private zone, so its query goes through public DNS and gets the real example.com IP address. This is split-view DNS in action.

🙋‍♀️ EC2 still showing the public IP?

Confirm you selected the correct VPC (dns-lab-vpc) when creating the private hosted zone for example.com. Open the hosted zone and check the Associated VPCs section.

If the VPC association is missing, click Edit hosted zone and add it. DNS changes propagate within a few seconds for private zones.

help me troubleshoot my split-view DNS setup in Route 53

Understand Route 53 Resolver architecture

The SAA-C03 exam tests several Route 53 Resolver concepts that go beyond what you can demonstrate in a single-VPC lab. This section covers the architecture you need to know for the exam.

What is the VPC Resolver?

Every VPC gets a built-in DNS resolver at the VPC CIDR+2 address (for your VPC, that is 10.0.0.2). This resolver handles all DNS queries from your EC2 instances by default.

Inbound endpoints allow on-premises DNS resolvers to forward queries INTO your VPC, resolving private hosted zone records. They require a Direct Connect or VPN connection.

Outbound endpoints allow your VPC to forward queries OUT to on-premises or custom DNS servers. Each endpoint requires a minimum of two ENIs in different Availability Zones, costing $0.125 per ENI per hour.

Route 53 also provides Profiles and DNSSEC features relevant to multi-account and hybrid architectures.

What are Route 53 Profiles?

Route 53 Profiles are centralized containers that group DNS configurations for sharing across VPCs and accounts via AWS RAM. Only one Profile can be associated per VPC.

A Profile can include private hosted zones, Resolver rules, DNS Firewall rule groups, interface VPC endpoints, and VPC Resolver query logging configurations. Profiles are regional resources and can be associated with up to 5,000 VPCs.

The exam also tests DNSSEC concepts for securing public hosted zones.

What is DNSSEC in Route 53?

DNSSEC signing applies to public hosted zones and uses two key types. The Key Signing Key (KSK) is a customer-managed AWS KMS asymmetric key with the ECC_NIST_P256 spec, and must be in US East (N. Virginia).

The KSK signs the Zone Signing Key (ZSK), which Route 53 manages and rotates automatically. A DS record in the parent zone establishes the chain of trust. DNSSEC validation can be enabled per-VPC via Route 53 Profiles without enabling signing on your own zones.

Create a Route 53 Resolver outbound endpoint

With split-view DNS proven, you will now create the infrastructure that enables hybrid DNS forwarding. An outbound endpoint gives your VPC a path to forward DNS queries to external DNS servers.

Why build an outbound endpoint?

In enterprise environments, on-premises data centers run their own DNS servers. An outbound endpoint lets your VPC forward queries for corporate domains (like *.example.corp) to those servers instead of querying public DNS.

Each endpoint needs at least two ENIs in different Availability Zones for redundancy. In the next step, you will attach a forwarding rule that tells the endpoint which domains to forward.

  • In the Route 53 console left navigation pane, expand Resolver and choose Outbound endpoints.
  • Click Create outbound endpoint.
  • In the Endpoint name field, enter outbound-to-corp.
  • In the VPC in the us-east-1 Region dropdown, select dns-lab-vpc.
  • In the Security group for this endpoint dropdown, select dns-lab-sg (it already allows all outbound traffic, which covers port 53).
  • Leave the Endpoint type set to IPv4.

Now configure the two required IP addresses in different Availability Zones.

  • Under IP addresses, for the first IP address, select Availability Zone us-east-1a and subnet dns-lab-subnet-1.
  • Leave the IP address selection as Use an IP address that is selected automatically.
  • For the second IP address, select Availability Zone us-east-1b and subnet dns-lab-subnet-2.
  • Leave the second IP address selection as auto-assigned as well.
  • Click Create.

What does this endpoint do?

The two ENIs act as network interfaces through which forwarded DNS queries leave your VPC. Having them in separate Availability Zones provides redundancy.

The endpoint alone does not forward anything yet. You need a forwarding rule (created in the next step) to tell the endpoint which domains to send and where to send them.

📣 Resolver endpoint costs

Each ENI costs $0.125 per hour. With two ENIs, that is $0.25 per hour. Make sure to delete this endpoint in the Before You Go section when you are done with the project.

  • Wait 1-2 minutes for the endpoint to provision. Refresh the page and confirm the Status column shows Operational.

Endpoint stuck in Creating?

Endpoint creation typically takes 1-2 minutes. If the status has not changed after 5 minutes, check that your subnets have available IP addresses and that the VPC does not use dedicated instance tenancy.

help me troubleshoot my Route 53 Resolver outbound endpoint that is not becoming operational

Your outbound endpoint is now live and waiting for instructions. In the next step, you will create a forwarding rule that tells this endpoint exactly which domain queries to intercept and where to send them.

Create a Resolver Forwarding Rule and Verify Hybrid DNS

Your outbound endpoint is operational, but it is not forwarding anything yet. Without a forwarding rule telling the Route 53 Resolver which domains to forward and where to send them, all DNS queries still go through normal public DNS resolution.

In this step, you will create a forwarding rule that directs queries for a specific domain to a target IP address, simulating how enterprises bridge AWS and on-premises DNS. You will then verify the forwarding behavior from inside your EC2 instance.

In this step, get ready to:
  • Create a forwarding rule for the example.corp domain.
  • Associate the rule with your VPC so it takes effect.
  • Verify the forwarding behavior by comparing DNS responses from inside your EC2 instance.
Create a forwarding rule

A forwarding rule tells the VPC Resolver to send DNS queries for a specific domain to designated target IP addresses instead of resolving them through public DNS. You will create one that forwards all queries for *.example.corp to 10.0.1.50, simulating an on-premises DNS server.

  • In the Route 53 console, expand Resolver in the left navigation pane.
  • Select Rules.
  • Choose Create rule.
  • Enter forward-to-onprem in the Name field.
  • For Rule type, select Forward.
  • Enter example.corp in the Domain name field.
  • For Outbound endpoint, select your outbound-to-corp endpoint.
  • Under Target IP addresses, enter 10.0.1.50.
  • Choose Submit.

What is a forwarding rule?

A forwarding rule is a conditional instruction for the VPC Resolver. It says: "When you see a DNS query for this domain, don't resolve it through public DNS. Instead, forward it through the outbound endpoint to these specific IP addresses."

In a real hybrid architecture, the target IP would be an on-premises DNS server reachable via Direct Connect or VPN. Here, you are simulating that scenario with a private IP inside your VPC.

💡 Why Forward instead of System or Delegate?

Route 53 Resolver supports three rule types. Forward sends queries for a domain to your network resolvers. System overrides forwarding for a subdomain so the VPC Resolver handles it locally. Delegate passes authority using NS records.

Forward is the most common type for hybrid DNS because it covers the simple case: send all queries for a corporate domain to an on-premises DNS server.

Associate the rule with your VPC

A forwarding rule only takes effect after it is associated with a VPC. Without association, queries from your instances will not be forwarded.

  • On the Rules page, select the forward-to-onprem rule you just created.
  • Choose Associate VPC.
  • Select your dns-lab-vpc and confirm the association.

The rule status changes to Complete. Any DNS query for *.example.corp originating from your VPC will now be forwarded through the outbound endpoint to 10.0.1.50.

Rule status not showing Complete?

Make sure you selected your VPC during the association step. The rule only activates for VPCs explicitly associated with it.

If the status stays at a non-Complete state, wait 10-15 seconds and refresh the page. Why isn't my forwarding rule showing Complete status?

Verify forwarding from your EC2 instance

The true test of a forwarding rule is observing how the Resolver handles queries differently. You will compare what happens when you query a domain covered by the rule versus a domain that goes through normal public DNS.

  • Switch back to your SSH session on the dns-lab-ec2 instance.

Before you run the next command, think about what you expect to happen. There is no actual DNS server running at 10.0.1.50. Will the query succeed, fail with NXDOMAIN, or do something else?

  • Test the forwarding rule by running this command:
nslookup test.example.corp

The query times out after several seconds. This is the expected behavior. The Resolver is attempting to forward the query to 10.0.1.50, but since no DNS server is running there, the connection hangs until it times out.

  • Now compare this to a query for a domain that is not covered by any forwarding rule:
nslookup test.nonexistent.xyz

This query returns NXDOMAIN instantly. The public DNS resolver immediately tells you the domain does not exist.

Why does the difference matter?

The timeout versus the instant NXDOMAIN proves two completely different DNS paths. For test.example.corp, the Resolver forwards the query through your outbound endpoint to the target IP. The timeout shows it is actively attempting to reach a DNS server.

For test.nonexistent.xyz, the Resolver goes through normal public DNS resolution and gets an immediate answer that the domain does not exist. If the forwarding rule were not working, both queries would return NXDOMAIN instantly.

💡 What would this look like in production?

In a real hybrid architecture, 10.0.1.50 would be an on-premises DNS server reachable via Direct Connect or VPN. The query would resolve instantly to the internal IP of your corporate service. The SAA-C03 exam tests this architecture pattern frequently.

🙋‍♀️ Both queries returning NXDOMAIN instantly?

If nslookup test.example.corp returns NXDOMAIN immediately instead of timing out, the forwarding rule is not active for your VPC.

  • Return to the Route 53 console and confirm the rule shows status Complete.
  • Verify that dns-lab-vpc appears in the associated VPCs list for the rule.
  • Confirm the domain name on the rule is exactly example.corp with no trailing dot or spaces.

Why is my forwarding rule not forwarding queries?

Your hybrid DNS forwarding is working. The Resolver routes queries based on your rules, sending corporate domain lookups to your designated target while everything else resolves through public DNS. Next up, you will layer DNS-level security on top of this environment by blocking queries to known-bad domains with DNS Firewall.

Secret mission

DNS Firewall - Block Suspicious Domains

Your VPC can resolve internal names and forward queries for corporate domains. But what stops an attacker from using DNS to exfiltrate data or phone home to a malicious server? In this mission, you'll layer DNS Firewall on top of your private DNS environment to block queries to known-bad domains before they ever leave your VPC.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The Resolver outbound endpoint is the most expensive resource in this project at $0.25/hour, so cleanup is critical if you are done experimenting.

Cost warning

Your Route 53 Resolver outbound endpoint has 2 ENIs costing $0.125 per ENI per hour ($0.25/hour total). If you leave it running overnight (8 hours), that is $2.00 in charges. Delete the outbound endpoint first if you choose to clean up.

Resources you used:

  • Route 53 Resolver outbound endpoint (outbound-to-corp) with 2 ENIs at $0.125/ENI/hour.
  • Resolver forwarding rule (forward-to-onprem) associated with dns-lab-vpc.
  • DNS Firewall rule group (BlockSuspicious) with domain list (SuspiciousDomains), associated with dns-lab-vpc.
  • Private hosted zone: corp.internal (with A records for db and api).
  • Private hosted zone: example.com (private type, with www A record).
  • EC2 instance (dns-lab-ec2), t2.micro, free tier eligible.
  • VPC (dns-lab-vpc) with subnets, internet gateway, route tables, and security group.

Keep everything running

No action needed. Choose this if you plan to continue experimenting with DNS configurations within the next few hours.

  • Your Resolver outbound endpoint costs $0.25/hour while active. Monitor your billing dashboard if you keep it running.
  • Private hosted zones cost $0.50/month each. This is negligible for short-term experimentation.
  • The EC2 instance is free tier eligible, so it will not add cost.
  • The forwarding rule and DNS Firewall rule group have no hourly charge. DNS Firewall charges $0.60 per million queries, which is negligible for testing.

Pause - I'll come back to this later

Shut down the expensive resources while keeping your DNS configuration intact. Total ongoing cost is approximately $1/month for the hosted zones.

  • Delete the Resolver outbound endpoint (outbound-to-corp) to stop the $0.25/hour charge. In the Route 53 console, go to Resolver > Outbound endpoints. Select outbound-to-corp and choose Delete.
  • Terminate the EC2 instance. In the EC2 console, select dns-lab-ec2, choose Instance state > Terminate instance.
  • Leave the private hosted zones, forwarding rule, DNS Firewall rule group, and VPC in place. These cost very little when idle.

Delete - I don't want to use this again

Remove all project resources completely. Follow this order to avoid dependency errors.

Step 1: Delete DNS Firewall resources.

  • In the Route 53 console, choose DNS Firewall in the navigation pane.
  • Select the BlockSuspicious rule group. Go to the Associated VPCs tab, select dns-lab-vpc, and choose Disassociate.
  • Delete the rule BlockBadDomains from within the rule group, then delete the BlockSuspicious rule group itself.
  • Go to Domain lists and delete the SuspiciousDomains domain list.

Step 2: Delete the forwarding rule.

  • In the Route 53 console, go to Resolver > Rules.
  • Select forward-to-onprem. Go to the Associated VPCs tab, select dns-lab-vpc, and choose Disassociate.
  • After disassociation completes, delete the forward-to-onprem rule.

Step 3: Delete the outbound endpoint.

  • In the Route 53 console, go to Resolver > Outbound endpoints.
  • Select outbound-to-corp and choose Delete. Wait for the status to change to Deleting and then disappear from the list.

Step 4: Delete private hosted zones.

  • In the Route 53 console, go to Hosted zones.
  • Open the corp.internal hosted zone. Delete the A records for db and api (you cannot delete the NS and SOA records manually). Then go back and delete the hosted zone itself.
  • Open the example.com private hosted zone. Delete the www A record, then delete the hosted zone.

Step 5: Terminate the EC2 instance.

  • In the EC2 console, select dns-lab-ec2.
  • Choose Instance state > Terminate instance. Confirm when prompted.

Step 6: Delete the VPC and associated resources.

  • In the VPC console, go to Your VPCs. Select dns-lab-vpc and choose Actions > Delete VPC.
  • AWS will automatically delete the associated subnets (dns-lab-subnet-1, dns-lab-subnet-2), route tables, and security group (dns-lab-sg) when deleting the VPC.
  • If the VPC deletion fails, manually detach and delete the internet gateway (dns-lab-igw) first. Go to Internet gateways, select dns-lab-igw, choose Actions > Detach from VPC, then Actions > Delete internet gateway. Retry deleting the VPC.

Delete your key pair if you created one

If you created a new key pair for this project, go to the EC2 console > Key Pairs and delete it. Also delete the .pem file from your local machine.

Nice Work!

Nice Work!

Nice work! You have built a complete private DNS environment inside AWS, from internal name resolution to hybrid forwarding to DNS-layer security controls.

You've learned how to:

  • Create a private hosted zone (corp.internal) with internal DNS records that resolve only from within your VPC, proving DNS isolation between private and public networks.
  • Demonstrate split-view DNS where the same domain name returns different IP addresses depending on whether the query comes from inside or outside the VPC.
  • Build a Route 53 Resolver outbound endpoint and forwarding rule for hybrid DNS resolution, and understand the architecture of inbound/outbound endpoints, Route 53 Profiles for multi-VPC management, and DNSSEC signing concepts with KMS integration.
  • Configure DNS Firewall to block queries to suspicious domains and verify the block in real-time from your EC2 instance (Secret Mission).

Ready to quiz yourself?