Last updated on June 5, 2023
Route 53 Private Hosted Zones
Amazon Route 53 DNS service supports Public Hosted Zones and Private Hosted Zones. Private Hosted Zones are useful when you want to use your private domain and have Route 53 respond to queries on that domain from resources within your VPC.
For example, if you host a database on an EC2 instance on a private subnet, you can create a Route 53 record set (ex: privatedb.tutorialsdojo.com) for that database instance on your Private Hosted Zone to allow other EC2 instances to resolve the domain name.
But what if you have a VPN connection (or AWS Direct Connect to Amazon VPC connection), and you want your on-premises servers to resolve the DNS record you have on the private hosted zone? The DNS resolver only replies to queries from resources within your associated VPC so you will need a different approach for this scenario.
In this post, we’ll show you how to set up an Ubuntu EC2 instance as a DNS forwarder that will allow your on-premise servers to resolve domain names in your Private Hosted zones.
The setup overview
In this setup, you will use a new Ubuntu EC2 instance that will accept DNS queries from your on-premises servers, and then forward them to Amazon Route 53. The reply will be sent back to the on-premises server to effectively resolve domain names in the private hosted zone.
You should have an entry on your private hosted zone for your domain, ex: privatedb.turtorialdojo.com pointed to EC2 instance 10.10.0.5, as shown in the diagram below.
Configure your DNS forwarder
Before you proceed, you need to ensure that DNS resolution and DNS Hostnames are enabled on the target VPC. Refer to this link on how to do that on your custom VPC.
** The default VPC and VPCs created from the VPC wizard in the AWS Console have them enabled by default, so you don’t need extra effort for that.
1. Create a new Ubuntu EC2 instance on the same VPC where you have the MySQL EC2 instance. Let’s assume that the IP address is 10.10.0.6.
2. Update the security group of the new EC2 instance to allow inbound port 53 and protocol TCP & UDP, where the source is your on-premises network IP.
3. SSH to your newly created EC2 instance. Refer to this link on how to SSH.
4. Once logged in, you can check the current DNS resolver used by the instance with the following command:
$ cat /etc/resolv.conf
Sample output:
# Generated by NetworkManager
search ap-southeast-1.compute.internal
nameserver 10.10.0.2
5. To receive DNS queries, the BIND DNS server needs to be installed. To install the package to your instance, use this command:
$ sudo apt install bind9 bind9utils -y
6. Next, configure the BIND server to be a forwarder by modifying the contents of the /etc/bind/named.conf.options file.
$ sudo nano /etc/bind/named.conf.options
7. Inside the file, before the “options” section, create an access control list (ACL) for the BIND server of the IP addresses that you trust i.e. the IP block of the on-premises network for this example. Follow the syntax of the bind config file, with semicolon on every statement.
acl “trusted” { 10.20.0.0/24; localhost; }; options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; };
8. Inside the “options” section, configure BIND to forward all DNS requests to the Amazon VPC name server. The nameserver is always the second available IP address in your VPC CIDR block. In this example, it is 10.10.0.2 as we confirmed in Step 4. Add this IP as forwarders, as shown below:
options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; forwarders { 10.10.0.6; }; };
9. Next, add “forward only” entries then add the “trusted” ACL on the “allow-query” list and “allow-recursion” list to limit permitted hosts to query the BIND Server. Also set “dnssec-validation” to “no” since Route53 does not support DNSSEC at this time. Your config file should look like this:
acl “trusted” { 10.20.0.0/24; localhost; }; options { directory "/var/cache/bind"; dnssec-validation no; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; forward only; allow-query { trusted }; allow-recursion { trusted}; };
10. Save and exit the file. Test the syntax of the BIND config file with the following command
$ sudo named-checkconf /etc/bind/named.conf.options
11. No output means that the syntax is correct. Finally, you can restart the BIND process to apply the changes:
$ sudo service bind9 restart
After setting up the BIND server on your new Ubuntu instance, you have to configure your on-premises servers to use this as their DNS server to resolve the domains in the hosted private zone.
Update DNS Setting of your on-premises servers
Changing the DNS server on your on-premises servers depends on the operating system.
On Linux servers, you can edit the /etc/resolv.conf file (like the one on Step 4) and change the nameserver entry.
Example:
$ cat /etc/resovl.conf
# Generated by NetworkManager
search company.internal
nameserver 10.10.0.6
On Windows-based servers, you can edit the DNS on the Network Connections Setting. Example:
Test DNS resolution
To test DNS resolution, login to your on-premises Linux server and use the dig command.
$ dig privatedb.tutorialsdojo.com
Sample output (truncated, only showing the answer section):
;; ANSWER SECTION:
privatedb.tutorialsdojo.com. 233 IN A 10.10.0.5
Note: If you are studying for the AWS Certified Advanced Networking Specialty exam, we highly recommend that you take our AWS Certified Advanced Networking – Specialty Practice Exams and read our Advanced Networking Specialty exam study guide.
Sources:
https://aws.amazon.com/premiumsupport/knowledge-center/r53-private-ubuntu/
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario4.html
This article is authored by: Kenneth Samonte, our resident AWS whiz/contributor.