I'm running my parse app on a naked domain. Parse is not making my life easy though.
At first I struggled to set it up because most DNS hosting services don't allow CNAMEs on the the root domain and Parse requires a CNAME.
Decided to try it out with CloudFlare's CNAME flattening and it ended up working by setting up the CNAME under [hostname key].example.com.
Parse wouldn't allow me to set it up without the hostname key because example.com was not a real CNAME (it's being translated to an A record under the wood by CloudFlare).
But I want to run my website under HTTPS so I registered a certificate that is valid for both "https:// example.com" and "https:// www.example.com".
Again Parse doesn't make it easy. First it didn't accept my certificate because the hostname wouldn't match. I thought that maybe it was trying to compare it with the subdomain of the cert (www.example.com) and that wouldn't match with my app domain (example.com).
I created another CNAME at [hostname key].www.example.com poiting to my parseapp.com url (didn't want to change www.domain.com because it's already poiting to another service that redirects to domain.com), changed my app hostname to www.example.com and it finally accepted my certificate! Yeahhh!
Changed the app hostname back to example.com and tried to access it in the browser, but it takes forever to load and ends failing.
If I change my app to run on "https:// www.example.com" (secure site with with the www subdomain) then it works fine.
So I'm able to run my app in http://example.com (not secure, without www) or "https:// www.example.com" (secure with www).
Why is it that Parse makes it so difficult to run an app on the root domain?
Is there something that I need to do to be able to run a secure app in the root domain?
Most of web services nowadays are designed around the idea of CNAMEs: they provide you a CNAME and you should alias your hostname to that name.
However, as you noted, the CNAME has certain limitations imposed by the DNS protocol RFC and it can't be used to map an apex domain.
Some DNS companies, such as DNSimple or DNS Made Easy, provides a CNAME-like record type that can be used to map the root domain to an hostname provided by a cloud service. Using these services will also make it easier to configure an SSL certificate.
Speaking of SSL certificates, beware that when you purchase a single-name certificate for example.com or www.example.com, it is only valid for that specific hostname. Most certificate authorities will also include the corresponding apex domain if you purchase www.example.com, but you need to check with your SSL certificate provider.
Last but not least, the ability to redirect HTTP to HTTPS traffic really depends on your service provider, in this case parse.com. Unfortunately, it's not uncommon for these services to not force HTTPS. Heroku is currently doing the same, they don't force HTTP to HTTPS when you enable HTTPS.
You should check with them if there is a way to apply such redirect, as the only way is to apply it either at server level or app level. You can't apply the redirect, for example, at DNS level.
Related
I have mydomain.com.au setup with a DNS provider. I have successfully pointed my DNS target through Heroku to my DNS provider. However, to do so, I had to use a CNAME record to do so. As such, the web app is now available at www.mydomain.com.au.
I am trying to redirect www.mydomain.com.au to mydomain.com.au instead. This seems to be quite challenging. As per this Heroku Guide, I need to use specific DNS providers that support ALIAS or ANAME records to do this. However, none of their DNS providers support domain transfer of .com.au
Does anyone have an alternative????
You can use Cloudflare DNS, where you can enable proxy and configure the website to redirect if the user visits www.mydomain.com.au.
I am hosting my nodejs app in heroku and my domain name is in OVH.
I managed to create a subdomain www and a CNAME record that points to my heroku app. It is working fine and SSL is also working fine from heroku.
I added a redirection from all subdomains to https://www.mywebsite.com and everything is working fine.
My problem is when i type www.mywebsite.com, there is no redirection and no SSL.
How can i redirect www.mywebsite.com to https://www.mywebsite.com ?
Thanks !
Unfortunately, No.
DNS maps domain names onto IP addresses, that is, it tells the client that example.com points to 12.34.56.78. HTTP vs. HTTPS is a matter of picking a port, and using the right protocol, and this is negotiated directly between client and server; DNS lookup has already happened before that.
If you want to redirect all plain-http traffic to https, you have to do it on the web server, not the DNS server.
In your situation, you could do this in node.js.
There tons of examples online for node's built-in http server or for frameworks like express. I'd recommend this solution.
But there are also solutions like Cloudflare.
They offer you a DNS Service and a proxy, which can handle such HTTP to HTTPS redirection and they even let you use their own SSL Certificate, so you don't need to buy (or let's encrypt) a SSL Certificate on your own, for example.
I purchased a domain (say, example.com) from Google and my Django application (say, mysite.herokuapp.com) runs on Heroku. The CNAME is set on Google to forward the http requests to the Django applicaiton on Heroku. Forwarding requests from http://mysite.example.com to mysite.herokuapp.com works just fine.
Recently, I need to introduce progressive-web-application to my application and it requires the https protocol, instead of http, that is, the URL now has to be https://mysite.example.com and it doesn't work for Google domains. I tried https://mysite.herokuapp.com and it works fine, which means Heroku already supports https. However, I tried (and also googled) for a long time without finding a solution.
So how do I set the Google domain to use https protocol?
The DNS answer from Google cannot contain the port or protocol (http vs. https), it just contains the hostname.
You need to add a redirect from http to https in the Heroku django app, see e.g. here for more instructions.
It's not Google you need to change, it's your Django configuration.
Set SECURE_SSL_REDIRECT to True, and enable the SecurityMiddleware in your app, and any requests should automatically be redirected from HTTP to HTTPS.
When switching to HTTPS you need to add certs to heroku and that process updates the host from "mysite.heroku.com" to something like "tokyo-2121.herokussl.com". You will need to update your DNS to serve HTTPS pages from the new SSL compliant heroku instance for both HTTP and HTTPS.
Here is a tutorial that outlines the process with Godaddy, it should be very similar or all DNS providers.
http://www.joshwright.com/tips/setup-a-godaddy-ssl-certificate-on-heroku
Just got a solution from one of Heroku's engineers:
1) Upgrade the Heroku app to a paid one (e.g., Hobby)
2) On the DNS provider's settings, set the DNS target to <app_name>.<domain>.herokudns.com (e.g., "mysite.example.com.herokudns.com")
3) Run $ heroku certs:auto:refresh -a <app_name> (e.g., $ heroku certs:auto:refresh -a mysite)
I'm not sure if this is the same problem that you ran into, but when forwarding from https://example.com to my wix subdomain https://learn.example.com, I got a "No resource with given identifier found" error in the browser. Forwarding from http://example.com to https://learn.example.com was working just fine.
I had to open Google Domains' advanced forwarding options for my forwarding rule and enable SSL forwarding, like so:
DNS A-records require that an IP address be hard-coded into your application’s DNS configuration
...which Heroku recommends avoiding. Heroku suggests two workarounds:
...using a DNS provider that supports CNAME-like functionality at the apex, and using subdomain redirection`.
My question revolves around the latter option (because the former isn't supported by DreamHost AFAIK):
Is it possible to redirect from the root (i.e. apex or 'naked') domain to the 'www' subdomain for HTTPS requests without the browser throwing up?
Heroku thinks not:
...applications requiring SSL encryption should use the ALIAS/ANAME configuration on the root domain. Subdomain redirection will cause a browser error when the root domain is requested over SSL (i.e. https://example.com).
...but I'm hoping that's an incomplete (or incorrect) statement.
CLARIFICATION UPDATE:
The real issue with redirecting from apex to 'www' is that typing https://example.com directly into a browser will raise a certificate warning. Sure, it's an edge case, but not a small one.
SOLUTION UPDATE:
I solved this problem with DNSimple. (Didn't even have to transfer my domain!)
I believe that easyDNS offers a similar feature, but surprised to find that most other domain hosting companies don't.
There are two separate but interdependent levels of indirection to consider here. The first is what IP address a DNS name ultimately resolves to. The second is what the server on that IP address does.
Remember that when you type a URL into a browser, the first thing that happens is a DNS lookup. Usually, that's handled by the operating system – not the browser itself.
So your browser will ask the OS, "what is the address of example.com?" The OS will look up the record, and if it gets a CNAME, will look up that record, until it finds an A record. The OS then responds to the browser with an answer.
Your browser then opens a TCP connection to that IP address:
If a http:// URL, it connects to port 80, then issues a HTTP request.
If a https:// URL, it connects to port 443, establishes a TLS/SSL connection (which means validating certificates), then issues a HTTP request over the secure channel.
Only at this point can HTTP redirection happen. The browser sends a request (GET /, and the server can respond with a 301 to any other URL.
Understand that "subdomain redirection" services offered by registrars are nothing more than a regular HTTP server that issues 301s. When you opt for a registrar's redirection option, they just set the A record of your domain's apex to a server they control, and that server tells browsers to go to www.example.com.
Since most registrars don't allow you upload a SSL certificate to their redirection server, browsers cannot establish the necessary secure connection to the server, and therefore they never issue a HTTP request. Thus, requests for https://example.com fail.
So why can't you just CNAME the apex? It is forbidden.
The domain system provides such a feature using the canonical name
(CNAME) RR [Record Resource]. 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.
The spec requires that a CNAME record be the only record for a given (sub)domain. This is at odds with the requirement of having a SOA record on the apex. (There are some efforts out there to change the specs to allow CNAME and SOA to coexist, but there are still many broken SMTP implementations that will be confused by the CNAME on a domain.)
You have the following options to get SSL working on the apex:
Use a third-party service that supports SSL on the redirect server. You'll likely pay for this. Here's one service. I would not recommend this route, since it takes the control of reliability out of your hands, and requires you to hand over the keys to your SSL certificate to someone who may or may not be trustworthy.
Run your own redirection server. Since the apex requires an A record, you'll need a static IP, which services like Heroku and AWS' ELB do not provide. So if you're in a cloud environment, it will be very difficult (if not impossible) to guarantee reliability. On the plus side, you retain control of your SSL keys.
Use a DNS host that allows you to set an alias. Point the alias to your Heroku domain/ELB/whatever. This is most likely the best option.
An alias is not technically a type of DNS record. Instead, it is a special configuration on the DNS host side that returns an A record from the result of another lookup. In other words:
Your OS issues a DNS request for example.com to your DNS host.
Your DNS host reads the internal alias configuration, and issues a DNS request for that domain. So if you have an alias set up for example.herokuapp.com, it would look up the A record of that domain.
The DNS host returns a simple A record with the IP(s) it got from the alias lookup.
With an alias record, you could point your apex to the same cloud load balancer that your www domain is CNAMEd to. Assuming you've set up SSL on the www domain, the naked domain will work just fine. At this point, it's your choice whether your app issues a redirect, or just serves your content directly over the naked domain.
You need a certificate that secures both www.example.com and example.com.
NOTE: I have not tried this with Heroku app.
I am still sharing this solution here as this is the first stackoverflow page that shows up for 'redirection from naked domain to www version' search. It may help others who are looking for an answer to generic redirection.
I have successfully redirected naked domain to www version.
In addition, I also redirected the HTTP version to HTTPS version using google domains DNS settings in synthetic records.
Delete any 'A' records for '#' in your DNS.
Add a synthetic record with subdomain = '#' and redirect it to www version of your website.
After addition, edit this same record and change the default 'http://www.example.com' to 'https://www.example.com' . Note the 's' in http here. Click Save.
That's it. Your redirection is now taken care of by DNS settings.
Detail steps are documented here:
https://www.am22tech.com/redirect-naked-domain-www-http-https-google-domains/
I already added a custom domain to my Heroku app and it works with www.domain.com.
I need to know how to set up the domain without www to resolve to the app, too.
Here are my current DNS settings:
$TTL 86400
# IN SOA ns1.first-ns.de. postmaster.robot.first-ns.de. (
2013041500 ; serial
14400 ; refresh
1800 ; retry
604800 ; expire
86400 ) ; minimum
# IN NS robotns3.second-ns.com.
# IN NS robotns2.second-ns.de.
# IN NS ns1.first-ns.de.
# IN A 88.198.38.XXX
localhost IN A 127.0.0.1
mail IN A 88.198.38.XXX
ftp IN CNAME www
imap IN CNAME www
loopback IN CNAME localhost
pop IN CNAME www
relay IN CNAME www
smtp IN CNAME www
www IN CNAME appname.herokuapp.com.
# IN MX 10 mail
What are the correct settings to use so that both example.com and www.example.com would point correctly to my Heroku app?
(Note: root, base, apex domains are all the same thing. Using interchangeably for google-foo.)
Traditionally, to point your apex domain you'd use an A record pointing to your server's IP. This solution doesn't scale and isn't viable for a cloud platform like Heroku, where multiple and frequently changing backends are responsible for responding to requests.
For subdomains (like www.example.com) you can use CNAME records pointing to your-app-name.herokuapp.com. From there on, Heroku manages the dynamic A records behind your-app-name.herokuapp.com so that they're always up-to-date. Unfortunately, the DNS specification does not allow CNAME records on the zone apex (the base domain). (For example, MX records would break as the CNAME would be followed to its target first.)
Back to root domains, the simple and generic solution is to not use them at all. As a fallback measure, some DNS providers offer to setup an HTTP redirect for you. In that case, set it up so that example.com is an HTTP redirect to www.example.com.
Some DNS providers have come forward with custom solutions that allow CNAME-like behavior on the zone apex. To my knowledge, we have DNSimple's ALIAS record and DNS Made Easy's ANAME record; both behave similarly.
Using those, you could setup your records as (using zonefile notation, even tho you'll probably do this on their web user interface):
# IN ALIAS your-app-name.herokuapp.com.
www IN CNAME your-app-name.herokuapp.com.
Remember # here is a shorthand for the root domain (example.com). Also mind you that the trailing dots are important, both in zonefiles, and some web user interfaces.
See also:
Doing DNS right with Heroku
Avoiding Naked Domains and DNS A-records
Remarks:
Amazon's Route 53 also has an ALIAS record type, but it's somewhat limited, in that it only works to point within AWS. At the moment I would not recommend using this for a Heroku setup.
Some people confuse DNS providers with domain name registrars, as there's a bit of overlap with companies offering both. Mind you that to switch your DNS over to one of the aforementioned providers, you only need to update your nameserver records with your current domain registrar. You do not need to transfer your domain registration.
To point your apex/root/naked domain at a Heroku-hosted application, you'll need to use a DNS provider who supports CNAME-like records (often referred to as ALIAS or ANAME records). Currently Heroku recommends:
ALIAS at DNSimple
ANAME at DNS Made Easy
ANAME at easyDNS
ALIAS at PointDNS
CNAME at CloudFlare
Whichever of those you choose, your record will look like the following:
Record: ALIAS or ANAME
Name: empty or #
Target: example.com.herokudns.com.
That's all you need.
However, it's not good for SEO to have both the www version and non-www version resolve. One should point to the other as the canonical URL. How you decide to do that depends on if you're using HTTPS or not. And if you're not, you probably should be as Heroku now handles SSL certificates for you automatically and for free for all applications running on paid dynos.
If you're not using HTTPS, you can just set up a 301 Redirect record with most DNS providers pointing name www to http://example.com.
If you are using HTTPS, you'll most likely need to handle the redirection at the application level. If you want to know why, check out these short and long explanations but basically since your DNS provider or other URL forwarding service doesn't have, and shouldn't have, your SSL certificate and private key, they can't respond to HTTPS requests for your domain.
To handle the redirects at the application level, you'll need to:
Add both your apex and www host names to the Heroku application (heroku domains:add example.com and heroku domains:add www.example.com)
Set up your SSL certificates
Point your apex domain record at Heroku using an ALIAS or ANAME record as described above
Add a CNAME record with name www pointing to www.example.com.herokudns.com.
And then in your application, 301 redirect any www requests to the non-www URL (here's an example of how to do it in Django)
Also in your application, you should probably redirect any HTTP requests to HTTPS (for example, in Django set SECURE_SSL_REDIRECT to True)
Check out this post from DNSimple for more.
I am now using Google Apps (for Email) and Heroku as web server. I am using Google Apps 301 Permanent Redirect feature to redirect the naked domain to WWW.your_domain.com
You can find the step-by-step instructions here
https://stackoverflow.com/a/20115583/1440255
You are not allowed to have a CNAME record for the domain, as the CNAME is an aliasing feature that covers all data types (regardless of whether the client looks for MX, NS or SOA records). CNAMEs also always refer to a new name, not an ip-address, so there are actually two errors in the single line
# IN CNAME 88.198.38.XXX
Changing that CNAME to an A record should make it work, provided the ip-address you use is the correct one for your Heroku app.
The only correct way in DNS to make a simple domain.com name work in the browser, is to point the domain to an IP-adress with an A record.