How to set up AWS DNS in a VPC

This post documents a technique that I used to set up DNS in AWS inside a VPC. Setting up DNS in a VPC is quite easy to do and allows you to use consistent naming across all your cloud and non-cloud servers. (You might also be interested in this discussion of how to configure AWS VPCs.)

Voila! Your names instead of Amazon's for internal VPC resolution
Voila! Your names instead of Amazon’s for internal VPC resolution (click to enlarge)

This DNS name resolution technique for AWS VPC is one that I like. There are probably dozens of ways of achieving convenient domain name resolution in a VPC, but I like this one because it works well when you have a mixture of OSs in private subnets that need to communicate with each other. And for private VPC subnets, it only exposes non-routable IP addresses while allowing public subnet servers to have their names resolved to AWS elastic IPs (EIP) via DNS. Because these RFC 1918 addresses are non-routable, there’s no information leakage by allowing DNS in your VPC to resolve them on the internet.

Once you get the hang of how this works, you’ll never think twice about it. But until then, it takes a little thinking through. Remember how DNS name resolution works: first, the hosts file, if any, is checked to see if it can resolve the name. Next, the local DNS server is queried. If the local DNS server cannot resolve the request, it will request (and usually cache) the entries from an authoritative DNS. If what it gets back from this query isn’t an address but is instead a canonical name (CNAME), the DNS server restarts the request, using the CNAME it received (see this Wikipedia entry on DNS). I rely on the way CNAMEs work in combination with the name resolution provided by VPC DNS.

First, we make sure to set up a VPC with an AWS-provided DNS resolver. Then, if a CNAME is returned for a request, the VPC DNS resolves it to the internal address in the VPC. In other words, all you need to do is to create CNAME records in a zone file (preferably Route 53 because it’s easy and inexpensive) and use the AWS-provided DNS server.

Yes, it’s a loopedy-loop. But it works — and works well.

This overview relies on CNAMEs coupled with Amazon’s DNS service, Route 53. Here’s how it works.

VPC DNS resolution using CNAMEs and Route 53
VPC DNS resolution using CNAMEs and Route 53 (click to enlarge)

Here’s more of a step-by-step breakdown that should help you implement this in your own VPC.

First, you want to set up your domain in Route 53. Route 53 has superior support for subdomains. That makes it possible for you to use a subdomain of a corporate domain that you can manage in Route 53 just for your VPC. In this model, the root corporate domain delegates control of a subdomain to Route 53. This is an extraordinarily convenient way of using DNS in a VPC

Unless you have direct access to the name servers for the base domain, this is the best way to go. Using a Route 53 subdomain for your VPC-managed domain means the owner of the base domain updates the base domain name servers just once. Thereafter, you can use Route 53 to manage the DNS names of your EC2 instances in a VPC without affecting the root corporate domain.

The subdomain approach is what I have illustrated here. Start by setting up the Route 53 domain and then add the generated name server entries to the base domain. These two screenshots show how to create a subdomain in Route 53 and add the name servers to a base domain, in this case which I own and which was registered at GoDaddy when this post was written.

Creating a subdomain in Amazon Route 53
Creating a subdomain in Amazon Route 53 (click to enlarge)
Example of adding NS records to parent domain (click to enlarge)
Example of adding NS records to parent domain

Next, make sure to select name resolution when you create your VPC. (It can also be added later.) This is what tells AWS to insert a DNS resolver in your VPC.  AWS automatically selects where to place the VPC — this is why you must leave the first few subnet addresses free in each subnet; the DHCP and DNS servers go into those addresses. If, for example, your VPC contains the subnets in, the DNS will be at AWS calls this the “plus-two” address. This screenshot shows what to select when creating a VPC. For more info on how AWS VPC DNS works, see this link. Remember: make sure to not use the first five or so addresses in your VPC’s subnets so AWS can map the DNS server into each of you VPC subnets!

Select DNS resolution when creating an Amazon VPC
Select DNS resolution when creating an Amazon VPC (click to enlarge)

Once you’ve set up your (sub)domain and given it time to replicate, you can add your own names to the Route 53 entry set. The trick here is to make sure that a) you use a CNAME entry and b) you use the AWS DNS-generated name for the instance. That is, of course, what the DNS server in the VPC uses to map to the actual IP address. You can get the internal name from the EC2 console for that instance, if you allowed AWS to assign a private address randomly. My personal best practice is to assign private IP addresses in ranges at instance creation so I know in advance how the CNAME entry should be created. Six of one, half dozen of another — just as long as you are certain you have the right name from the VPC DNS.

Add CNAME records to resolve your names in a VPC
Add CNAME records to resolve your names in a VPC (click to enlarge)

And presto! Now you can use real names that resolve inside the VPC for your EC2 instances! In the screenshot below, you can see that I did an nslookup for the Route 53-managed name, which resolved to a CNAME, which resolved to the internal IP address in the subnet, courtesy of the VPC DNS server.

Voila! Your names instead of Amazon's for internal VPC resolution
Voila! Your names instead of Amazon’s for internal VPC resolution (click to enlarge)






8 responses to “How to set up AWS DNS in a VPC”

  1. T Avatar

    Exposing your AWS private addresses through DNS is leaking information about your architecture.  It is a security risk.

    1. Alex Neihaus Avatar
      Alex Neihaus

      Well, “T” at email [email protected], IP, I guess this is one point of view.

      I’d argue on the other side that a). private addresses are well, private and b). that if your network architecture is dependent on private IP addresses, you have more issues than exposure of non-routable IP addresses.

      Comments and pushback are always welcome here. But if you comment, please leave your real name and an email. I don’t expose them — unless they’re fake, like T’s.

  2. […] blog has been receiving lots of traffic lately to a post on using AWS Route 53 DNS in a VPC. Google features the post in search results for folks interested in the topic and I am gratified […]

  3. David Avatar


    I am trying to do the same configuration on my end but my environment is a bit more complex as I have done BGP between AWS and IDC, so my machines in IDC aren’t able to resolve name, even if i point my name server to Any suggestions? Thank you very much.

    1. Alex Neihaus Avatar
      Alex Neihaus

      What is IDC?

  4. Aaron Avatar

    Just curious, but why do you need to set your CNAME record to return the VPC hostname, rather than just the private static IP?

    1. Alex Neihaus Avatar
      Alex Neihaus

      Great question.

      You can, of course, simply put in the private IP address in an A record and let the AWS DNS server resolve that name directly to the IP address in the subnet.

      It’s a matter of choice. I prefer the “self-documenting” and indirect nature of CNAMEs. In production, my Route 53 domain contains both private subnets and public subnets. Servers reachable on the public subnet get A records; private servers get CNAMEs. It’s an artificial distinction, but it helps me keep a long list of items sorted in my head.

      And, since all my servers cache addresses and you can set very long TTLs for the CNAMEs, I don’t mind the “double query” for the CNAMEs.

  5. […] been very gratified with the response to my tutorial describing how to use Route 53 CNAMEs to easily resolve names in an Amazon Web Services (AWS) virtual private cloud (VPC).  This post has gone straight to the top of search results on this topic — and visitors from […]

Leave a Reply

Your email address will not be published. Required fields are marked *