-1

I am creating a landing page creation and hosting service. My clients will be able to link their domain to their account. I am using AWS and Route 53.

I'm considering two potential systems:

  1. Having my clients change their name servers to resolve to a hosted zone I create for them

or

  1. Having my clients create a CNAME record that points to a unique subdomain of mine that is linked to their account.

What are the advantages and disadvantages of each method? Is their a clear better solution?

Alex
  • 1
  • 1
  • 2
    #2 won't work for apex domains (i.e. `example.com`) because you can't use a `CNAME` for those. – ceejayoz Oct 23 '15 at 17:40
  • @ceejayoz So this would require two steps then. Creating the CNAME for www and then forwarding the apex to www. I guess this is a disadvantage of #2 but something I just thought of is Route 53 charges 50 cents/mo per hosted zone, so that will start to add up whereas #2 wouldn't require a new hosted zone per domain. – Alex Oct 23 '15 at 17:45
  • 3
    If $0.50/month is eating significantly into your hosting profits it's probably time to start charging a bit more for hosting. – ceejayoz Oct 23 '15 at 17:52
  • How do you propose to go about forwarding the apex? – Jenny D Oct 23 '15 at 18:14
  • @Jenny D, this would be dependent on the domain registrar. For example, here's how you do it for godaddy: http://stackoverflow.com/a/11822580/1655322. – Alex Oct 23 '15 at 18:16

2 Answers2

1

Traditionally you wouldn't want to change the name server unless the service you are charging for includes full DNS management. Any change your client wants - setting up a google / office 365 business account etc all - would need to be made on your end. Since you needed to ask this question I doubt that is your intent.

That leaves the two options of your client entering an A or CNAME record. CNAME records don't work reliably for root domains like example.com. As such the best solution in this case is simplest - your client creates an A record to an IP address that you have provisioned for them.

EDIT:

Based on the further comment about ELB what you will need to do is something like this for your client. The second line is only needed if you want the root domain forwarding to work. 

CNAME: www.example.com -> my-aws-01-elb.aws.amazon.com
CNAME: example.com -> www.example.com
Tim Brigham
  • 15,545
  • 10
  • 75
  • 115
  • You are correct. I am not looking to offer a full DNS solution, just landing page hosting. Regarding an A record, I should have noted that I'm using an elastic load balancer, so this is not an option. – Alex Oct 23 '15 at 17:48
  • I thought you couldn't create a CNAME record for the apex domain? – Alex Oct 23 '15 at 18:16
  • @Alex not for the root domain, e.g example.com -> my-aws-01-elb.aws.amazon.com – Tim Brigham Oct 23 '15 at 18:18
  • So then in your example, how is the second CNAME valid? – Alex Oct 23 '15 at 18:21
1

My strategy is as follows. In addition to considering what works and what doesn't, my practice is based on minimal future client interaction. You do not want to have to contact hundreds or even dozens of clients to have them coordinate some kind of change.

When not at the apex of a zone, I have a domain name I use specifically for this purpose. Let's assume my domain name that I used for these purposes is network.example.org.

I have the client create a CNAME. If the hostname for the new site is client.example.com then I have the client create a CNAME pointing to client.example.com.network.example.org. Then, in Route 53, I create the client.example.com.network.example.org hostname as an A-record alias to my ELB endpoint, or to CloudFront, or just an A-record to an elastic IP. (Or, I could make it another CNAME if I had some reason to. They do cascade.)

The significance of this configuration, again, is that I never have to ask the client to reconfigure anything. No matter how my network might change -- I need to move them to a different ELB, migrate them to a different region, etc., I can make the change in Route 53.

For zone apex, this is off the table, since CNAMEs are out of the question, but usually when a client wants to point a zone apex at my systems, the client isn't using that domain for anything else, anyway. If they were, they would probably not have pointed the apex at me... so I create the hosted zone in Route 53 and give them the 4 assigned name servers. In the event the client needs additional records, I add them in as a courtesy. (You can also create a Reusable Delegation Set in Route 53 using the API or CLI, for white-label DNS servers, giving the client ns1...ns4.example.org, instead of the "awsdns" hostnames, but this is probably not ideal if you're planning to do any geo/latency-based routing.)

When I explain to clients that my DNS is integrated with the rest of my platform, and allowing me to host their DNS provides me with the ability to automatically mitigate against outages and DDoS attacks by dynamically updating their DNS records, this is almost always an easy sell. I host the DNS and throw in MX records, of whatever they might need, which is rarely anything.

In one exceptional situation where the client was adamant about not only retaining control of the DNS, the site was at the apex, but also where the web site in question was to be accessible to their employees behind a firewall -- so they wanted the site to have a fixed IP address anyway -- I solved this dilemma with an EC2 instance with an Elastic IP address, which is a t2.micro running HAProxy and forwards the traffic to my back-end systems. HAProxy is so insanely well-written that this $10 machine served 896,392 http requests in the prior 24 hours and never exceeded 6% CPU utilization. (And it was also dynamically compressing text, css, and js on the fly, at that.) The customer created an A record pointing to the Elastic IP, which I can still re-map within the region if the circumstances require.

Of course, at the zone apex, if the client was using a DNS provider that supported some kind of "A-Name" record (like CloudFlare's "CNAME flattening") then I would revert to the "not at the apex" configuration and give them a destination in my domain named with their domain as a prefix, so I would retain the ability to modify the configuration without their intervention... but this has never come up.

Michael - sqlbot
  • 22,658
  • 2
  • 63
  • 86
  • Hi Michael, thanks for your reply. I like your theme of minimal future client interaction. That is critical in my situation. My project is serving single page, static landing pages. The first record in Apache is the catch all that routes all domains not matched to a php router that looks up the request url in a redis cache and returns the html or 404 if not found. – Alex Oct 23 '15 at 22:16
  • ...I give my clients free sub domains such as your name.mysite.com. This setup also allows the use of any other domain as long as it's eventually aimed at my server/load balancer. I'm thinking then, for my use case, a CNAME is the best option because 1. It doesn't require creating a hosted zone. 2. I'm able to control all DNS changes without intervention from my client. The only real issue is if they want the apex, which they could mitigate by forwarding it to www. – Alex Oct 23 '15 at 22:16
  • *"This setup also allows the use of any other domain as long as it's eventually aimed at my server/load balancer."* As long as your platform allows mapping one domain to another. Remember that the only thing your server sees is the `Host:` header sent by the browser. CNAMEs are only used for ultimately resolving an IP. They are invisible at layer 7. – Michael - sqlbot Oct 23 '15 at 23:27
  • I neglected one point... you can create a single `*.network.example.org` resource record in Route 53 and it will respond to requests for `any.number.of.prepended.levels.of.hostnames.network.example.org` with the same response. Any matching hostname that you want to override and do something other than this "default" behavior will work as expected if you declare it separately. – Michael - sqlbot Oct 24 '15 at 03:12