Problem
I am using a custom domain to host a static index.html on amazon S3. That all works fine on my domain: site.com. However, when I visit www.site.com I get an error. From what I understand I need to do a 301 redirect of the www URL to the naked URL.
There seems to be a few ways to do this, but my understanding of DNS is limited, and it sounds like many of these options are inadvisable.
Options
Have two A records one with www and one without. Apparently this can cause SEO issues because google will take it as duplicate content.
Have a single redirect bucket which all are routed through. This might cause problems with cloudfront.
https://stackoverflow.com/questions/10115799/set-up-dns-based-url-forwarding-in-amazon-route53Use a PTR record to redirect - But apparently this is not advisable.
How do I redirect www to non-www in Route53?Since my name is with godaddy, use godaddy to redirect:
https://support.google.com/blogger/answer/58317?hl=enUse a free service like wwwizer
http://wwwizer.com/naked-domain-redirectUse Amazons bucket redirect. This gives the big issue of needing two buckets for every domain, meaning I can only have 50 domains instead of 100. This is a problem for me.
http://i.stack.imgur.com/lqict.png
I have tried to list every option I know. Please can someone with a better understanding of domains and DNS help me to decide which is the optimal route to go down, considering performance, reliability and SEO.
Answer
Option 1 will not work with S3-hosted web sites because what S3 sees in the Host: header of the incoming HTTP request must match exactly the name of the bucket, and setting a duplicate A record does will not solve your problem.
Option 2 will not work for the same reason -- the request will never arrive at the bucket containing the redirect rules except for requests directed toward the actual name of the bucket. The answer you linked to is nothing more than the "hard way" of doing Option 6, and requires one bucket per hostname.
Option 3 is not useful because PTR records don't cause browser redirects. Usually used for reverse-DNS, A PTR record has no application in this context.
Option 4 Go Daddy has options called "Domain Forwarding" and "Subdomain Forwarding" but this means you have to have your DNS hosted by Go Daddy, not just have your domain registered there (those are two different things that often, but not necessarily, go together). If this is what you have now, you can "forward" the "www" subdomain (www.example.com) to the apex (example.com) which Go Daddy accomplishes by creating either A or CNAME records for www.example.com which point to their own web servers, which generate HTTP 301 or 302 redirects to http://example.com. If your DNS is hosted with Go Daddy, and not on Route 53, then this is probably the simplest option, but if your DNS is not hosted with Go Daddy, this option is not available. Since you are using the apex of your domain as a web site in S3, I'm assuming your DNS is hosted with Route 53, which means this won't work.
Option 5 seems like a bad idea, introducing an unnecessary third party into the equation, but more importantly, it solves the wrong problem. They don't redirect www.example.com to example.com, they redirect example.com to www.example.com.
Option 6 is a good choice, with the drawbacks that you mentioned, regarding the limited number of buckets available to each AWS account.
If you have that many different domains, than another option would be to allocate an Elastic IP Address in EC2 (so that you have a static endpoint IP address that won't change), then spin up a Micro instance bound to that IP address and install HAProxy on it. HAProxy is actually designed to front-end actual web servers and load balance traffic to them from the outside world, but it also has the capability of generating redirects. Configuration is not terribly complicated, and HAProxy is very efficient with CPU, so I would expect you'd get a lot of work out of a Micro but could always scale it up to a larger instance if traffic made that necessary.
You'd configure a front-end listener on port 80:
frontend main
bind *:80
And then for each domain create an access control list (acl) to watch for requests containing that hostname in the "Host" http header...
acl www.example.com hdr(host) -i www.example.com
...then configure a redirect to generate a 301 to the desired hostname.
redirect prefix http://example.com if www.example.com
In DNS, you'd configure www.example.com with an A record pointing to this Micro instance's public Elastic IP address.
With this configuration, the path is preserved, so a request that is sent to any path, sush as http://www.example.com/foo/bar will be met with an HTTP 301 redirect to the exact same path on the other domain, such as http://example.com/foo/bar.
You can do similar things with an actual web server running on a machine, such as Nginx or Apache, but HAProxy is a very heavy-duty-yet-light-weight tool that seems quite appropriate for such a task, and generating redirects like this this is one of the things that I use it for in my operations.
No comments:
Post a Comment