4 ms·

Ask HN: Mass redirect of naked domains (from non-www to www)

3 points by oriettaxx 2y ago

Is it only us? We have tons of domains pointing to our saas, and naked domains are a real pain. Our saas is in aws, with load balancer with dns that changes in relation to the availability zone, so it works perfectly for CNAMEs, but not for RECORDs A (IP) Is there a service out there that massivly redirect naked domains to their www version? and handle TLS certificates, too? We have no problem with domains with NS in aws or cloudflare, of course, due to their ability to set naked domain to a DNS, but many of our customers do not have their NS there. Or, is there some proxy that automatically handle it (and automatically creates and renew TLS certificates): we know haproxy, but certificates needs a restart of it: Traefik could work, too, but free version has limitations on certificates storage. The request is for a (reliable/redundant/ HA) service that provide an IP to which our customer will set their naked domain (record A), then any web http or https call to that domain will redirect it to the www version of that domain

dangus 2y ago
I’m confused at why this is a difficult problem to solve, basically any load balancer/reverse proxy can handle this easily. Nginx example: https://stackoverflow.com/a/11733363 https://stackoverflow.com/a/11733363 I might be misunderstanding you, something about the way you wrote your question is really hard to follow. In AWS you could front with a load balancer with ACM certificates and then send that traffic to an nginx proxy fleet where you can do whatever you need to do. You could even put AWS global accelerator in front of those AWS load balancers if you want to be able to give your customers just a couple of IP addresses globally.
- oriettaxx 2y ago
  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.
p_ing 2y ago
You're going to run into two issues: 1. Major services use CNAMEs or otherwise 'special' DNS records for the APEX record. But sometimes they offer the ability to just add IPs to an A record, like Cloudflare does. 2. You may need to add a domain verification and/or SSL verification TXT records which means more interactions with your clients. Azure Front door even requires renewal of the APEX TXT record for SSL cert renewal (but not subdomains). Looks like ACM does the same (https://docs.aws.amazon.com/acm/latest/userguide/renew-publicly-trusted.html https://docs.aws.amazon.com/acm/latest/userguide/renew-publi...), but I haven't used it. At least for Azure and AWS, I think you're going to run into some frustrations over time if you don't control the DNS zone. Based on the docs, Cloudflare Universal SSL may be different, if you can pair it with one of their gateway products. Or you can wait for RFC 9460.

3 points by oriettaxx 2y ago

dangus 2y ago

I’m confused at why this is a difficult problem to solve, basically any load balancer/reverse proxy can handle this easily. Nginx example: https://stackoverflow.com/a/11733363 https://stackoverflow.com/a/11733363 I might be misunderstanding you, something about the way you wrote your question is really hard to follow. In AWS you could front with a load balancer with ACM certificates and then send that traffic to an nginx proxy fleet where you can do whatever you need to do. You could even put AWS global accelerator in front of those AWS load balancers if you want to be able to give your customers just a couple of IP addresses globally.

oriettaxx 2y ago
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.

p_ing 2y ago

You're going to run into two issues: 1. Major services use CNAMEs or otherwise 'special' DNS records for the APEX record. But sometimes they offer the ability to just add IPs to an A record, like Cloudflare does. 2. You may need to add a domain verification and/or SSL verification TXT records which means more interactions with your clients. Azure Front door even requires renewal of the APEX TXT record for SSL cert renewal (but not subdomains). Looks like ACM does the same (https://docs.aws.amazon.com/acm/latest/userguide/renew-publicly-trusted.html https://docs.aws.amazon.com/acm/latest/userguide/renew-publi...), but I haven't used it. At least for Azure and AWS, I think you're going to run into some frustrations over time if you don't control the DNS zone. Based on the docs, Cloudflare Universal SSL may be different, if you can pair it with one of their gateway products. Or you can wait for RFC 9460.