Setup AWS R53 Private Hosted Zone (Beginners Tutorial)

In this tutorial, you will learn to setup AWS Route53 Private hosted zone to resolve private DNS in AWS environment.

Need for Route53 Private Hosted Zone

Let’s understand why we need a Private Hosted Zone when we already have public ones.

AWS Route 53 is a managed DNS service that handles DNS for both AWS and non-AWS resources.

In production setups, many applications run in private VPC subnets. To use DNS names for these internal services, you need private DNS, DNS that works only inside the VPC or through VPN access.

This is where Route 53 Private Hosted Zones help. They allow DNS resolution within AWS’s internal DNS system, limited to the VPC. So, you don’t need to set up your own DNS server.

In short, Private Hosted Zones let you use custom domain names for internal AWS resources without exposing them to the public internet.

How Does Private Route53 Hosted Work?

The private hosted zone setup is required when you want to access the AWS resource typically privately over a VPN.

The workflow diagram explains the AWS Route53 private hosted zone configurations as well as the integration of a VPN Server.

Here’s how it works:

1. The Route 53 Private Hosted zone is a private DNS space within the VPC, the domain names will be resolved only within the same network.
2. The VPN Connection is established from the client (user) side to communicate with the VPC so its like the local workstation and the VPC are in a same network.
3. In the local DNS resolver configuration or the /etc/resolve.conf configuration, we define the VPC DNS server IP. So the DNS query will directly go to the VPC DNS resolver through the VPN connection.
4. The VPC DNS resolver looks the hostname on the Route53 private hosted zone and identifies the actual IP behind the hostname.
5. The resolver returs the IP to the local machine so that the local machine can access the private AWS Resources.

AWS Route53 Private Hosted Zone Setup

Now lets get started with the setup.

Follow the below steps to setup a private hosted zone in AWS Route53.

Step 1: Create a Private Hosted Zone

Open the AWS Route53 service and select the Hosted zones tab from the left side panel.

On the following window, click the Create hosted zone button to create a new hosted zone.

Provide a domain name that you want (techiescamp.com), you can provide any name.

Select the types as Private hosted zone and on the VPC association section, select the region of the VPC and its ID.

Once provide all the required information, click the Create hosted zone button to create the private hosted zone.

After the successful creation of the private hosted zone, two records will be available by default.

What are they?

1. The first one is the NS record which represents the Name Server Record. These records define the internal name servers that are responsible for the DNS resolution only within the VPC.
2. The second one is the SOA which represents the Start of Authority Records, this will provide the metadata about the hosted zone, such as admin contact, serial number, and timing values(refresh, retry, and expire).

The Route53 private hosted zone setup is done, now we can test the setup.

How to Validate the Route53 Private Hosted Zone?

The private hosted zone setup is completed now.

So how can we test it?

Well. we can create a simpe Nginx server on the private subnet and map the IP of that server to the Route53 private hosted zone.

Then try to access it from the public server using the hostname.

For that, we need to create an EC2 instance on both public and private subnets.

Step 1: Create Test Servers

To test the private DNS configuration, we need one server in a public subnet and another in the private subnet.

We will be acessing the private server from the public server.

For this testing I am using two ubuntu instance instances. One in public subnet and one in private subnet.

Step 2: Install an Nginx Web Server on the Private Server

Since the private server doesn't have public access, we can only access it from the public server.

So open the public server and SSH to the private server, but before that note down the private server's IP address.

Now open the public server.

Select the EC2 Instance Connect option to connect the public server through the web terminal.

To SSH to the private server from public, we need the key pairs that we used to create the private server.

You need to copy all the contents from the key pairs and paste it in the public server terminal as a .pem extension file.

Create a .pem file in the public server and store the Key Pairs contents.

Using the following command, we can SSH to the private server to install the Nginx server.

ssh -i key.pem ubuntu@<PRIVATE_SERVER_IP>

To install Nginx on the Ubuntu server, use the following command.

sudo apt update
sudo apt install nginx -y

Note: The private subnet should be attached with NAT, otherwise application packages won't be downloaded from the internet for the Nginx installation.

To check the service after the installation,

systemctl status nginx.service

This ensures that the service is active and running, so now we need to check the localhost access.

curl localhost

You can see the welcome page, which means that the web server page is actively loading on the private server itself.

Now, we need to check it directly from the public server.

So, you need to exit from the private server using the following command.

exit

Before directly accessing the Nginx server from the public server, ensure the private server's security group allows port 80 to the public server.

Once the security group rules are correctly set, we can access the private Nginx server from the public server using its private IP.

curl <PRIVATE_SERVER_IP>

But this is not we want, we need to access this private Nginx server via a domain name.

Step 3: Map Private IP to the Hostname on Route53

We can map the same private IP to the Route53 private hosted zone, so that we can access this Nginx server using the hostname.

When we try to access, the DNS resolution will happen by the internal DNS servers, which AWS manages.

To map the private IP, navigate to the Route53 console private hosted zone and create a new DNS record.

Create a prefix for the record name e.g., nginx and select the record type as A which will map the IP with hostname.

In the Value section, we need to add the IP of the private Nginx server, then click to Create records to create the record.

It will take a few minutes to complete and then you can see the record on the dashboard.

Now, we can access the Nginx server from the public server using this hostname instead of the IP address.

curl <HOST_NAME>

It is working, but what if I want to access it from my local machine?

First, you need to establish a VPN connection between your local machine and the AWS VPC.

Validating Route53 Private Hosted Zone From Local Workstation using VPN

In this section, we will initiate the DNS resolution from the local machine to access the AWS resources securly over a VPN encrypted tunnel.

For this to work, we need a VPN connection between our local machine and the specific AWS VPC.

I am using the Pritunl Self-hosted VPN server for this demo, but you can use any VPN setup like OpenVPN, AWS Client VPN Endpoint, etc.

To know about the setup of the Pritunl VPN in an EC2 instance, you can refer to this blog How to Setup Pritunl VPN

Once the VPN connection is established, we can access the private Nginx server from our local machine by using its private IP as like we did in the public server.

Here, you can see that the DNS resolution is not happening. This is because the local system is not part of the AWS VPC and doesn't have DNS server details.

So, we need to add the DNS server details.

In the Pritunl configuration, we can provide the DNS server details, but how can we identify the DNS server information, such as its IP?

Well, for the custom DNS servers in the VPC, the IP of the DNS server is the second IP from the CIDR range. For example, if the VPC CIDR is 10.0.0.0/16, then the DNS server IP is 10.0.0.2.

To learn more about this, please refer to the official documentation.

We need to configure this for the DNS resolution on the VPN server configuration.

After changing the DNS server on the VPN configuration, when you establish the VPN connection from your local machine, your default DNS server configuration on the local machine will automatically be changed, and you can check that from the /etc/resolve.conf

This ensures that the resolution will happen only through this DNS server.

Now, we can check access from the local machine using the hostname.

Not only check from the terminal, but you can also directly check from the web browser.

Bonus Configuration

Instead of configuring the DNS server information directly to the VPN server, we can only configure it in our local machine to harden the security.

First, we need to keep the DNS details on the VPN server dashboard empty.

Now, configure the DNS server information on the local machine.

I am setting up on the MAC workstation, but it would be similar to every operating system.

On the DNS configuration section, add the DNS server IP

After adding the DNS server details on the local machine, we can use the hostname to access the private server resources in a secure manner.

After the hands-on, you can use the following commands to destroy the setup.

aws cloudformation delete-stack --stack-name EC2InstanceStack --region us-east-1

Route53 Public Vs Private Hosted Zone

1. A public hosted zone is for the resources accessed by the user over the internet, such as public websites, etc. Here, the DNS resolution will happen on public DNS servers
2. A private hosted zone is for internal resources, such as databases, etc. Here, the DNS resolution only occurs within the network by the internal DNS servers.

Conclusion

This is the effective method of using the Route53 Private hosted zone to access the private resources from the local machine.

You can use any VPN server to communicate between the local machine and the AWS VPC.

A single hosted zone creation will cost $0.50 per month. This will be the same up to 25 hosted zones, and if it goes beyond that, each new one will cost an additional $0.10 per month.