Amazon Web Services, Authoritative DNS Guide for Illinois

How to configure DNS domain names for services hosted in your University of Illinois Amazon Web Services (AWS) account. Where possible, the simplest and preferred solution is to create stand-alone CNAME records pointing to generic Amazon public DNS names.


This page focuses on DNS recommendations which are specific to the University of Illinois.  For general topics, please consult Amazon's documentation.

Authoritative DNS for public-facing services

This section will discuss several ways to implement a friendly DNS name (affiliated with the University of Illinois, not with Amazon) by which users can access your AWS-hosted service.  Which solution(s) are suitable will depend on:

In all cases, this section is concerned only about forward-mapping DNS (i.e. resolving the friendly name to eventually obtain one or more Amazon public IP addresses).  Since the IPs in question are owned by Amazon, we have no control over their reverse-mapping DNS.

Solution 1: Illinois CNAME record to Amazon FQDN

In many cases, your service is already identified by a single, stable fully-qualified domain name (FQDN) for which Amazon DNS returns one or more A records.  For example:

The simplest and preferred solution in such cases is to create a stand-alone CNAME record in IPAM which points to this Amazon public DNS name: IN CNAME

This solution works if the desired friendly name is:

This solution cannot be used for:

Solution 2: Illinois A record to Amazon IP

If your service has one or more Elastic IP Addresses (not auto-assigned public IPs which may change over time) such as 52.15.m.n and 13.58.j.k, you can use IPAM to create stand-alone A records pointing to these IPs: IN A 52.15.m.n IN A 13.58.j.k IN A 52.15.m.n IN A 13.58.j.k

The only advantage of this solution over Solution 1 is that it can be used at a zone apex.  In all other cases, Solution 1 is preferable.

Hint: you can assign Elastic IPs (one per Availability Zone) to a Network Load Balancer in order to use this solution. Note however that IPAM is not currently able to automatically stop returning one of the A records in the event that all of your targets in a particular Availability Zone are unhealthy.

Solution 3: Illinois Subdomain Delegation to Route 53

Amazon Route 53 offers a number of advanced features to help route traffic to AWS resources in more complex cases. For example, a single domain name managed in Route 53 can direct clients to multiple Elastic Load Balancers (e.g. in different Regions), with DNS-based failover taking advantage of existing health-check knowledge.

If you wish to utilize Route 53 for services hosted in your AWS account, the recommended approach is as follows:

  1. Choose an appropriate subdomain (e.g. for which you are already responsible in Contacts Database.

  2. Create a Public Hosted Zone in Route 53 for a generic subdomain of that subdomain, e.g.
  3. Select the automatically-created resource record set of type NS to display its value, which should look similar (but not identical) to:
  4. Contact to request a delegation of to Amazon Route 53, and copy/paste the NS record set from the previous step.

  5. Use Route 53 to configure resource record sets as desired for your services, e.g.

  6. Finally, use Solution 1 above to create friendly names for the Route 53 names, e.g. IN CNAME IN CNAME

    and even (provided it's not registered as a separate DNS zone) IN CNAME

    Note that e.g. should not itself be a CNAME record (so-called "CNAME chaining" is not technically an error, but is bad DNS practice and strongly discouraged). You can generally avoid this by using a Route 53 Alias Resource Record Set instead.

The advantage of delegating a generic subdomain (rather than the actual desired friendly name) is future flexibility.  Using this pattern, a single delegated subdomain can hold DNS records for an arbitrary number of different services hosted in the same AWS account, yet each service can be easily and independently migrated to a new implementation by modifying its CNAME record -- even if the new implementation uses a different AWS account or a different cloud platform altogether.

Solution 4: Domain served by Route 53

If the desired friendly name is e.g. (the apex of a second-level domain), and Solution 2 is not suitable, then the remaining alternative is to serve the entire domain from Amazon Route 53.

  1. Create a Public Hosted Zone in Route 53 for the desired domain, e.g.
  2. Select the automatically-created resource record set of type NS to display its value, which should look similar (but not identical) to:
  3. For new domains: use the Domain Request Form to request the desired domain through Technology Services.  Use the comments field on the last page of the form to indicate that the new domain should be served by Amazon Route 53, and copy/paste the NS record set from the previous step.

  4. Use Route 53 to configure all desired DNS records for your domain.

For existing domains: do not fill out the Domain Request Form. Instead, complete the first two steps above and then contact for help migrating the existing zone into Route 53.

Note that the University of Illinois does not use Amazon for domain registration (i.e. purchase); the domain will remain registered with our usual registrar, but we will configure the registrar NS records to point to the appropriate Amazon Route 53 DNS servers rather than the University of Illinois DNS servers.

See Also: