How do I use my Google App with my a custom domain? - google-app-engine

I've looked at previous questions enter link description here, but they use the GSuite Administrator to make changes, while my app uses GCloud. The domain registrar is separate since Google domains don't work in my country.
I mainly followed this guide to setting up my Zones and updating the name servers. I've configured the
https://cloud.google.com/dns/docs/update-name-servers
The question I linked to earlier recommended setting up a www. subdomain, but it used Authenticator. I'm not sure how to do this in a zone. I set up all the records properly in my domain registrar.
Here are the settings:
When I load the site itself (There's no actual HTTP response code):
And when I try the www. subdomain
I'm sure there's a step I'm missing, but this is my first site with GCloud. So I'm not very familiar with the process.

I think where is your missing step.
When you ask Google to use your domain, Google will expose HTTPS endpoint. HTTPS requires a certificate, and Google will generate it for you. However, before doing this, Google has to be sure that the domain belong to you.
You have to prove to google that you own your domain. For this, go to this page, log in and add a property (your website URL). Follow the instruction and be sure that your property has been validated.
Then, wait some minutes (hours?) the time that the certificates are generated and deployed.

Related

How to configure custom domain for App Engine for service that is not the defautl in GCP?

I have one Node aplication runing on default App Engine service. Its was runing on "urlFromWebSite.appspot.com", and I config it to run in my domain url "customUrl.ai".
I built a second service with Node with name "second-service",and its runing at
"service-two-doturlFromWebSite.appspot.com", but i want to run at "subDomain.customUrl.ai"
I tried dispatch.yaml file with the url that i want for 'second-service';
Stack post 1 talking about dipatch
Stack post 1 talking about dipatch
GCP explanation for dispatch
I have tried Custom domains in App Engine > Settings > Custom domains;
GCP documentation for mapping custom domains
At custom domains I config my subdomain url, and it generates the DNS. ยด
I have question here:
Where should I add this DNS config? At the "customUrl" or should i create a new record set for it?
I have been strugling with it for 2 days already, and could figure it out how to solve it. How should i config this to change my second service's url for a custom subdomain?
When user enters customUrl.ai in a browser, traffic should be routed to Google's servers (for your GAE project). To do that, you configure DNS settings on your domain registrar's end.
When user enters subDomain.customUrl.ai in a browser, traffic should be routed to Google's servers. To do that, you also configure DNS settings on your domain registrar's end.
Both #1 & #2 are done for the same domain on your domain registrar's end (which is GoDaddy in your case). I believe this is what #JohnHanley is referring to. Put another way - just go to GoDaddy, find your domain and create entries corresponding to what GAE has outlined for you. If they are duplicates, GoDaddy will tell you.

How does DNS domain verification work?

Im reading this google doc on how to hook up app engine to a custom domain (a domain I purchased through a different registrar)
I get to a point where I have to "Supply the domain name ("example.com") and click Verify. This opens up a new tab titled Webmaster Central." and walk through some prompts to prove I own the domain.
After doing this "domain verification is automatically re-confirmed about every 30 days".
What exactly is "domain verification"? Is there like a domain verification protocol that all DNS registrars must support? What communication is happening between google and say godady or AWS (route53)? Is there a special type of DNS record specifically for verification?
I don't understand whats actually happening to prove I own the domain and if this process is standardized or each DNS provider has their own solution/quirks for doing this.
From Verify your site ownership (also accessible via the Webmaster Central help menu):
What is verification?
Verification is the process of proving that you own the site or app
that you claim to own. We need to confirm ownership because once you
are verified for a site or app you have access to its private Google
Search data, and can affect how Google Search crawls it.
No, it's not a standard. Each hosting provider asking for it had their own method/algorithm of doing it.
Google actually has several such optional methods so that you can choose one that best works for your case. They're listed in the Verification methods chapter further down in the above-mentioned doc, together with some explanation of how each of them operates. Not all of them are based on DNS registrar actions.
Also keep in mind that Webmaster Central is used for other sites as well, not only for GAE-based sites - just in case some things might not make sense in a GAE context. This includes sites not even hosted on/using Google infrastructure/services.

Google App Engine redirecting all naked domain requests, causing letsencrypt to not work

I have a GAE app and a custom domain registered on enom.com. The app is a static website that's configured by app.yaml.
I'm trying to use LetsEncrypt certs for ssl, so I want to have valid certs for both www.example.com and example.com. I can get the cert for www.example.com working fine.
However the problem is in my naked domain. Whenever a http request goes to http://example.com/, it gets redirected to http://www.example.com/, ok. But, if a http request goes to e.g. http://example.com/a.html, the request is still redirected to http://www.example.com/. So when LE servers come looking for their well-known acme-challenge, it fails because they see index.html.
I guess this isn't a common behavior because no one is mentioning this, not at https://code.google.com/p/googleappengine/issues/detail?id=10802, nor at https://github.com/certbot/certbot/issues/1480.
I've tried to dig into why this is happening, one error I can see is here:
If I select to overwrite, GAE says it "failed to insert mapping"
This whole project was started by another person and he claims he's not aware of example.com being assigned anywhere else. I've looked at his Google Cloud Console and it would seem that he's correct.
Maybe something of interest is that in the Domain page of admin.google.com, naked domain redirect is set up. It redirects example.com to www.example.com. I've not found a way to disable it.
On my dns registrar, I have input the four A records, four AAAA records, and a www for CNAME.
TL;DR: My LetsEncrypt acme-challenge is failing for my naked domain, help!
I started getting the same error in app_engine after I went to Google Apps account and added example.com to redirect to wwww.example.com. After I did this, in app_engine I got "is already mapped" error. And there was no way to undo the redirect in Google Apps, so my guess was that Google Apps had mapped it and so App Engine could not modify it or add it. I had to explain this to Support team, and btw Google Apps support is free to call, so contact them and then get transferred to App Engine support team.
There is no way to fix it yourself, you have to get Google Support on call and explain clearly and they can reset. I was bounced between Google Cloud and Google Suites (Apps) support teams 7 times and after 2 weeks finally resolved, each one blaming the other, until I found a guy who understood this issue and fixed it for me.

GAE naked to www custom domain mapping does not work

I setup a custom domain on GAE using the tutorial at aral balkan to access http;//app.apspot.com at http://app.com. (I can access the app at www.app.com)
The tutorial is pretty old(Sep 2008) and it mentions
Add four Hostnames for the naked
domain (i.e., yourdomain.com without
the www) and have them point to IP
addresses 216.239.32.21,
216.239.34.21, 216.239.36.21, and 216.239.38.21.
I added the required A names to my domain dns, but accessing app.com leads me to a Google 404 page
I have used naked to www redirection on blogger using a similar method(A names provided by Google Blogger Help) and it has worked for me(it still works). However apart from the article at aralbalkan.com, I have not come across an official source which says that naked to www domain redirection using these IPs works for domains on Google Apps(which GAE uses to manage custom domains).
My Question:
Does anybody use a similar method(A names pointing to Google IPs) to resolve www domains from naked domains for custom domains on GAE? If yes, are the IPs different or am I doing it wrong?
The alternate method that I can think of using is, getting a third party host and pointing the A name of app.com to the IP address of that third party host, followed by placing a 301 redirect script to www.app.com on that host.But that will require me to manage another hosting just for naked to www redirection.
If anyone knows of any easier methods to achieve naked to www redirection on custom domains for GAE, please help.
Update:
Thank you for the answers. If it can be of any help, I am using geoscaling.com for DNS. I have an everydns account too. The domain is on namecheap and namecheap offers a freedns option too.
Update 2
Switched back my dns to namecheap. I guess geoscaling.com does not offer a 301 url redirect(correct me if I am wrong), although it's still a great service. Namecheap offers a 301 URL redirect. Should start working in some time.
While it's true Google doesn't officially support naked domains, it is possible to make this work using your registrar's DNS and Domain Forwarding tools.
For example, http://conversionsupport.com is hosted on Google App Engine, and GoDaddy is where the DNS is managed. The naked domain redirects to the http://www.conversionsupport.com subdomain using a domain forwarding rule.
Requests for the naked domain result in a 301 redirect to the www subdomain. Some SEO resources claim that using one subdomain is better for ensuring search engines don't see your site's content as being duplicative. This 301 redirect should help ensure that both naked domain and www subdomain are treated the same.
Here is a resource for Setting up URL Forwarding in GoDaddy. Note that while this is intended for Google Sites, I have confirmed that it does work on Google App Engine apps.
UPDATE:
To clarify, the naked domain itself will redirect to the www subdomain. This means that if your users type http://example.com then they'll be redirected to http://www.example.com as is the case with my original example above.
From what I understand, most Google Apps accounts are partnered with GoDaddy. Here are the Instructions from GoDaddy Support on Domain Forwarding Using a 301 Redirect..
Naked domains are not supported on App Engine. You need to use www-redirects, as you suggest.
Naked domain (e.g. yourdomain.com) support for App Engine can be setup in three steps:
Setup a naked domain redirect to a subdomain of your choice (e.g. redirect mydomain.com -> www.mydomain.com). See the App Engine FAQ, which instructs you to configure the redirect via the Google Apps control panel for your domain.
Configure App Engine to serve traffic for your custom subdomain (e.g. www.yourdomain.com) via the Google Apps control panel.
(Optionally), setup SSL for your custom domain. This step is required if you which to serve https:// traffic, but not required if you only plan on hosting http:// content.
As nick says, naked domains are not supported by app engine.
On your point of easier methods to achieve naked to www redirection on custom domains... Some DNS hosts, (for example, dyndns.com) integrate that ability into their DNS control panel. You may check with your DNS provider to see if that is the case.
With all the changes over time, I wanted to post that GAE (at least at the time of this writing) DOES support naked domains. I have this working for wdydfun.com. Follow the directions as mentioned above by Fred Sauer and it will eventually work. I'd love to provide more detail on those steps, but things seem to change frequently. You'll have to click around a bit to find where to set stuff. With the DNS propagation time that can be a bit frustrating. I recommend running
dig ns <your url>
from the command line to help see what is going on. My "www" domain was resolving to ghs.google.com and my naked domain was resolving to dreamhost where the domain was registered. After filling out the extra "A" records from the google directions, the naked domain eventually started returning different information and it worked. If you are testing this out in a browser, it's worth mentioning that at the time of this writing webkit browsers seem to be pickier than mozilla. My DNS settings:
A 216.239.32.21
A 216.239.34.21
A 216.239.36.21
A 216.239.38.21
TXT google-site-verification=W0rC...fnQ
* CNAME ghs.google.com.
Yours will probably look similar. Unless the directions have changed again. The CNAME value changed since when I first set things up, so if what I'm writing here differs from the directions on Google, trust the directions on Google. HTH.
Naked domain mapping works from the Google Developers Console.
https://code.google.com/p/googleappengine/issues/detail?id=777
We have added support for custom domains for App Engine from the
Google Developers Console, meaning you can now associate a custom
domain without first associating that domain with Google Apps.
To access the feature, visit https://console.developers.google.com/
and you will find the option to add a custom domain under App Engine >
Settings.
NOTE: Currently we do not support SSL on custom domains created
through this method (although we expect to rectify this in a future
release). In the meantime, we continue to support SSL (via VIP or SNI)
for custom domains that are created through Google Apps, and we
continue to provide free HTTPS for all *.appspot.com domains.
Alternatively, you could follow below steps which solves this problem, for sure,
Ping the website you are wanting to forward to, in order to get the
IP address if you don't know it.
"Run"; CMD; "ping yourwebsite.com"
Will display ping data and reply from IP address. Note this address.
Login to Godaddy.com to manage your account or other domain registry
site
Go to DNS Control Modify/Add "A Host"
Under "Host" enter: #
Under "Points To" Enter the IP Address you obtained earlier.
You are done! Site is forwarded without the www prefix when entered into
address bar.
More details and reference :
http://www.techproceed.com/2014/05/custom-domain-setup-on-blogger-with.html

Redirecting domain (not google apps) to appengine

I'm building a application that supports different domains. A small CMS that supports different domains.
But what I can't figure out is how to redirect other domains that's outside google apps. I have a domain at google apps, that work's perfectly.
When I create a cname that points at either my appid.appspot.com or www.appsdomain.com it just goes to google.com.
What do I need to do so the other domains point to my appengine application.
..fredrik
You can't just use a cname because google needs to know how to direct the requests through their infrastructure to your app.
You should follow the instructions here: http://code.google.com/appengine/docs/domain.html to set up your name with their infrastructure so that requests to the cname get routed correctly.
Update: You do not have to move your domain to google, only inform them of the names you are going to set up cnames to point to them.
You can do that without a cname.
You need to set up a redirection mechanism of your second domain name. You can do that either by telling your registrar to redirect that url to your Google Apps url (that's how I do it with my registrar, name.com), or you could set up a small [php] script on a server you manage that would receive the queries on the second domain and issue a 301 redirect to your Google Apps domain.
EDIT: It all depends on what you want to do. If you want your app to live at both urls, then this solution will not work. I wrote this in the idea that you want the second url to redirect to your main url, if that's not what you want to do, then issuing redirects won't do the trick.

Resources