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:

Our primary concern here is 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 generally have no control over their reverse-mapping DNS (but see Solution 2 below for one exception).

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 Elastic 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.kyou can use IPAM to create stand-alone A records (with optional DNS Traffic Control) 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

This solution offers two narrow advantages over Solution 1:

Hint: you can use this solution with the Elastic IPs (one per Availability Zone) assigned to an internet-facing Network Load Balancer.

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 your subdomain is not registered as a separate DNS zone) IN CNAME

    Note that e.g. should not itself be a CNAME record (so-called "CNAME chains" are not technically an error, but create inefficient behavior and are discouraged as a bad practice). 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 of a service) 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, but any given service can be easily and independently migrated to a new implementation (in the same AWS account, a different AWS account, or even a different cloud platform altogether) by modifying its CNAME record.

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.

    For existing domains: do not fill out the Domain Request Form; instead, contact for help migrating your existing zone into Route 53.

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

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: