0

Let's assume I have a multi-tenant webserver that runs an application for 500+ domains. I have an AWS Loadbalancer url, my_application.elb.eu-west-1.amazonaws.com, which have A and AAAA records to the actual LB. Now I want to ensure that all the domains I have point to this LB. Then I would see three options:

  1. Read the A and AAAA records from my LB, and copy them for each domain.
  2. Make a CNAME record for each domain, to the LB url (suggested solution by AWS)
  3. Register one custom domain, e.g. applicationdns.com, and create a CNAME record to the LB url for e.g. www.applicationdns.com. Then for each domain create a CNAME record to this record (www.applicationdns.com).

Of course, option 1 is horribly inefficient so discarded right away.

Option 2 is the suggested approach, which works fine. However, if at any point I would need to migrate the Loadbalancer to a different URL, I would need to fix 500+ DNS records, possibly distributed over multiple providers, so it is hard to automate.

Option 3 would solve this problem, however it introduces a "chained CNAME". From what I've seen (RFC 1034) this is technically valid, but not considered good practice.

What is the best way to approach this challenge? Is there another approach that might work?

Dave
  • 1

2 Answers2

0

When you are able to register the custom domain to point to the Loadbalancers in AWS Route53, you can actually make alias A (and AAAA) records that function similar to CNAME records. This prevents chaining CNAME records, but still allows you to migrate the Loadbalancer url if necessary.

This is also explained in the AWS documentation, you can just repeat the described procedure for AAAA records if you want to support Ipv6.

Dave
  • 1
0

From an automation point of view, option 1 & 2 automate the same. Scaling in managed configuration can be done quite swiftly with the help of templates + variables.

I would personally favour 1 over 2, since CNAME incur an extra step on domain resolution while adding no real benefit to the ease of configuration, provided (again) you use managed configurations and you do not update them manually.

All in all, the keystone would be how you manage your hundreds of domains' configuration. Since you are using external providers, the quality of their API seems to be the landmark to look out for. If you go for self-hosted/managed authoritative name servers, even old technology allows for dynamic reload of individual zones, so there is really nothing standing in the way of automated (rolled out?) deployment.

Bernard Rosset
  • 1,398