Need to move your existing website to a new domain or TLD? Are you migrating from HTTP to HTTPS and #$&@ keeps breaking? No matter the case. If you have ever considered setting up your redirects at the DNS level… this article will answer every question you could ever have.
Important note: No, you cannot redirect HTTP to HTTPS at the DNS level. This is something you have to configure on your web server (because it manages the protocol). If you don’t have access to your web server, you will need to contact your web hosting provider.
What is a DNS redirect?
A redirect is an HTTP response with a 301 status code and the new location. It looks something like this:
>>> https://vercara.digicert.com > -------------------------------------------- > 301 Moved Permanently > -------------------------------------------- Status: 301 Moved Permanently Code: 301 Server: nginx/1.10.3 (Ubuntu) Date: Wed, 01 Aug 2018 22:11:33 GMT Content-Type: text/html Content-Length: 194 Connection: close Location: https://constellix.com/
Redirects are commonly used to tell website visitors and search engines which URL is the one you want them to see. In this case, we want our users to only visit the HTTPS version of our website. The 301 simply tells users that https://constellix.com is the intended destination for our website.
Since HTTPS is now a standard for all websites, it’s become more important than ever to redirect traffic to the HTTPS version of a website. Recently, browsers like Google Chrome are showing “nonsecure” badges for websites still running over HTTP.
Keep in mind that for a lot of the examples in this article, there is more than one way to create the redirect. Like in the previous example, you can set up a redirect on your web server to automatically send all traffic to the HTTPS version of the site, no matter what page they are visiting. You can also do it at the DNS level using an HTTP redirection record (we’ll talk more about this in a minute).
There are other kinds of “redirects” at the DNS level, but they don’t operate over HTTP or HTTPS protocols. Instead, they are records that point one hostname or IP to another.
How about when www. disappeared from the beginning of URL’s? All it takes is a simple CNAME record and you can redirect all traffic hitting www. to go to the “naked” version of your domain, like example.com.
Go ahead and try it! Prepend www. to an address and see where you end up.
>>> https://www.constellix.com > -------------------------------------------- > 301 Moved Permanently > -------------------------------------------- Status: 301 Moved Permanently Code: 301 Server: nginx/1.10.3 (Ubuntu) Date: Thu, 02 Aug 2018 17:56:53 GMT Content-Type: text/html Content-Length: 194 Connection: close Location: https://vercara.digicert.com/
You can also test for redirects to HTTPS by prepending http:// to a URL.
DNS Redirects
So, how are regular DNS records like A and CNAME different from HTTP redirects?
DNS records are confined to redirects within the same FQDN (Fully Qualified Domain Name) or zone.
For example:
I own www.mydomain.com and I want to point it to blog.mydomain.com. I CAN do that with a CNAME record.
Okay, but what if I own mydomain.com and I want to redirect it to myfriendsdomain.com? I would have to use an HTTP redirect since the second hostname is not one in my current zone.
HTTP redirects operate very differently from traditional DNS records. That’s because they require the help of a dedicated web server to store all of the redirects.
When you create an HTTP redirection record, you’re actually making an A record that points to that web server. The web server will respond with a 301 redirect and the destination URL.
How HTTP Redirects Work
But this is only one step in the lookup process. To better understand how HTTP redirects work, we need to go back to the very beginning.
When you enter a website into your browser, what happens?
Your browser checks to see if it has a cached version of the website.
It realizes it doesn’t, so it starts a DNS query. Your browser asks the resolver (usually your ISP) if they have the DNS information for the domain.
The resolver asks the root nameservers for the DNS information.
The root nameservers ask the appropriate TLD (Top Level Domain) nameservers, who then ask the authoritative nameserver (who hosts the DNS for the domain).
The authoritative nameserver answers with the IP address in the DNS record for that domain (and subdomain, if appropriate). The other nameservers and servers pass back the information to the browser.
The browser connects to the IP address specified in the DNS record, which is the web server for that website.
What happens here is a sort of handshake.
If the browser made the request over HTTP and the web server is not encrypted by HTTPS, then the web server will answer with an HTTP response and the website content.
If the browser made the request over HTTP and the web server IS encrypted with HTTPS, then it will answer with an HTTP response and the website content, but over an insecure connection.
In Chrome, the browser will alert the user that the website is not secure.
If the browser made the request over HTTPS and the web server IS encrypted, then it will answer with an HTTP response over a SECURE connection.
Problems with HTTPS Redirects
What does this have to do with redirection? Everything. If you are querying a domain that isn’t secure (over HTTP) but redirects to a secure domain (HTTPS), the handshake will never take place.
That’s because web servers that host secured domains also have to be secure.
Both domains in a redirect must have SSL certs. That means you can’t redirect an HTTPS site to an unsecured one.
A lot of SysAdmins run into this kind of issue, and there are a few reasons why.
In most cases, you may not have purchased an SSL certificate (which allows you to run over HTTPS), but if you use a CDN, your website could still be running over HTTPS. That’s because most CDN services will automatically create an SSL certificate for your domain when you add your domain to their network.
Let’s go back to what happens when you enter a website into a browser, but this time the website we are looking for uses HTTPS.
User and web server exchange certificate information and keys to create a secure connection. AKA: the handshake.
Then, the browser sends the HTTP request (which is encrypted) and provokes an HTTP response from the web server.
an HTTPS request is exactly an HTTP request but transmitted over a secure (TLS/SSL) connection
The web server encrypts the HTTP response and sends it to the client’s browser.
Now when a redirect happens, we still go through the first two steps. However, the server will respond with the redirect code and location over a secure connection.
Bottom line. If you want to redirect a secure hostname to anything (secure or not)… then you must have a valid SSL certificate on the web server that the hostname is hosted. Otherwise, you’ll fail at step one.
Kinds of HTTP redirection
Okay, now that we have all of that out of the way. What kinds of HTTP/HTTPS redirects can you do with DNS?
- Permanent Redirect (301): Exactly what it says. This is the standard for most redirects.
- Temporary Redirect (302): Tells search engines that you may change it later, so they should check again.
- Hidden Frame Redirect: This kind of redirect actually creates a “framed” experience in the browser. The user will see the original URL in their browser but will see the content from the destination URL.
What is a Hard Link?
You can also configure a hidden frame redirect to not include the path the user entered into their browser.
For example:
Say a user enters www.domain.com/my-blog into their browser
You have a hidden frame redirect set up that will show the original URL in their browser but show the content for www.notmydomain.com.
A hard link will remove the path “my-blog” from the end of the URL and not append it to www.notmydomain.com.
Meta Tags
You also have the option to configure the meta tags for the framed page.
Why HTTP redirect?
Remember, don’t try to use an HTTP redirection record to redirect HTTP to HTTPS. Only use HTTP redirection records to point an FQDN to another FQDN.
How Vercara UltraDNS Can Help
Vercara UltraDNS simplifies and enhances DNS-based redirection with reliable, high-performance HTTP redirection capabilities. By leveraging UltraDNS, businesses can ensure seamless domain migrations, efficient URL restructuring, and optimized traffic management without disruptions. UltraDNS provides secure and scalable redirection services, helping organizations maintain website availability while avoiding misconfigurations that can impact performance or security. With built-in redundancy and advanced DNS management, UltraDNS enables effortless implementation of 301 and 302 redirects at the DNS level, ensuring a smooth user experience. Whether managing multiple domains, migrating websites, or optimizing traffic flow, UltraDNS offers the flexibility and security needed for modern digital infrastructure.
