HTTPS redirect from root domain (i.e. apex or 'naked') to 'www' subdomain without browser throwing up?

Question

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.

Answer 1

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:

1. Your OS issues a DNS request for example.com to your DNS host.
2. 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.
3. 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.