IssueTracker

try that post url again:
http://groups.google.com/group/google-appengine/browse_thread/thread/172596b3582786a2

I'm the developer of what used to be called http://wordle.net/ .

The suggested workaround--to have the domain registrar forward the naked domain to
the www. subdomain--will not help me change the literally tens of thousands of
existing links and images out there, which lead to specific pages in my site. So, if
Google really can't bring back support for naked domains, I'll have to pull the plug
on Wordle (since it's not feasible to move the existing 300,000 saved Wordles to some
other host). Therefore, +1.

@e.e.coli:

Apparently forwarding of links works just fine, check for example:

http://muspy.com/contact - forwarded to - http://www.muspy.com/contact

I used the method described here:
http://www.google.com/support/a/bin/answer.py?hl=en-in&answer=61057 

I tried this for zunzun.com, Google search results for "curve fitting" dropped the
site from ranking of 4 or 5 down to the 30s and 40's - i.e., no longer in the first
page of search results.

Google's search engine penalizes redirects, so Google itself makes this a
non-realistic solution for existing sites.

     James

wolfire.com was actually kicked in the ass by Google after modifying wolfire.com/* to 301 redirect to
www.wolfire.com/*

Even a search for 'wolfire overgrowth' would not return our page in the first 10 pages or so.

Luckily thanks to living in the Bay Area, I have a few friends at Google and they were able to promptly look
into the matter and take wolfire.com off of Google's black list quickly and things seem to be back to normal.  
However, after reading James' post, I am concerned that my search ranking have been hurt in general.

I second James' concern that Google itself is forcing its users to employ what I guess Google considers black
hat SEO techniques.  This sounds like a classic case of the right hand not knowing what the left is doing.

What if Google did not penalize redirects to appspot.com?

That would immediately fix the problem.

     James

This is important to me as well. excla.im is a naked domain and i don't want to move
it. It doesn't make sense and people are not linking to www.excla.im. Please bring
back naked domains. +1

+1 for this feature. it *should* be simple to support naked domains. And, if may I add, essential!

Your applications may not use the domain alone but rather must use a subdomain as is
clearly stated in this Google App Engine policy.  Also, you may not use the
appspot.com url for your application unless you use the google id system:


... all pages requiring login must be served off of some subdomain of that domain.
For example, restricting users to the domain foo.com means that the application can
only be accessed through subdomain.foo.com. If you trying to view the page at
appid.appspot.com it will result in a server error.

The option for restricting an application's authentication settings can only be set
at app creation time, so your first step is to create a new application:


From section "Restrict your application's authentication to members of your domain"
at http://code.google.com/appengine/articles/auth.html

I try to create a site similar with tinyurl.com, but i found i can not use a naked
domain. If i use xxx.example.com, it seems that is too long for me.

Trying to get a custom domain working at all has taken twice as long as developing my
app (verifying domain ownership by adding as an alias in Google Apps silently and
mysteriously fails).  And after all that I find that I can't use the base domain at all.

This makes hosting a site-specific URL shortening service on App Engine unfeasible.
Guess I'll have to rewrite it for another platform, at least until this is fixed.

This feature going dead simply isn't classy. +1

Google should host the 301's needed to fix this.

I would like go much further requesting google to support subdomain binding and
regex subdomain binding.

I'd say this is essential if App Engine is going to be a serious alternative to hosting your own server.  This and
lack of support for SSL for your own domain are deal-breakers for commercial apps on GAE.

This is important to me as well.Please bring
back naked domains. +1

I'm personally sick and tired of the second class citizen treatment of Google Apps by Google. It's 2009 and you
still can't use a lot of Google features using Google Apps accounts.

You can now create a "Google Account" using the same email address as your G Apps login. They do seem to be
separate and I can only assume that this stuff will be unified one day. But at least you can log in an use apps like
this one and G Groups with an @yourdomain.com username.

More on the topic of this issue though:

It would be great if G Apps supported an HTTP redirector. That is, I would map mydomain.com to the
redirector (A), and it in turn would HTTP 301 redirect to www.mydomain.com (or whatever), which CNAME's
into App Engine.

Right now, I have to use GoDaddy for this, which sort of drives me nuts.

NOTE: the redirector would need to preserve path/args, etc.

Not a naked domain, but at least cloud-based support for some kind of response from mydomain.com.

This is important, i bought a domain to be used specifically without any www at the
beginning. +1.

I realize that you are all important people doing important things, but if you have
nothing to add, please just star this issue instead of spamming everyone with `+1'
comments.

[ Yes I realize the irony. If you want to argue with me... please don't do it in the
comments ]

Really important to any URL shortening apps, like bit.ly etc. The short URLs are a requirement in Twitter apps.

So +1

I used dns to get around this........... if you go to cloudclipboard.com or
www.cloudclipboard.com it'll resolve to the same path.  I don't think this feature is
necessary, am I alone on this?  FYI: my dns is with zoneedit, feel free to contact me
if you need help.

Artie

once again: forwarding from abcdefgh.ijk to www.acdefgh.ijk is NOT a solution :)

@another.two (comment 23):

what about urls inside your app.  
eg: cloudclipboard.com/my_app_action?a_get_param
does that work also?

@dennisfogg yes.  try the following url:
http://cloudclipboard.com/Authentication/?operation=login&username=foo.  It's a bad
example because I need to turn off get requests but, it works for now.

@jovan.brakus: I guess I didn't fully understand why this was an issue, I replied to
this post half awake, I see the validity of this issue now.  It is worth noting
forwarding does help in some situations though.

@another.two (comment 26):

yes, the url you gave me seems to work.  I also have one app that seems to support
naked domains.

But as the title of this issue implies, the goal is for google to official support
naked domains regardless of your dns provider/settings.  
Google's current policy:
App Engine no longer supports mapping your app to a naked domain.
http://code.google.com/appengine/kb/general.html#naked_domain

Combining the dns operator's redirect or forwarding works. The reason is probably due
to that google isn't a dns operator.

My DNS is with NetworkSolutions.com who wants to ... CHARGE AN EXTRA $20/year simply
to forward.  So yes, please GOOGLE allow naked domains.

I am also with NetworkSolutions, at least, for another year until my service runs
out.  At that point I will switch to NameCheap.com, which includes forwarding for
free and is only $10.  They also support private registration, which was the big
reason I stayed with NetworkSolutions for many years.  Over the past few weeks I have
moved three of my five domains over to their FreeDNS, which they let you use for
free, even if your domain is registered elsewhere.  Right now I am using that to
support the naked domain forwarding for those three domains (three AppEngine apps)
and it is flawless.  There are other free DNS solutions out there too, I am just
mentioning this one company since it solved my problems with NetworkSolutions without
having to lose out on the registration time I had already paid for in advance.

Any progress on this issue?

I bought a domain through yahoo and they don't allow "mydomain.com" to be redirected
to "www.mydomain.com" only "www.someotherdomain.com". I'd rather not transfer my dns
control somewhere else just to accommodate this issue, especially after setting up
my other CNAME and MX records for google apps already.

Redirecting mysite.com to www.mysite.com defies the entire purpose of hosting your
application on Google Apps Engine.  The reason you want to host on GAE is to get the
benefits of the google infrastructure; the redundancy, the speed, the bandwidth, the
uptime.

By using redirecting, all requests to your site must first cross a webserver hosted
by your domain provider and be redirected to GAE.  This webserver is not as well
connected as GAE, nor as realiable or available.  This effectively adds a point of
failure before the user can reach your highly available google app.

Please, please please natively support real naked urls.  The domain i purchased was
selected because it is small, adding a subdomain defies the purpose.

Thanks

Purchased a domain with the naked domain being part of the marketing.  Until this issue is rectified by
Google, my website and the hosting money tied to it will be going elsewhere.  To bad as Appengine is
wonderful and we would love to use it for our project.

Bought a domain for the purpose of using it naked (http://example.com) and would love to use App Engine to
back it... looking forward to a Google update on when this might see the light of day, thanks G-Team! :)

I'm also in the process of launching a URL shortening service.

I really would like to use GAE and I'm really am shocked to see that GAE does not support naked domains!

How can a company like Google just ignore the fact that loads of startups want short URL's to be used in Twitter messages.
It's just totally insane!! A bunch of people must be sleeping, really.

Everyone knows that redirecting from your own provider is not an option, and again it's really bizar to see Google mentioning this as an option, shame on you Google.

The strange thing is that there are already some url shortening services that run on GAE,  like http://ur.ly   
Read about this great opensource project here: http://adamstiles.com/2008/07/urly-dang-short-urls-powered-by-google-app-engine/

Please also read this great article: No nudity please, we’re Google (or why you shouldn’t mix naked domains and www on Google App Engine)
http://aralbalkan.com/1425/comment-page-1#comment-258336

Then there's  http://urlborg.com  another short url service on GAE

All these services probably just added a couple of A-records that point to servers that service ghs.google.com 
I could do that do, but as this is not officially supported I find it a bit scary.

Also because ghs.google.com are servers that are load balanced and so, so adding a couple of ip addresses is not what I had in mind to put my short url service in the App Engine cloud.


SO PLEASE GOOGLE, YOU'RE MY FRIEND FOR SO MANY YEARS, WHAT'S GOING ON ? ? ?

HELP  !!!!!

Couldn't Google just find a spare IP address and run a universal wwwizer, which would
add the www prefix to all requests and issue a permanent redirect? Would work for me
as a temporary measure.

Obviously GAE isn't a serious option for a startup, it's like a catholic wedding with a
woman you barely even know. Bart's probably better off using a standard pay-per-month
vps that can handle this trivial issue.

I still haven't got an answer why it is not supported. I think that with a proper load
balancer and IP mapping it can be done fine.

justin.forest has the best solution of the bunch... a redirector that simply prepends
"www." would help greatly.

The problem here is that naked domains require, as noted, a fixed IP address. They
cannot be mapped by CNAME (here, to "ghs.google.com") due to DNS restrictions. This
prevents the use of smart DNS to direct requests to different clusters depending on
where the requestor is. Remember that GAE is not conventional web hosting; it's not
only one machine/cluster located in only one place.

For years I've avoided the use of naked domains by redirecting to "www.",
specifically because of the DNS CNAME issue. Forcing the use of a subdomain such as
"www." offers the greatest flexibility, allowing the content to be hosted on anything
from smart DNS based clusters, all the way down to consumer-broadband dynamic IPs.

If you really, really, really badly want to serve up content at a naked domain,
you're better off with conventional Web hosting. Of course, then you won't gain any
of the benefits of GAE's scalability.

> justin.forest has the best solution of the bunch... a redirector
> that simply prepends "www." would help greatly.

It would help because eg. GoDaddy, the worlds largest domain registrar, supports
redirection but drops the path. For example, if you type in 'example.com/foo'
GoDaddy's server will redirect you to 'www.example.com' -- no '/foo'.

If Google offered a redirector which maintained the full path then that would solve a
lot of people's problems.

(It's not as if this doesn't exist already. Try: http://google.com/analytics )

GoDaddy does support maintaining the path and query string on a redirect (we have it configured this way).

You just have to navigate through their sh*tshow of a user interface...

Ah, you are right. Apparently I am not smart enough to navigate GoDaddy's easy-to-use
interface. Thanks!

Do you know if that is also possible with the eNom registrar?

If it were at least possible to *configure* a GAE with a naked domain, it wouldn't be
too hard to use a DNS-level proxy to rewrite DNS records instead of using a CNAME record.

If I can use naked domains in Blogger, why this can't be deployed in GAE?

http://www.google.com/support/blogger/bin/answer.py?hl=en&answer=55373

This one is particularly annoying because App Engine used to support naked domains!

One of my domains is still working with it's naken domain. Enom supports CNAME
records for '@', so everything is copasetic.

I just don't get it..

I like the Blogger url, those Ip addresses are exactly the ones that where used for GAE
in the past, you can still see that in existing short url services. I also made a short url
for this discussion, just for the fun of it;

http://bit.ly/naked777

If eNom is supporting CNAME for '@', it's broken, because it's putting CNAME in
parallel with NS and SOA.  RFC1034, section 3.6.2:

==========
The domain system provides such a feature using the canonical name
(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical name in the RDATA section of the
RR.  If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.  This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.
==========

There are recursive DNS resolvers that, if they are queried for the SOA or NS of the
same name as a CNAME and get back anything other than the CNAME, will invalidate the
CNAME record as in violation of this rule.  In short, if you're using a CNAME at '@',
you *will* break some users.

Blogger may support it, but it's not scalable.  If you're using a naked domain for
Blogger, rest assured that you are not getting the best response times possible for
your users... for all the same reasons above.

(The only way Google could provide naked domain support for real is by taking over
the entire domain as its DNS server, so that the naked domain's IP address could be
assigned at request time by their DNS clusters.)

Google could provide a DNS host for a given domain name, then i could point to
googles NS servers.

the problem for me is compounded because i have a *.is domain name that i want to use
in a naked fashion for a google app.

i can only change my settings every 24 hours.

http://ur.ly has successfully done this, but they do have it pointing to 4 ips.  i
have been trying to use NS lookup to get info on the different DNS names i am
studying, but i guess it's now standard practice to restrict NS lookups for unknown
hosts ( which i can understand ) its just hard to figure out how some have done this,
and many of us are un-able.

the reason redirection is lame, is that it adds a hop to our webservice.

if scalability is the problem, google could also implement dynamic DNS, and
dynamically update our DNS settings for a given domain name.  Sites like godaddy, and
namecheap support dydns, and this would also be an acceptable solution.

if i could get the *.is to work on namecheap, my problem could at least be hacked as
google suggests, however i don't have a highly scalable means to force a redirect to
www.*.is.

please just figure out a solution to this.  i think it's obvious that people want
naked domains.

Related Chromium Browser issue: http://code.google.com/p/chromium/issues/detail?id=20904

I understand why you can't solve this issue (after reading all comment) so I think
you should push Chromium team a little bit.

Please stop using this section as a forum.
I have started a thread.
http://groups.google.com/group/google-appengine/browse_thread/thread/75f86ba9dc7da30d

I get more than enough in my inbox as it is.

[Comment deleted]

I'm tired too of getting all those e-mails from issues, but I'm even more tired of
people asking others not to use the *comments* feature to comment on those issues.

It's Google UI's fault, not people's. When you star an issue you should get by
default only messages with status updates, and have an option to receive them all if
you're masochist enough.

Until Google fixes it we'll have to make do with e-mail filters, because expecting
people not to click on that "Add a comment below" when they want to make a comment is
just a lost battle.

Yep...like Google Groups you should be able to determine if you want to be emailed
directly, get and email digest or get no emails at all.

The way it is now is unacceptable.

Bad Google, bad!

related ontopic I say sequence is get a google domain, it responds via blank subdomain, add
gae app, forward from blank, enom appears handling google dns, told them, got the very important
and responible project we stand for "no reply.."  or what we, the most important people, wish
(=accept)
<>
totally offtopic were, since completely unrelated to this issue and about ad hoc wishlist ("boiling
down to your ability to accept"), and no technical evidence:
Comment 53 by maumac, Today (14 hours ago)
I'm tired too of getting all those e-mails from issues, but I'm even more tired of
people asking others not to use the *comments* feature to comment on those issues.

It's Google UI's fault, not people's. When you star an issue you should get by
default only messages with status updates, and have an option to receive them all if
you're masochist enough.

Until Google fixes it we'll have to make do with e-mail filters, because expecting
people not to click on that "Add a comment below" when they want to make a comment is
just a lost battle.
Comment 54 by java.jago, Today (13 hours ago)
Yep...like Google Groups you should be able to determine if you want to be emailed
directly, get and email digest or get no emails at all.

The way it is now is unacceptable.

I updated the Wikipedia Restictions section of GAE
http://en.wikipedia.org/wiki/Google_App_Engine#Restrictions

[Comment deleted]

Update:

I managed to create a CNAME from my naked domain to ghs.google.com and it just works!

But as ghs.google.com is not listening to this url I get the "The requested URL / was not found on this server." error

So now it's just a matter to have that back in place I think.

I would like to get in contact with Technical or Product lead about this.

Does anybody know how to contact Kevin Gibbs or Paul McDonald?

@bart.burkhardt

This works for your website, but your emails will not be delivered anymore.

@oliver.oli

I just tried it from a non gmail server and got the email fine.
If I send from gmail it fails.

You're right about it can break email, it's also mentioned in the RFC's
From what I understand a sending mail server could get in trouble, if so it would deliver the email to
ghs.google.com. If ghs.google.com would map port 25 to the gmail servers it would be fixed in my
opinion. This could be a cool cloudy solution.



 

The fact remains that CNAME records at the root of a domain have multiple issues.
It's not up to Google to fix that; there's plenty of DNS software in the wild that
expects CNAME to function a very specific way -- as an alias for a domain that is
exclusive of (almost*) any other record.

That software can (and does, depending on query type) get confused when CNAME is in
the root of a domain, because that puts it in parallel with NS and SOA records. This
is a very bad path to take and will eventually cause you problems, whether e-mail,
web browsing, XMPP, what-have-you.

(* DNSSEC records are the only ones allowed to be in parallel with CNAME per RFCs.)

@tvierling I agree it's not the way to go because of the problems that you describe. And
also because it's against best practice / recommendation of the RFC's

Thanks for replying, we still have a problem.

Bart, see comment 39.  Basically the most capable solution that is intra-Google would
be to provide an IP that consists only of a redirector.

http://code.google.com/p/googleappengine/issues/detail?id=777#c39

I think the best solution would be some IP addresses that would be load balanced, hence
connected to the cloud. The company where I work for, is working  with BIG-IP. You can
configure one IP address to balance with multiple others. http://www.f5.com/products/big-ip/

It would mean an investment but it would be the best solution I think.

Redirection is not an option but until now it's the only one. As a matter of fact, I am working
on a free web forward service. I'm testing http://freedns.afraid.org but there's also
http://zoneedit.com

i would like to be able to redirect & preserve the path

so redirect:

mydomain.com/foo to www.mydomain.com/foo

I'm testing http://freedns.afraid.org now and it is preserving the path.

Hi bart -

 Are you redirecting to a google app engine project?   Would you mind sharing your dns settings?    

thanks-
matt

I am using dreamhost to manage my DNS, I have it set as a 'fully hosted domain'
i used the custom DNS feature to cname to ghs.google.com, and i serve the 'A record'
domain and use a .htaccess script to mod_rewrite the incoming request to www.loc.is 
which is cnamed to ghs.google.com.

i tried every other option something like this is optimal.

I first had to move the NS servers to freedns.afraid.org. Then I created a A record.
I did not use www but only w and pointed that to ghs.google.com (You have to
configure this URL also in GAE)

Then I forwarded the blank or naked domain to http:/w.mydomain.com

Today Google launched its own url shortener http://goo.gl

Read more at the Google blog: http://googleblog.blogspot.com/2009/12/making-
urls-shorter-for-google-toolbar.html

I think it can help someone so I opened my http redirector for anyone to use.
Check here: http://wwwizer.com, I can respond to questions by email and in this
thread:
http://groups.google.com/group/google-
appengine/browse_thread/thread/c1dd182ed482fb5a

Thanks dimaulupov.  Your solution works well for my site (which gets <10 hits/hour,
so no harm to your router/link  ;-)

Alright Google App Engine team! You just implemented wildcard domains on custom URL's... now this is the next
step! You guys are doing a great job and the App Engine is going to rule the world! We just need naked domains
and a few other things maybe... but here is my vote! +1

+1 for me, too. SEO is quickly moving to naked domains, too. Users, particularly on mobile devices, need to type
in their browsers as little as possible.

3 workarounds are client redirects, DNS or google.com/a appears getting GAE here ie
gralumo.com

www CNAME is a horrible remnant of 1990's internet.

To help clueless users browsers used to add the www for you, at least I see Chrome no longer does this and simply suggests www.example.com if you type example.com and it gets no response.

I've been testing AppEngine.  I've got my bags packed and ready to move in... waiting for naked domain.  +1

I've got two account ready to move in the next week, everything to google (small biz with google for domains, appengine for database).

I still need to maintain one accoutn with an ISP, just to host a nacked-domain redirect (DNS provider cannot redirect) ;-(

Hi pedromorgan, you can use wwwizer.com and no need for account with ISP.

@dimaulupov i believe this functionality should be done by google, because i don't like words i see on wwwizer.com: "But remember one thing – there is no warranty of any kind". In case of any problem with wwwizer.com - i have to fix dns record and it can take up to 48 hrs to be propagated through the world which is not acceptable for any business i think :(

Warning: wwwizer.com might block your harmless little website and not answer any emails you send to help@wwwizer.com to explain why. Not cool.

To be fair though... the site does say it doesn't come with a warranty, so I was properly warned.

Until Google fixes this, you're probably better off rolling your own wwwizer. Of course, like many others have said, it's a shame that you need to do that. If GAE is really targeting businesses that want to build websites, then supporting naked domains should be a core feature of their service.

Try using www.editdns.net
i believe their free DNS service allows forwarding for naked domains, also has a nice template feature for quickly setting up Google Apps hosting.

@Ustas.Michelius I also believe that Google can do simple redirects. But now it doesn't. I have spare reserved instance @aws, some number of apps at gae and all my domains at Godaddy. Tired of clicking every time - made wwwizer.com

About trusting other services - just don't trust anyone. I don't have your dns - you can change it anytime you want.
Propagation time depends on your TTL values in A-record. Put TTL 20 minutes and you are safe.

@ryan.niemeyer Harmless little website you are talking about - probably urizy.com?
Yes I blocked it, after receiving complaints from Amazon about spam emails using your service.
If you are making "serious url-shortener" (as said on a website) - consider using your own www-redirector.
Sorry mate, don't have time to answer abuse email not addressed to me.

@dimaulupov If you want to know what urizy.com means by "serious" I suggest you watch this video: http://youtu.be/i6Fr65PFqfk

I have no problem w/ you blocking that site, what I do have a problem with is the lack of response to emails sent to help@wwwizer.com asking for a simple explanation of why it was blocked... and then coming on here telling people to use wwwizer without mentioning that you might block them without any explanation.

Regardless, I think we are all on the same page here... this is something Google should be supporting. For serious sites and sites that are very much NOT "serious".

@ryan.niemeyer Sorry mate, but, yes, spam-helper sites will be blocked without much explanation.

Prio block scamming if any block, paulgraham.com/antispam.html has stuff for sceptics while normal professional improve creative functions

I'm un-starring this issue due to all the irrelevant mail coming from the recent comments. I'm probably not the only person. If you want this to be implemented (which means being starred by lots of people), I suggest you move the mindless arguing and unrelated discussions somewhere else.  

Allow me to digress for a moment. You are forcing us to go out and find a DNS provider that offers URL forwarding. And, ok, most DNS providers probably do. But my application also needs wildcard subdomains. Trying to find a reliable DNS service that offers both wildcard subdomains _and_ URL forwarding is a nightmare. In my search, I have gone through dozens of DNS providers, and so far I have only found one: but it's a free service and only a few hundred visitors knocked it offline.

However, I think the real issue is that there is no real reason why this feature should be missing! Are there technical difficulties associated with this? My DNS has successfully CNAME'd my naked domain to ghs.google.com, where I get a google error that nothing exists at that location. The code required to get that working from google's side isn't much different from what is already done. I can't believe you would support wildcard subdomains before you would support this! Please, am I missing something? If you're going to offer a cloud hosting platform, how on earth can you think it's "ok" to leave this feature out?

Unstarred due to too many "digressions".

Stars show support, anything else that isn't relevant to the development or delivery of a fix is just spam.

Unstarred. Comment 4 works fine for me.

Redirection isn't really a solution, since you still end up with a big ugly 'www' on the front. Why not use table layouts and ActiveX applets while we are at it?

The www isnt big, ugly! Its the best practise using a 301 redirect for naked domains. Many peoples still type www so you have to support it. Allow both without redirect will be a bad idea, since www.mysite.com and mysite.com are different hosts, different cookies belong to them. I'm going to remove my star here! This issues isnt it worth to get all this annoying mails. *Why* can the peoples not read at least the first and last few postings? There are so many workarounds. This is a issue tracker, not a Maillist for help. Please join the appengine Google Group, thats the place for help. Thanks

One final comment, then I am going to unstar this.

I am almost certain that appengine for enterprise will resolve this issue in conjunction with HTTPS support. With a dedicated IP address, naked domains will be a simple no-brainer to implement for goog.

Counterexample 2 like www.com.mx and www.web.com.mx then regex technically covering any interpration likely confuses easy counterexamples

Unstar - enom and many other registrars allow forwarding and wildcarding.

Redirection is not a good solution, but not because appending www is ugly. Everyone is quite used to it!

The problem with redirection is that it does not work for TLS/SSL. If the application/site requires a secure connection, redirection does not work since services like wwwizer cannot provider a valid certificate for every domain. Last I heard, Verisign is not issuing global wildcard certificates (cn=*).

Also, another problem that I would have with using a solution like wwwizer, is that you rely on their service to be fault tolerant, to scale and not to be bought up by a sleazy internet provider who wants to temporarily steal your traffic while you frantically change DNS servers. Does anyone really feel good about trusting important applications to this service?

Last comment, I believe most of the spam from this discussion is everyone commenting about how they are going to unstar the discussion. Please, keep it to yourself!

Please excuse me for being off the topic, but those who get irritated by the comments they consider meaningless might want to star issue support:4107, which proposes adding a way to mute noisy issues and only receive comments by project members.

I don't need naked domains, as a three level domain would be fine for me.  www.foo.com cnamed to www.bar.com where bar.com is the Google Apps account would be fine.

It seems wrong to have to make a google apps account for every top level domain.  I don't need more than 10 apps running, I just need them each to be on separate domains.

Please also star this reuqest for regular cnames:
http://code.google.com/p/googleappengine/issues/detail?id=2649

It has only been starred by a few people.... and appears like it would actually solve much of what most people here need.

@98: You can simply add add any domain as an alias to your main Google Apps account.

Hell yeah! Please officially support naked domains!!!

With out this feature, our decision to not use GAE just became dead-easy.

Google, of all people, should know better than to mess with people's search engine optimization and pagerank.

Wanting to switch to GAE, but dont want www!

Some people may be interested in this work around which requires access to an already running apache server.

If you do have a server with apache and have permission to modify the apache config file, you can use mod_proxy, to proxy all incoming request from one domain to, any other domain, so with mod proxy you can do:

http://mysite.com -> http://mysite.appspot.com

The main downside of this is a single point of failure for your website, and secondly all your page hits come in via a proxy which means you have code that checks a users IP address, you need to install a work around to check the originating requestors IP address.

It just doesn't make sense for a company to use GAE without naked domains. I don't get which is the purpose of google not giving this feature. It was fun to use it while I was doing projects at my university. But building a start-up is not the same. Give support for naked domains!!!

[Comment deleted]

[Comment deleted]

I need it!!

i want it

i need it!

I vote for this as well!

please allow naked domains for GAE, +1

must have!

It's pretty ridiculous that naked domains aren't supported, and also that Google Apps is required to manage these settings. This is a solvable problem; please go solve it. +1

[Comment deleted]

I need it too!

I think this is an essential feature. How am I to setup a scalable url shortener service when I need to rely on an external (non scalable) redirect service to make it happen? Adding size to the url is not an option, and we can't afford the extra request/lag.

+1 This is a basic essential core, not even a feature.

Support for naked domains would be the icing on top of the cake. Please consider raising it with the product managers, it will make the service even more attractive (which, admittedly, is already a challenge!)

[Comment deleted]

Frustrated that there isn't even a workaround anymore, which enables naked domains.
I've been learning Python just because GAE looked so promising and wasn't aware of this issue until today... Naked domains are a must for the social apps I'm working on  - I guess I'll have to check Django…or back to ASP.NET... :(

Since google handles both requests it should be able to direct these to same:
http://alltfunkar.com/
http://www.alltfunkar.com/
The former responds a google error and the later my blobstore app. It should be just a DNS setting.

Ant good news recently, even forwarding in GoDaddy is not helping, I'm sorry that paid $10 for this

This should be high priority, not medium priority. It's an essential feature.

please.

+1, nobody types www anymore, and you either have to expect your users to type it in or redirect.

+1, i don't want to need to do a redirect.

777 stars for issue 777. Redirects are slow. If we get to 777 comments, will you fix it?

(I wouldn't post this useless comment, but they've turned off auto-email, so I'm hopefully not spamming 777 people.)

+1 GAE is a perfect project! But i need naked domain!

i need it!

need to be naked :)

naked domains should not be medium priority - it is an absolute must-have for any serious web application. Please add it.

need to be naked, +1

+1. Surprised to see this missing

need it

I need it.

This is affecting us, as we're a launching a biz built atop app-engine and heavily dependent on search engines, yet are being penalized from a search perspective due to this.  Also incredibly inconvenient from a hosting/management perspective.

Ya i need to it and very very very important. I am running a big project in GAE.

A solution would be for Google to offer DNS hosting. Then naked domains shouldn't be a problem to implement.

Redirection from the naked domain to the www subdomain is failing on my website. The worst part is that the failure only occurs on some machines. Godaddy's support is atrocious.

парни, ну сделайте уже

Need naked domains support, please

Naked domains support, please

Very surprised this was not available. Wish I had known before moving my small non-profit over to Google Apps. Everything else was an easy sell, but from a marketing communications standpoint, this is a must. Thank you for considering our need!

Ip address 77.37.146.180 will redirect your naked domain http://domain.com to http://www.domain.com. The only thing you have to do is to add the following record "A 77.37.146.180" to your naked domain

Need this too :(

How do we enable the redirect like comment 145 states?
Record address 77.37.146.180
Record type A
But which host name?

this is a must have feature. badly surprised to see it's impossible to make without 'hacks'

must have feature

+ 1

It seems done now. http://koolbusiness.com responds OK from here. Can you make affirmation? I followed the instrcution from the google apps panel domain settings.

What's the difference? Here's enom saying the configs are the same and different. "Hello Nick,
Thank you for your response.The DNS host record configuration for the domain alltfunkar.com is exactly the same as the DNS configuration that you have for koolbusiness.com. These domains are correctly configured to use Google Apps. Since the domains are configured correct for use with Google Apps, the ssue as you've described is related to Google Apps for Your Domains, not your DNS settings. eNom can only assist with questions about your domain management interface via http://access.enom.com and the settings that are available here. For issues with your Google Apps account configuration, domain resolution and services you will need to contact Google support directly. Please visit the Google Apps Administrator Help Center at www.google.com/support/a to find out more information or get in touch with the Google Apps support team via http://www.google.com/support/a/bin/request.py?contactus=1 Regards,
Google Advanced Domain Support

[Comment deleted]

[Comment deleted]

It's done for now and working.
Instructions to enable:
1. At least, one of Google Apps core services (e.g. Gmail) should be enabled.
2. In Google Apps control panel, in Domain Settings check "Enable pre-release features" and toggle "Next generation".
3. Now, in Domain Settings will appear a new tab – Domain names. All you need is here.

This is working, followed instructions and was able to setup redirection of my naked domain to GAE sub domain (i.e. http://example.com -> http://gae.example.com) using Google Apps.

Is there any way to make it work in way that user don't actually see the redirected domain? But maintains the naked domain in his browser URL?

[Comment deleted]

If you can control some arbitrary webserver, you can attach your naked domain to it, so that main page will load Google Apps subdomain content in frame, via AJAX or similar way, so it will be transparent for user.
For this moment, Google Apps able to do only HTTP 302 redirect on naked domain.

We need top-level domain working for our App.
Also we need HTTPS working with our domain.