Overview

By default, recursive DNS queries from instances within your VPC will be handled by AmazonProvidedDNS. In many cases, this is all you need.

However, some DNS zones at the University of Illinois are intentionally restricted to allow queries from University clients only, and therefore cannot be resolved by AmazonProvidedDNS. These zones include:

• ad.uillinois.edu
• Please note that some Active Directory resources have publicly resolvable DNS names and can be accessed without querying this zone; see Active Directory, U of I Resources in AWS for details.
  
• reverse-mapping zones for RFC1918 private IPv4 space on campus
  
• reverse-mapping zones for RFC1918 private IPv4 space in AWS Enterprise VPCs (if managed in IPAM)
  

This page describes the three options available for recursive DNS resolution within an Enterprise VPC, summarized graphically in the figure below.  The example Infrastructure-as-Code published by Technology Services at https://github.com/techservicesillinois/aws-enterprise-vpc/ includes implementations for all three options.

Option 1: use AmazonProvidedDNS

This is the default, and the preferred option if clients within your VPC do not need to query any University-restricted DNS zones.

Option 2: use Core Services Resolvers directly

Each Core Services VPC (see Amazon Web Services, VPC Guide for Illinois) maintained by Technology Services includes a pair of Core Services Resolvers located in different Availability Zones, with well-known private IPv4 addresses. These recursive DNS resolvers are capable of answering queries for University-restricted DNS zones and for any public DNS zone.

Core Services VPC	Core Services Resolvers
aws-coresvc1-vpc	10.224.1.50, 10.224.1.100

(note: as of this writing there is only one production Core Services VPC, but there may someday be more than one)

To use them, first make sure that your Enterprise VPC has a VPC peering connection to a Core Services VPC. Next, create a custom DHCP Options Set with domain-name-servers set to the well-known private IPv4 addresses of both Core Services Resolvers within that particular Core Services VPC.  Finally, associate the new DHCP Options Set with your VPC.

The disadvantage of Option 2 is that the built-in AmazonProvidedDNS also offers its own special behavior (especially with enableDnsHostnames = true, explained in Using DNS with Your VPC) which is specific to your VPC and thus cannot be replicated by the Core Services Resolvers. Examples we are aware of include:

• forward and reverse resolution of private DNS hostnames (e.g. ip-10-224-255-17.us-east-2.compute.internal. = 10.224.255.17)

  Note: while largely uninteresting in its own right, this is apparently required for services that use Hadoop, and may also be useful for other things like Apache mod_unique_id.

• internal resolution of public DNS hostnames (e.g. ec2-52-15-193-136.us-east-2.compute.amazonaws.com) to the associated private IP within your VPC instead of to the public IP seen by external clients
  
• mounting an EFS file system by DNS name
• Private Hosted Zones

Depending on your use case, it may be possible to simply work around the absence of these features (perhaps by using AWS API calls to get the information you need, or explicitly directing certain queries to AmazonProvidedDNS even though it's not the default nameserver learned from DHCP).  If not, or if that suggestion strikes you as irredeemably inconvenient, please read on.

Option 3: use Recursive DNS Forwarders within your Enterprise VPC

If clients within your VPC need to query University-restricted DNS zones and still take advantage of the special features of AmazonProvidedDNS, the solution is to deploy lightweight Recursive DNS Forwarder instances within your own Enterprise VPC, and assign a DHCP Options Set with domain-name-servers set to the private IPv4 addresses of your RDNS Forwarders.

RDNS Forwarders do not perform full recursion on their own; instead, they answer each query by forwarding it either to the Core Services Resolvers (if the query is for a University domain) or to your local AmazonProvidedDNS (if the query is for any other domain). Note that you still need a Core Services VPC peering, so that your RDNS Forwarders can communicate with the Core Services Resolvers.

Option 3 combines the best functionality of both worlds.  The trade-off is complexity; you have to manage these additional instances, and everything else in your VPC depends on them.  The example code from Technology Services includes an RDNS Forwarder module which is designed to be easy to deploy, and to run completely unattended (see documentation within the module code for details). But there's no such thing as completely bug-free software, and if an RDNS Forwarder instance in your VPC unexpectedly stops working, Technology Services will not be able to proactively repair it on your behalf or even to detect that it's broken (unlike the Core Services Resolvers which we actively monitor and maintain).

As always, please contact Technology Services at aws-support@illinois.edu if you have questions or need help.