6 ms·
CNAME is absolutely an issue, especially when using managed hosting. Many hosts require that you CNAME since they move around IPs. (e.g. Heroku) so unless you p
by ericpauley 8y ago
CNAME is absolutely an issue, especially when using managed hosting. Many hosts require that you CNAME since they move around IPs. (e.g. Heroku) so unless you put a provider in front of them that integrates with your DNS you need www.
- hacknat 8y agoYou can add AWS, Azure, and GCP to this list. Most people don’t want to lay out the money for a static IP, and why should they?
- yegle 8y agoNot true for App Engine: we have a fixed set of IP addresses to be used in A/AAAA record. Disclaimer I work on App Engine.
- hacknat 8y agoThis FAQ on App Engine specifically says you guys can’t map a static IP to a site: https://cloud.google.com/appengine/kb/ https://cloud.google.com/appengine/kb/
- stickfigure 8y agoThat is something different. If you want to run your app on a naked domain, they give you a set of A/AAA records you can use. Search in that same document for "naked domain".
- paralelogram 8y agoApp Engine uses four anycast IP addresses: https://www.bing.com/search?q=ip%3A216.239.32.21 https://www.bing.com/search?q=ip%3A216.239.32.21 https://www.bing.com/search?q=ip%3A216.239.34.21 https://www.bing.com/search?q=ip%3A216.239.34.21 https://www.bing.com/search?q=ip%3A216.239.36.21 https://www.bing.com/search?q=ip%3A216.239.36.21 https://www.bing.com/search?q=ip%3A216.239.38.21 https://www.bing.com/search?q=ip%3A216.239.38.21
- merb 8y agoyou should read before you write. > I'd like to map my app to a naked domain (such as http://example.com http://example.com). vs. > App Engine does not currently provide a way to map static IP addresses to an application the latter is that you own an IP and want to map it against your appengine. the former is example.com -> appengine site. (not related to google)
- gray_-_wolf 8y agoWe solved this by having cloudflare manage our dns and they offer something like "cname to ip".
- TheRealPomax 8y agoYou sidestepped it, rather than really solved it: you got rid of the CNAME issue by trading it for a proxy availability issue. It works--of course it works, it's literally why cloudflare exists--but now your service availability is directly tied to cloudflare's availability. And cloudflare glitches often enough that plenty of people run into their 5xx pages on a daily basis across the web. So you traded an intermittent problem (only relevant when an IP change occurs) for 24/7 guaranteed service outages for a (probably very) low percentage of your intended demographic.
- Dylan16807 8y ago"Now your service availability is tied to your DNS service's availability" is always true.
- amingilani 8y agoFor pretty much any DNS service you use.
- TheRealPomax 8y agoWould you like me to edit it so it says "Now your service availability is tied to not just the global DNS system that literally anything that wants to exist on the web with not just an IP but a named host relies on, but a secondary routing entity that sits on top of standard DNS and does fancy things"? Because I'm pretty sure we all know what I meant when I pointed out using Cloudflare means gaining a convenience at the expense of being at the mercy of third party outages.
- scoggs 8y agoIt could just be a stopgap in the meantime while they write the true solution? Just a thought.