30 comments

[ 0.28 ms ] story [ 79.5 ms ] thread
Works with Google App Engine?
Yes. This works on the DNS level, so it doesn't matter what technology your site uses.

But as others pointed out, decent DNS registrars will let you do this in your DNS administration account. Which is much safer.

If you have Godaddy, they allow you to forward your domain to www for free. I do that with my GAE apps.
Thanks, I didn't realize that. I've been using godaddy for eons and have looked for this feature on their confusing site before. I'll look again.
I thought their last UI was bad, but their latest UI, with all the spinning and zooming boxes, is even worse.
Let me know when you find out how to do it. I have my www. subdomain pointing to Google Sites, and I'd love for the naked domain to go there too.
It is really not a good idea to let your naked record go to a 3rd party. If you need your root to be an A name, go with a DNS provider that will do URL redirects. If you trust them with DNS resolution of your domain you can trust them to not go crazy with your root record.

EDIT: If you are looking for a host that will do this, http://NameCheap.com is how I do it but I understand GoDaddy and Hover does it too. Seriously... go with a reputable registrar that has these simple features it will pay off in the end.

when I saw someone retweet about this service in my stream it was a bit confusing... can't really see the purpose myself, when you, as you mention, you can handle this within the confines of your own registrar.

I'm curious as to why the developer felt the need to make this.

I wrote this "service" and the answer to why I did it is three-fold. 1. I had used 2 services, blogger and shopify, which didn't support pointing naked domain names. 2. It took all of 10 minutes and 3. I somehow landed on an epic domain name.

The long answer is that I run a platform for high-availability sites. I don't want to manage the client's DNS and I want to have the flexibility to instantly move sites from server to server. The answer, is to setup a CNAME and have the clients point their primary CNAME (www) to a host where you control the DNS.

www.example.com CNAME to example.myhostingservice.com. example.myhostingservice.com would then either point to an IP address or a round-robin DNS setup.

That leaves the problem of the naked domain. Traditionally you'd point the naked domain to the Primary IP address and then do some httpd.conf magic to redirect the naked to the www (or vice versa). However this does not solve the problem of what happens if the underlying IP address changes.

Pointing the naked domain to a dedicated IP address which is not associated with where the site is hosted removes the problem of what would happen if you change IPs quickly.

I agree with this 100% If anyone wants to implement something like this on a server which you have control over, here is the mod_rewrite line which enables this "service":

RewriteRule (.*) http://www.%{HTTP_HOST}/$1 [R=301,L]

This is pretty much the greatest setup for a mass-lemonpartying known to man.
Forgive my ignorance, but when is this useful?

Don't most self-respecting DNS providers allow you to do this?

That's weird, I usually go the other way - I redirect the www to the naked domain.
That's the way it should be. It's a shame the www convention took hold.
Google AppEngine does not support naked domains unfortunately.

At least, that is what I use it for myself.

I may be wrong here, but I think there's one good reason to use anything.example.com instead of example.com: with the naked domain, you can't have a separate domain for static assets which the client doesn't send the cookie to (for performance improvement). If you set a cookie with the domain example.com, it will still get sent to static.example.com.

Granted, you could use examplecdn.com or something, but then you have to register and manage more domains.

Isn't that what the domain portion of the set-cookie header is for?
It gets propagated to subdomains, it doesn't restrict it to just the domain specified.
Yes, it gets propogated to subdomains, but the point was that if you have subdomain X.y.z, as long as you set the cookie for y.z, the cookie is valid for X.y.z and U.y.z.
My point was that you don't want the cookie to be sent to other subdomains, so you'd actually want to set the domain to X.y.z. You can't do that if you're web domain is y.z.
only reason www is usefull is because common cms (forums, blogs, comments, ....) convert www.example.com to a clickable link, but example.com not. yeah stupidbutthats the way it is.....
It's a pretty clever idea, I've come across loads of sites that have a naked domain but no www.

As clever as it is though, it serves no real world purpose, anyone clever enough to setup up their own domain will be able to set up a www subdomain, be it dns level or using a 301 redirect.

(comment deleted)
What the website advocates, redirecting site traffic through them, is a very bad idea. If you don't know why this might be so, stop and ask yourself why you are in charge of modifying the zone records.
I go with enom. They allow wildcard subdomains, so I just ask nginx to 301-redirect the .www to the root

  server {
    listen       80 default;
    server_name  your_domain.net;
    rewrite   ^  http://www.your_domain.net$request_uri? permanent;
  }
I did this too (redirect2www.com/74.53.18.72). So easy I'm surprised no one at Google/etc has done it with a slick IP address like they did for DNS.