Private Hosted Zone in AWS Route53 allows to limit access to DNS records of a domain, thus making it inaccessible for the DNS Enumeration (or DNS brute-force), when an attacker checks for available records in a domain to know endpoints list to check them for vulnerabilities.
The idea behind using private domain zones is that they can be reached from inside of only a limited set of VPCs in an AWS account, but they can not be accessed from the Internet.
At first, let’s check how DNS is working in AWS VPC: in each VPC we have an address *.0.1 — it is its Gateway, and another address is the *.0.2 — it is the default DNS of a VPC.
For example, we have a VPC with the 10.0.6.0/24 CIDR. Thus, for this VPC we can reach the 10.0.6.2 to get information about a domain:
admin@bttrm-stage-console:~$ dig @10.0.6.2 ya.ru +short 18.104.22.168
This is the default DNS for services in an AWS VPC, although it can be configured for your own.
In our case, we have dnsmasq running on some of our old servers, and applications first will try to get information from it, and only then will go to the VPC's DNS:
admin@bttrm-stage-console:~$ cat /etc/resolv.conf domain us-east-2.compute.internal search us-east-2.compute.internal nameserver 127.0.0.1 nameserver 10.0.6.2 nameserver 22.214.171.124
See more in the DNS: установка BIND, DNS Load Balancing и network-based routing через view, and DNS: dnsmasq и порядок разрешения домён из resolv.conf posts (both in Rus), or in the documentation — Resolving DNS queries between VPCs and your network.
Keep in mind that to make DNS in a VPC working, this VPC must have options
enableDnsSupport enabled. Also, there are some limitations for the Route 53 health checks and routing policies. See more at Considerations when working with a private hosted zone.
Now, when we know how DNS in AWS VPC is working, let’s create a private DNS zone.
Go to the Route53, create a new zone, set its type to the Private hosted zone:
Below, you’ll see new options available to select AWS Regions and VPCs in them, from where this DNS zone will be accessible:
Now, when the zone was created, add some records in there:
For example, let’s add a record that will be pointed to one of our Staging servers — app1.stage.mobilebackend.bm.local:
And check if it’s available for another Staging server, located in this VPC:
admin@bttrm-stage-console:~$ dig app1.stage.mobilebackend.bm.local +short 10.0.6.68
Or by using the
admin@bttrm-stage-console:~$ dnstracer app1.stage.mobilebackend.bm.localTracing to app1.stage.mobilebackend.bm.local[a] via 10.0.6.2, maximum of 3 retries 10.0.6.2 (10.0.6.2) Got answer
And we got our response from the 10.0.6.2 — the VPC DNS server, as expected.
Now, try to reach the zone from the office:
15:06:02 [setevoy@setevoy-arch-work ~] $ dig app1.stage.mobilebackend.bm.local ; <<>> DiG 9.16.18 <<>> app1.stage.mobilebackend.bm.local ;; global options: +cmd ;; Got answer: ;; WARNING: .local is reserved for Multicast DNS ;; You are currently testing what happens when an mDNS query is leaked to DNS ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27027 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;app1.stage.mobilebackend.bm.local. IN A
And the world is knowing nothing about this DNS zone.
by the way, it’s possible to have the same DNS zone created as Public and private, so-called “split-view DNS”. See How can I use Route 53 to access an internal version of my website using the same domain name as my public website? и Split-view DNS.
Originally published at RTFM: Linux, DevOps, and system administration.