5

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

  1. Have two A records one with www and one without. Apparently this can cause SEO issues because google will take it as duplicate content.

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

  3. Use a PTR record to redirect - But apparently this is not advisable. How do I redirect www to non-www in Route53?

  4. Since my name is with godaddy, use godaddy to redirect: https://support.google.com/blogger/answer/58317?hl=en

  5. Use a free service like wwwizer http://wwwizer.com/naked-domain-redirect

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

Community
  • 1
Jimmy
  • 239
  • 3
  • 7
  • 21
  • "Have two A records one with www and one without. Apparently this can cause SEO issues because google will take it as duplicate content." Google has understood this common configuration for years now. That's ancient SEO advice. If you're really concerned about it, you can always put a canonical meta tag in place to be explicit about it. – ceejayoz Sep 23 '13 at 15:32
  • Oh really? I haven't been able to find this in writing anywhere, are you able to post some validation? – Jimmy Sep 23 '13 at 15:33
  • I'm not keen on this approach really: http://webmasters.stackexchange.com/questions/11584/what-is-the-best-way-to-redirect-my-naked-domain – Jimmy Sep 23 '13 at 15:52
  • Canonical links: https://support.google.com/webmasters/answer/139394?hl=en | Setting preferred www vs. non-www in Google Webmaster Tools: https://support.google.com/webmasters/answer/44231?hl=en – ceejayoz Sep 23 '13 at 16:05
  • 2
    _Apparently this can cause SEO issues because google will take it as duplicate content._ Bogus statement from yore, Google has a setting in Webmaster tools so you can tell Google which has authority, the bare domain or the www. subdomain. Set it and your duplicate fears go away as Google now knows what URL you expect to be returned in SERP. – Fiasco Labs Sep 23 '13 at 16:46
  • Whilst I appreciate the information, I can't find this written, I really need some sort of written proof that this is the case – Jimmy Sep 24 '13 at 12:00
  • 1
    Well, go get yourself a Google Webmaster Tools account and read it in flaming 30 foot tall letters under site settings **If you specify your preferred domain as http://www.example.com and we find a link to http://example.com, we'll consider both links the same.** As opposed to quoting 6 year old _cargo cult SEO_ rules of thumb. – Fiasco Labs Sep 27 '13 at 06:29
  • Thats fine for google but what about bing etc.... – Jimmy Sep 27 '13 at 14:33

1 Answers1

1

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.

Michael - sqlbot
  • 21,988
  • 1
  • 57
  • 81