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 you have chosen to implement your service within AWS and 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, 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 after a restart) 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 pointing 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 set of CNAME records 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 zone

    note: in this situation, one suggested approach is to move unnecessary records out of mysubdomain.illinois.edu and convert it to a set of CNAME records.  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 after a restart) such as 52.15.m.n, and the desired friendly name resides at a zone apex, you can use IPAM to create stand-alone A records pointing to these IPs:

mysubdomain.illinois.edu. IN A 52.15.m.n
example.com IN A 52.15.m.n

The only advantage of this approach over Solution 1 is that it can be used at a zone apex.

Solution 3: Illinois Subdomain Delegation to Route 53

Amazon Route 53 offers a number of advanced features to help route traffic to AWS resources; for example, a single domain name managed in Route 53 can be load-balanced between multiple Elastic Load Balancers in different regions (using existing health-check knowledge).

The recommended way to take advantage of Route 53 features for services hosted in your AWS account 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.
  3. Select the automatically-created resource record set of type NS and copy 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 provide the NS record set from the previous step.

  5. Use Route 53 to configure resource record sets for your services as desired, e.g.
    foo.r53.mysubdomain.illinois.edu
    bar.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.

    Note that 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.

Using this pattern, a single delegated subdomain can hold DNS records for an arbitrary number of services hosted in the same AWS account.

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 and copy 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 provide 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 the registrar NS records will be updated to point to the appropriate Amazon Route 53 DNS servers rather than the University of Illinois DNS servers.




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-02-28 15:00 CDT
Sites:University of Illinois Technology Services
Feedback:  0   0