Overview

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:

• how your particular service is implemented within AWS
• where the desired friendly DNS name of your service resides in the overall hierarchy of DNS domains

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:

• If your service has a single internet-facing Elastic Load Balancer (any type), then that Elastic Load Balancer has a public DNS name such as xyz-9999999999.us-east-2.elb.amazonaws.com
• If your service is an Elastic Beanstalk Environment, it has a public DNS name such as foo-environment.xyz9999999.us-east-2.elasticbeanstalk.com
• If your service is a CloudFront distribution, it has a public DNS name such as d111111abcdef8.cloudfront.net
• If your service has a single Elastic IP Address (not an auto-assigned public IP which may change over time) such as 52.15.m.n, then that Elastic IP has a public DNS name such as ec2-52-15-m-n.us-east-2.compute.amazonaws.com

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:

foo.mysubdomain.illinois.edu. IN CNAME xyz-9999999999.us-east-2.elb.amazonaws.com.

This solution works if the desired friendly name is:

• foo.mysubdomain.illinois.edu (a fourth-level or greater name within an illinois.edu subdomain)
• mysubdomain.illinois.edu (a third-level illinois.edu subdomain) if registered as a CNAME record in the illinois.edu zone (see DNS Standards)
• foo.example.com (a third-level or greater name within a non-.edu domain)

This solution cannot be used for:

• mysubdomain.illinois.edu (a third-level illinois.edu subdomain) if registered as a separate DNS zone (see DNS Standards)
  
  note: consider moving unnecessary fourth-level (or greater) records out of mysubdomain.illinois.edu and converting it to a CNAME record.  Contact hostmgr@illinois.edu for help with this.
  
  
• example.com (the apex of a second-level non-.edu domain)

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.k, you can use IPAM to create stand-alone A records (with optional DNS Traffic Control) pointing to these IPs:

mysubdomain.illinois.edu. IN A 52.15.m.n
mysubdomain.illinois.edu. IN A 13.58.j.k
example.com. IN A 52.15.m.n
example.com. IN A 13.58.j.k

This solution offers two narrow advantages over Solution 1:

• It can be used at the apex of a zone.
• If necessary, AWS allows you to customize the reverse DNS record for an Elastic IP to match a corresponding A record.  Note that customizing reverse DNS is not necessary for most use cases.

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

You can also use it with the static IPs provided by Global Accelerator (e.g. with an Application Load Balancer endpoint).

Solution 3: Illinois virtual Alias record (non-.edu) to Amazon FQDN

If the desired friendly name is e.g. example.com (the apex of a second-level non-.edu domain), and your service has a stable Amazon public DNS name but not a stable set of IP addresses, consider requesting a virtual Alias record.

Please note that virtual Alias records are not currently offered for .edu subdomains, and have several other important limitations; see the above link for details.

Solution 4: 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 use 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.

Please note that most service architectures do not require Route 53.

Should 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. mysubdomain.illinois.edu) 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. r53.mysubdomain.illinois.edu.

3. Select the automatically-created resource record set of type NS to display its value, which should look similar (but not identical) to:

   ns-1532.awsdns-63.org.
   ns-479.awsdns-59.com.
   ns-843.awsdns-41.net.
   ns-1759.awsdns-27.co.uk.

4. Contact hostmgr@illinois.edu to request a delegation of r53.mysubdomain.illinois.edu 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. foo.r53.mysubdomain.illinois.edu.

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

   foo.mysubdomain.illinois.edu. IN CNAME foo.r53.mysubdomain.illinois.edu.
   myothersubdomain.illinois.edu. IN CNAME bar.r53.mysubdomain.illinois.edu.

   and even (provided your subdomain is not registered as a separate DNS zone)

   mysubdomain.illinois.edu. IN CNAME baz.r53.mysubdomain.illinois.edu.

   Note that e.g. foo.r53.mysubdomain.illinois.edu 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 to Route 53 (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 the friendly names of those services are not tightly coupled to this account.  By updating its CNAME record, any given service can be easily migrated to a new implementation in the same AWS account, a different AWS account, or even a different cloud platform altogether, without impacting other services.

Solution 5: Non-.edu Domain served by Route 53

If the desired friendly name is e.g. example.com (the apex of a second-level non-.edu domain), and Solutions 2 and 3 are 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 non-.edu domain, e.g. example.com.

2. Select the automatically-created resource record set of type NS to display its value, which should look similar (but not identical) to:

   ns-1532.awsdns-63.org.
   ns-479.awsdns-59.com.
   ns-843.awsdns-41.net.
   ns-1759.awsdns-27.co.uk.

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 hostmgr@illinois.edu 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 non-.edu 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.