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 a stand-alone CNAME record pointing to an existing Amazon public DNS name.

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 create 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 service is implemented within AWS
  • what you want its friendly DNS name to be

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:

  • 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 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

    note: in this situation, one suggested approach is to move unnecessary fourth-level (or greater) records out of mysubdomain.illinois.edu and convert 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 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:

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

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. mysubdomain.illinois.edu) for which you are already responsible in Contacts Database.

  2. Create a Public Hosted Zone in Route 53 for a subdomain of that subdomain, e.g. r53.mysubdomain.illinois.edu.

    Note that this name is intentionally generic and not tied to a particular service. Using this pattern, a single delegated subdomain can hold DNS records for an arbitrary number of different services in the same AWS account.

  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 it's not registered as a separate DNS zone)

    mysubdomain.illinois.edu. IN CNAME mysubdomain-apex.r53.mysubdomain.illinois.edu.

    Note that e.g. foo.r53.mysubdomain.illinois.edu 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.

Solution 4: 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 Solution 2 is not suitable, then the remaining alternative is to serve the entire domain from Amazon Route 53.

For new non-.edu domains:

  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. 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 non-.edu domains: do not fill out the Domain Request Form. Instead, complete the first two steps above and then contact hostmgr@illinois.edu 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 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.

See Also:




Keywords:AWS, Amazon, Cloud, DNS   Doc ID:71121
Owner:David Z.Group:University of Illinois Technology Services
Created:2017-02-27 17:14 CDTUpdated:2017-09-11 15:13 CDT
Sites:University of Illinois Technology Services
Feedback:  1   0