2 ms·

sorry for not being clear We have many domains pointing at our saas with AWS load balancer. Domains are not registered handled by aws (route53) or Cloudflare,

sorry for not being clear We have many domains pointing at our saas with AWS load balancer. Domains are not registered handled by aws (route53) or Cloudflare, so we have to tell our customers how to set them up. Typically we have: * the www version of the domain set as a CNAME to our aws load balancer dns (which changes, depending of the availability zones... no we do not want to use cross region traffic). * the non-www version (naked domain, aka apex) cannot be a CNAME, it has to be set to one or more IP (record A), and here we have the issue. The issue is that when we change availability zone, that record A change I am sure we are not the only one facing this issue. As for the certificates, we cannot ask customers (more then 500) to set TXT records for us, we just use letsencrypt, with the ordinary acme

oriettaxx 2y ago
I remember we had a look at the AWS global accelerator (2 years ago, about), and it was expensive, isn't?
- oriettaxx 2y ago
  for us, the best would be somebody offering this service: Set your apex/naked domain to our IP (eg. 1.2.3.4), then we redirect any call to it to its www version (even with https, so we'll provide the TLS certificate). Maybe our ISO (security certification...bla bla) may not allow us to delegate this service to third parties we do not control (and I can understand), so the best would be and open source tool (or a smart setup of Traefik or Haproxy, or nginx?) to do it: but it would really need work without adding/removing domains in it (so changing its configuration every time a domain is added)
- dangus 2y ago
  OP’s reply comment to me clarified that it’s not really the right solution anyway. If you don’t transfer a ton of data it’s not horribly expensive, but it’s really meant to solve a different problem. It can be really nice if you want to enhance performance and also have automatic regional failover. But I think it might make the most sense for the sort of companies that have a small quantity of high paying customers that aren’t transferring a lot of data like a large quantity of small customers would.
dangus 2y ago
Okay, thanks, this makes more sense in my head now. I thought you managed the domains yourself and that’s clearly not the case. I can think of a few ideas…maybe they not perfect but here they are. A couple of them involve setting expectations for your customers and I think that may or may not be reasonable. 1. Tell your customers that apex domain redirection isn’t going to be supported moving forward. This might not be an option for you, but if you can stomach it I think if customers were told to use a subdomain maybe your customers’ customers wouldn’t accidentally add www and necessitate the redirect. For example, “app.example.com” is less likely to pick up stray stray www entries. Your customer can then be responsible directing their customers to the correct place. 2. Similar to #1, you could say that you only support apex domains for DNS providers that support ALIAS/ANAME records at the apex. So if customers complain about #1 you could tell them to suck eggs and change their DNS provider. They can’t say they don’t have a workable option. 3. Run proxy server(s) with a static IP your customers will point their records to, which terminates SSL and runs certbot before forwarding traffic on to your ALB. I think in that case you’d just want to automate the configuration changes for when you modify the customer domain configuration, as well as having job/timer for renewal.
- oriettaxx 2y ago
  thank @dagus. My boss was for option #1, eventually for #2 (especially since we are wasting a huge amount of valuable time to tech customers how to set, change, correct DNS, which is not paid), but then it came out that part of the requirements for our customers (it's public administrations) is to correctly handle the apex domain, so we cannot skip it. So we are left with 3. As to how: we know haproxy a bit, and we see it could work but we have to automate it, as you said. We love Traefik, and the way it creates automatically a letsencrypt TLS certificates at the first https call (so, "on the fly") , but as far as we understood we need to manually add new domain to its configuration: once again we need to "automate" it. We were wondering if some service out there is already providing it, since I think is really a general issue many should face.
  - oriettaxx 2y ago
    ah... I've asked perplexity, and they suggest https://apexwise.io/#pricing https://apexwise.io/#pricing and what I've tried to explain is perfectly described here https://apexwise.io/#why https://apexwise.io/#why It could be a solution, but I see we have to add domains (with API), while our need is just to "fire and forget": we want to tell our customers: * set your apex domain as RECORD A with these two IPs: .... then if they do it well, if they don't we just do not want to care: if one day they remove those IPs, or add a new one on their own (something that happens way too often) it's their problem: we do not want to have to handle it (fix certificate renew, tell them they have to react and correct....)

oriettaxx 2y ago

I remember we had a look at the AWS global accelerator (2 years ago, about), and it was expensive, isn't?

oriettaxx 2y ago
for us, the best would be somebody offering this service: Set your apex/naked domain to our IP (eg. 1.2.3.4), then we redirect any call to it to its www version (even with https, so we'll provide the TLS certificate). Maybe our ISO (security certification...bla bla) may not allow us to delegate this service to third parties we do not control (and I can understand), so the best would be and open source tool (or a smart setup of Traefik or Haproxy, or nginx?) to do it: but it would really need work without adding/removing domains in it (so changing its configuration every time a domain is added)
dangus 2y ago
OP’s reply comment to me clarified that it’s not really the right solution anyway. If you don’t transfer a ton of data it’s not horribly expensive, but it’s really meant to solve a different problem. It can be really nice if you want to enhance performance and also have automatic regional failover. But I think it might make the most sense for the sort of companies that have a small quantity of high paying customers that aren’t transferring a lot of data like a large quantity of small customers would.

dangus 2y ago

Okay, thanks, this makes more sense in my head now. I thought you managed the domains yourself and that’s clearly not the case. I can think of a few ideas…maybe they not perfect but here they are. A couple of them involve setting expectations for your customers and I think that may or may not be reasonable. 1. Tell your customers that apex domain redirection isn’t going to be supported moving forward. This might not be an option for you, but if you can stomach it I think if customers were told to use a subdomain maybe your customers’ customers wouldn’t accidentally add www and necessitate the redirect. For example, “app.example.com” is less likely to pick up stray stray www entries. Your customer can then be responsible directing their customers to the correct place. 2. Similar to #1, you could say that you only support apex domains for DNS providers that support ALIAS/ANAME records at the apex. So if customers complain about #1 you could tell them to suck eggs and change their DNS provider. They can’t say they don’t have a workable option. 3. Run proxy server(s) with a static IP your customers will point their records to, which terminates SSL and runs certbot before forwarding traffic on to your ALB. I think in that case you’d just want to automate the configuration changes for when you modify the customer domain configuration, as well as having job/timer for renewal.

oriettaxx 2y ago
thank @dagus. My boss was for option #1, eventually for #2 (especially since we are wasting a huge amount of valuable time to tech customers how to set, change, correct DNS, which is not paid), but then it came out that part of the requirements for our customers (it's public administrations) is to correctly handle the apex domain, so we cannot skip it. So we are left with 3. As to how: we know haproxy a bit, and we see it could work but we have to automate it, as you said. We love Traefik, and the way it creates automatically a letsencrypt TLS certificates at the first https call (so, "on the fly") , but as far as we understood we need to manually add new domain to its configuration: once again we need to "automate" it. We were wondering if some service out there is already providing it, since I think is really a general issue many should face.
- oriettaxx 2y ago
  ah... I've asked perplexity, and they suggest https://apexwise.io/#pricing https://apexwise.io/#pricing and what I've tried to explain is perfectly described here https://apexwise.io/#why https://apexwise.io/#why It could be a solution, but I see we have to add domains (with API), while our need is just to "fire and forget": we want to tell our customers: * set your apex domain as RECORD A with these two IPs: .... then if they do it well, if they don't we just do not want to care: if one day they remove those IPs, or add a new one on their own (something that happens way too often) it's their problem: we do not want to have to handle it (fix certificate renew, tell them they have to react and correct....)