Approaching private hosted zones for DNS

Generally, when we put a domain name in the DNS, this domain will be resolved by the public DNS servers, such as 8.8.8.8. This means that even people outside the network can get a glimpse of what kind of software and applications are being used internally.

Let's look at the following screenshot to understand this. In the following image, we see that there are five subdomains for the record of internal.kplabs.in.

These subdomains are as follows:

• admin.internal.kplabs.in
• elk.nternal.kplabs.in
• phpmyadmin.internal.kplabs.in
• mongodb.internal.kplabs.in
• ipa.internal.kplabs.in

If an outsider looks into these subdomains, they can quickly map into what type of technologies are being used by an organization. From the following sample record sets, we can see that the organization is using various technologies such as PhpMyAdmin, MongoDB, ELK Stack, IPA, and has an admin page as well. This will help the attacker to refine the exploits in a much more granular way:

This is a sample screenshot of the records being queried by the public DNS servers:

This is one of the reasons why it is generally recommended to not include these record sets in the public hosted zones. It should ideally be inside private hosted zones that can be queried only via selected networks.

Since Route 53 does not directly support querying of records under private hosted zone by VPN or whitelisted IPs, many solutions architects decide to go the easy way and put all the records under the public hosted zones.

We will look at how we can create an ideal DNS configuration, which is based on both public and private hosted zones that work well with VPN.