(No comment was entered for this change.)

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.

since you can get a blank google domain (eg. alltfunkar.com) responsive, it's technically doable and 
matter of principle somewhere.

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

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

	Screen shot 2009-12-07 at 12.04.28 PM.png
	57.4 KB Download

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