Ask HN: Mass redirect of naked domains (from non-www to www) | Hacker News Reader

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

3 pointsoriettaxx11 comments

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

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-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.

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

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.

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

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

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)

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.

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.

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.

ah... I've asked perplexity, and they suggest https://apexwise.io/#pricing and what I've tried to explain is perfectly described here 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....)

More here, but still with the same limitations as apexwise.io

* https://redirect.pizza/use-cases/apex-to-www

The general issue can be called: "apex to www" (I'll update the title of this post)

https://stackoverflow.com/questions/16533341/https-redirect-...

Omg... I've found it, and it's even free https://www.apextowww.com/#get-started completely automatic!!

I'll contact them: I guess we can't just move 500+ domains there without asking permission :)

and maybe it is just Caddy itself? https://news.ycombinator.com/reply?id=43073019&goto=item%3Fi...

Reply on news.ycombinator.com