-1

I have a platform I made for my own use with the idea of potentially opening it out to a wider audience later. It's always been on Linode and will be there initially but I can see myself migrating it to Elastic Beanstalk on AWS if it reaches even a slight demand.

I tried to future-proof users being able to use their own, registered domain instead of a subdomain I provide them (user.example.com). As a proof-of-concept for myself, I had my own user domain (me.com) registered separate from the platform domain (example.com) and was able to make this work perfectly by creating an A Record on the registrar for me.com that pointed to my Linode IP address and created a virtualhost entry that caught all domains pointed its way and verified it was a registered one for a user.

So, all working.

I became aware not to long into the project that this isn't an ideal practise. Redundancy wasn't a major concern as, if my single IP went down, the service was down anyway. Having 5 other name servers to fall back on wouldn't help in this scenario. My major limitation was the liklihood of the IP address changing. I even envisage the change to AWS in the future, as mentioned above.

My question is, is the changeover from pointing user's self-registered domains to a method that allows for me to change IP address really going to be as either as financially hard hitting as it appears?

I won't make a lot of money from this platform as users will not be paying a lot to use it (it offers a fresh, local spin on slightly similar services but those services are heavily bankrolled and priced at a low cost) so I am already cutting it tight with hosting costs. I also don't want to take on further responsibilities, such as being a domain registrar and am not savvy enough to confidently run my own name server.

The typical answer to this would be to use an independent name server and register an A record for each domain. My situation is a little more niche where the platform is more built on representation for a profession. So I may have lots of users with custom domains, little traffic and paying little.

Most DNS services seem to offer limited A Records or small DNS query amounts. I have the potential to see a short spike in queries and an unexpected bill for a single month could be financially disastrous. I believe I have this mostly catered for on the hosting side but would now have to worry about it on the name server side too. I can't oversell resources to the degree that a typical platform could as I would have users in the tens or hundreds rather than the thousands.

Although it's certainly not recommended, unless I want to pay through the teeth, is my best option still to go back to using an A Record for my IP Address and request that users update it when/if I change server? I would love it if a company offered a vanity IP address that I could direct to a second one (my server) and change later but I guess nameservers fill that niche for most uses.

biscuitstack
  • 153
  • 1
  • 7

1 Answers1

5

Instead of creating A records on the external domains, create CNAME ones, so for example

yourapp.me.com IN CNAME platform.example.com
yourapp.someotherdomain.com IN CNAME platform.example.com

Then in the example.com create multiple A records with several IP addresses of the servers, and the same name (for now you have just one)

platform.example.com IN A 1.2.3.4
platform.example.com IN A 1.2.3.5
platform.example.com IN A 1.2.3.6

This way you can have multiple backend servers and when the need comes - change their IP addresses and it will cascade all down to the client domains.

For it to work best I would suggest not to use TTL on DNS records above 2 hours, preferably 1 hour or less if frequent DNS queries are not a problem, and lower that down to 15 minutes - 24 hours before migrating IP addresses of the servers.

And the best part here is : its free, this method doesn't cost you a buck.

Putting CNAME records on the root domains however will most likely break all other records on the domain, which Esa Joniken has remainded me of. It would be best to limit the configuration to subdoimains in that case.

bocian85
  • 822
  • 5
  • 10
  • 3
    This works well for subdomains e.g. `www.example.com` but is not recommended for `example.com` as `CNAME` replaces all other type records, including `MX`, `NS`, `TXT`... – Esa Jokinen Sep 20 '17 at 09:53
  • @bocian85 , I assume this requires an independent name server (when you say it costs nothing) and is not applicable to Linode's own DNS manager? In which case I still have the hurdle of DNS query spikes to contend with but this certainly increases options, thanks. – biscuitstack Sep 20 '17 at 10:01
  • @EsaJokinen My virtualhost entries for the `example.com` server currently look for `example.com` `*.example.com` or `*` and perform `rewrite_cond` appropriately. Are you suggesting this will cause issues for my current setup or just to avoid creating a `CNAME` to `example.com` and ensure a CNAME is always to `subdomain.example.com` for it to work? – biscuitstack Sep 20 '17 at 10:04
  • @EsaJokinen you are correct, I have edited my answer to reflect this, thank you for remainding me. biscuitstack if you have control over DNS zone of your domain and can edit all records yourself then you can do it on the Linode (I'm not linode user so I cannot confirm) – bocian85 Sep 20 '17 at 10:05
  • 1
    biscuitstack 'issues for my current setup or just to avoid creating a CNAME to example.com and ensure a CNAME is always to subdomain.example.com for it to work?' Yes it's exactly about avoiding CNAMEs on root domain in your case `example.com`, virtualhost wildcards are totally OK – bocian85 Sep 20 '17 at 10:07
  • @bocian85 Many thanks, I think I'm on top of this now. Except for now wondering what's to stop someone maliciously creating a `CNAME` to mine or someone else's root domain to disrupt services and how to address this? Perhaps better suited to its own question. – biscuitstack Sep 20 '17 at 10:15
  • 1
    he can only disrupt the domain that has a CNAME, so only his own domain in that case. Its because `CNAME` on the root domain renders all other records of that domain to be ineffective, so when he puts a `CNAME` on `evilguy.com IN CNAME portal.example.com` emails on accounts on his domain will be trying to reach your servers instead of his `MX` ones. Same goes for all other records. That will cause more traffic on your application but will actually bring more harm to the domain owner than you. Unless it will be used as a DoS attack, but that need much more than that. – bocian85 Sep 20 '17 at 10:16
  • @bocian85 This answers my question (and I've marked it so) but I'm finally appreciating that a `CNAME` means a user cannot market `user.com`, only `subdomain.user.com`, which may be a little redundant as online representation goes. I thought they only restricted the user pointing to `subdomain.example.com` from `user.com`. I didn't state so in my question so I may need to ask it again with this criteria. My research suggests `A records` are likely still the solution. A pity, and more research due. – biscuitstack Sep 20 '17 at 10:42