ANS Exercise 1.4: DNS Fundamentals

ANS Exercise 1.4: DNS Fundamentals

Luc van Donkersgoed

Luc van Donkersgoed

In this exercise we will look at the Domain Name System (DNS) implementation in AWS VPCs. We will look at DNS hostnames, DNS resolution, and Route 53 integration.

This is exercise 1.4 for the AWS Advanced Networking Specialty training. For an explanation and overview of all exercises, see the overview post.

The exercises are built on the assumption that you’re already familiar with the AWS basics and have achieved at least one associate level AWS certification.

Create a VPC

Log in to your AWS account and navigate to the VPC console. On the VPC Dashboard click the “Launch VPC Wizard” button.


Next, select “VPC with a Single Public Subnet” and click Select.


Give the VPC a name and click the “Create VPC” button.

Select your VPC in the VPC overview page, and look at the Description tab in the bottom. You will see that the options “DNS resolution” and “DNS hostnames” are set to Enabled.


Launch an EC2 Instance

Navigate to the EC2 console and click the “Launch Instance” button.


Select the latest Amazon Linux 2 AMI for x86, a t2.micro instance, and enable “Auto-assign Public IP” under instance details:


In Step 6: Configure Security Group, make sure you open port 22 to your IP address. In the last step, select an existing SSH key or create a new one.

DNS Hostnames

When the instance has booted up, SSH to it and run hostname. The result should look like this:

[ec2-user@ip-10-0-0-128 ~]$ hostname

As you can see, the EC2 instance has an internal hostname. This address will be resolvable by any resource within the AWS ecosystem. The .internal TLD will not resolve anywhere outside AWS.

We can also query the EC2 metadata service for the instance’s public hostname:

[ec2-user@ip-10-0-0-128 ~]$ curl

This is the Fully Qualified Domain Name (FQDN) for the instance. There are two requirements leading to an EC2 instance having a FQDN:

  1. The instance needs to have a public IP (either a dynamic public IP or an Elastic IP)
  2. The VPC setting DNS hostnames needs to be enabled.

Let’s disable the DNS hostnames setting and see what a instance’s addresses look like then.

Disable DNS Hostnames

Navigate to the VPC console, select your VPC and click “Edit DNS hostnames”.


Uncheck the checkbox and click Save.


Spin up a new EC2 instance using the same settings as before. Then SSH into the instance. Running the same commands now shows these results:

[ec2-user@ip-10-0-0-229 ~]$ hostname
[ec2-user@ip-10-0-0-229 ~]$ curl
[ec2-user@ip-10-0-0-229 ~]$

The internal hostname is still there, but there is no public hostname anymore.

DNS Resolution

From one of the instances above, run the command host while DNS Hostnames are still disabled in your VPC’s configuration. The result should be like this:

[ec2-user@ip-10-0-0-128 ~]$ host
Host not found: 3(NXDOMAIN)

Now re-enable the DNS Hostnames in you VPC settings, wait a few minutes, and try again. The result should be updated to this:

[ec2-user@ip-10-0-0-128 ~]$ host has address

You can resolve any hostname in this format, regardless whether you have resources with that hostname:

[ec2-user@ip-10-0-0-128 ~]$ host has address

Resolving public addresses

Resolving the public DNS name (eg. from your laptop would result in its public address:

➜  ~ host has address

Like the private hostnames, these addresses always resolve, whether they are in use or not.

When you try to resolve a public address you own from within the same VPC, the AWS DNS server will return the private address, but when you don’t own the resource, the public address is returned:

[ec2-user@ip-10-0-0-229 ~]$ host has address
[ec2-user@ip-10-0-0-229 ~]$ host has address

The AWS DNS server

If your VPC has DNS Resolution set to enabled, AWS provides an DNS server for the resources in your environment. This server resolves both private resources (eg. and public resources (eg.

The AWS DNS server is available at your subnet’s base address + 2 ( in our example), but can also be reached at (not to be confused with the metadata service at

[ec2-user@ip-10-0-0-229 ~]$ host -t A
Using domain server:
Aliases: has address
[ec2-user@ip-10-0-0-229 ~]$ host -t A
Using domain server:
Aliases: has address

By default, all DNS queries on EC2 instances will be forwarded to the AWS DNS server. As discussed in the previous exercise (DHCP Fundamentals
), this server has been configured in the instance’s /etc/resolv.conf:

; generated by /usr/sbin/dhclient-script
options timeout:2 attempts:5
search eu-west-1.compute.internal

The last line in this file defines the DNS server’s address.

The line before that (search eu-west-1.compute.internal) is the search domain used when a DNS name without domain (eg. ip-10-0-1-2 is queried. When the domain is missing, the domain specified in the search line is used instead. For example:

[ec2-user@ip-10-0-0-229 ~]$ host ip-10-0-1-2 has address

Disabling the AWS DNS server

The AWS DNS server can be disabled in the VPC settings. When you do, two things happen:

  1. The DNS server at your subnet’s base address + 2 / is no longer reachable.
  2. DNS hostnames are disabled, just like when you would have manually set the the DNS hostnames option to disabled.

Let’s disable the DNS resolution option and verify this:



[ec2-user@ip-10-0-0-229 ~]$ host ip-10-0-1-2
;; connection timed out; no servers could be reached
[ec2-user@ip-10-0-0-229 ~]$ host ip-10-0-1-2
;; connection timed out; no servers could be reached
[ec2-user@ip-10-0-0-229 ~]$ curl

With DNS resolution disabled, there is no AWS DNS server anymore, nor do we have a public hostname.

Integration with Route 53

For the next section, make sure DNS hostnames and DNS resolution are enabled for your VPC.


Now resolve from an EC2 instance:

[ec2-user@ip-10-0-0-229 ~]$ host has address

The result is a public address. But a common scenario would require an EC2 instance to resolve the target’s private address, for example if you want to route traffic over VPN.

In this example, when a customer wants to visit, the hostname for should resolve to the public address. But when an internal system needs to connect to, the hostname should resolve to its private address (eg.

As we’ve seen before, the AWS DNS server already does something like this for EC2 hostnames:

[ec2-user@ip-10-0-0-229 ~]$ host has address
[ec2-user@ip-10-0-0-229 ~]$ host has address

With Route 53 Private Zones we can achieve the same result for every domain. Let’s build that now.

Navigate to the AWS Route 53 console and click the “Create Hosted Zone” button.


In the next screen, fill in your domain name, select the Private Hosted Zone type and select your VPC. The screen will remind / warn you that DNS hostnames and DNS resolution need to be enabled for your VPC.


If you would select “Public Hosted Zone”, the domain would be publicly resolvable. By setting it to “Private Hosted Zone” we will assure that it will only be used within the VPC.

Click Create. Then click the Create Record Set button. Fill in the following details:


Click the “Create” button at the bottom of the page, and our private hosted zone is complete.

Navigate back to the SSH session to your EC2 instance and run host

[ec2-user@ip-10-0-0-128 ~]$ host has address



In this exercise we’ve seen how AWS assigns public and private hostnames to resources in a VPC if DNS hostnames and DNS resolution are enabled.

If DNS resolution is enabled, the AWS-managed DNS server is available at your subnet’s base address + 2 and

If both DNS hostnames and DNS resolution are enabled, AWS supports overriding public DNS records with private DNS.

In a future exercise we will replace the AWS-managed DNS server with one of our own.

Luc van Donkersgoed
Luc van Donkersgoed