在heroku上,是否绝对没有办法将heroku上的https裸域重定向到带有www的非裸域？

Question

看看Heroku文档中的这个链接:

https://devcenter.heroku.com/articles/avoiding-naked-domains-dns-arecords#subdomain-redirection

黄色方框说:

使用子域重定向时,通过SSL(即https://mydomain.com)直接向裸域发出的请求 将收到警告.这是预期的,只需循环和公布您的安全URL的子域格式即可避免.

这真的是唯一的解决方案吗？只是希望没有wwws的人不输入网址？

我有几个问题,人们只是从网址中删除子域到达主页(在https上)并遇到ssl警告？

有没有其他人想出办法解决这个问题？

Answer 1

到目前为止我们发现的最好的想法是设置两个带有少量nginx配置的Amazon EC2微机器实例.然后,配置两个弹性IP地址以指向那些EC2实例,并将2个A记录指向这些IP地址.这样,如果硬件出现问题,您可以始终将弹性IP指向另一台EC2计算机,而无需等待DNS传播.访问https://example.com和http://example.com的用户将获得301到域并且没有SSL警告.

server {
  listen 80;
  listen 443 default_server ssl;
  server_name example.com;
  ssl_certificate server.crt;
  ssl_certificate_key server.key;
  return 301 https://www.example.com$request_uri;
}

另一个想法是使用wwwizer提供的优质服务.

Answer 2

最好的选择是使用DNSimple的ALIAS记录类型,它为CNAME记录提供根域支持.

然后,您可以像这样设置记录(假设使用SSL端点进行SSL).

| type  | name | target                  |
| ALIAS |      | tokyo-123.herokussl.com |
| CNAME | www  | tokyo-123.herokussl.com |

虽然有其他DNS提供商提供类似的ALIAS记录功能(例如DNSMadeEasy的ANAME),但它不是DNS规范中的内容.这就是我们尚未提供有关使用此类记录的详尽文档的原因.但是,我们的目标是在不久的将来纠正这一问题,因为对那些想要根域支持的人缺乏明确的指导.

请密切关注使用AWS Route 53作为您的Heroku应用程序的DNS.我相信很快就能在R53上实现这一目标,或者很快就能实现这一目标.

Answer 3

301 重定向是正确的方法，因为 RFC1033 规定您不能将区域顶点（根域）指向 CNAME 记录 - 它必须是 A 记录。

话虽如此，无论如何，有一些 DNS 服务提供了这样做的可能性。我还没有亲自尝试过，但CloudFlare提供免费套餐，并于去年开始为区域顶端提供 CNAME。