1

I am building a small service where users will be assigned a subdomain such as:

myusername.myservice.com
anotheruser.myservice.com

I know that I can set up a wildcard vhost and using some configuration regex, serve the files like so:

myusername.myservice.com        ===> /var/www/myusername
anotherusername.myservice.com   ===> /var/www/anotherusername

The problem is that I would like to allow users to alias their own domain names to their service.

I understand that for the webserver, once the user adds the domain via my web interface, I can easily create a vhost for the domain in nginx and then refresh the webserver.

The problem is that I would prefer to NOT let the users add an A record of my webserver's IP address as I would prefer to keep things flexible (when we upgrade our infrastructure to something more complex to scale).

What is the best way to achieve this?

F21
  • 696
  • 3
  • 10
  • 20
  • 1
    A simple CNAME from their domain to yours would work perfectly fine, the problem arises when you start using SSL, you don't indicate if that's a requirement or not. If you're users are logging in it probably should be :) – Brent Pabst Dec 10 '12 at 01:49

1 Answers1

1

As I mention in the comment above if you are not using SSL this is pretty simple, just have your clients setup CNAME records against your domain and it's A record. So you end up with this:

WWW.MYDOMAIN.COM | CNAME --> YOURDOMAIN.COM | A --> 123.123.123.123

If you are running SSL there are a couple of different ways to work with this. You can't use the solution above as it will cause certificate errors on most browsers. Instead I usually end up with the same solution above, however instead of serving your content directly from that IP and domain name it instead serves a redirect page/script that forces the user to a SSL URL automatically.

The end result, the user can use their own custom domain name but the URL that is eventually returned is your domain after redirecting the user.

Like I said, there are loads of other ways to do this, but this is what I prefer.

Brent Pabst
  • 6,059
  • 2
  • 23
  • 36
  • This is what heroku, amazon ELB, etc., do. It works well. – Michael Hampton Dec 10 '12 at 01:53
  • @MichaelHampton Agreed, it totally depends on the environment and what you have at your disposal as well. SSL termination does get a bit tricky if you can't afford the mega mega certs. – Brent Pabst Dec 10 '12 at 01:55
  • Thanks for your answer. I would prefer to not have clients set the A record to my IP address to maintain flexibility. In such a case, how do I deal with naked domains (mydomain.com should point to username.myservice.com)? – F21 Dec 10 '12 at 03:51
  • The suggestion above does not have clients specifying an A record against your IP. It uses a CNAME instead. You might want to re-read the answer as so far it seems to cover everything you are looking for. – Brent Pabst Dec 10 '12 at 12:37
  • From my understanding, do you mean to have a CNAME on the root domain? This seem to cause other problems, because CNAMEs on a root domain cannot exist with other records, which means records for things like `mx`, `txt`, etc can break. – F21 Dec 18 '12 at 05:38
  • @F21 Yes, a CNAME as a RR can in fact cause issues as RFC states no other records should exist if a CNAME is in place. I updated the answer above to be a little more clear. Essentially the customer would need to setup a sub-domain record such as WWW.* and use that for the CNAME entry. [It's pretty common these days](http://help.squarespace.com/customer/portal/articles/413088-mapping-a-domain-general-instructions-?t=103959?t=103959) – Brent Pabst Dec 18 '12 at 13:32