DNS Redirects and URL Forwarding

DNS redirects and URL forwarding are techniques to send visitors from one domain or URL to another. While DNS itself doesn't perform HTTP redirects, several DNS-related methods can achieve the same result. Understanding the options helps you choose the right approach.

DNS Redirect vs. HTTP Redirect

It's important to understand that DNS and HTTP redirects work at different layers:

DNS alone cannot change the URL in a browser's address bar. For that, you need an HTTP redirect served by a web server. This distinction is critical: DNS resolves names to addresses, while HTTP redirects tell browsers to request a different URL.

Method 1: CNAME Records (DNS-Level Alias)

A CNAME record points one domain to another at the DNS level:

blog.example.com.  3600  CNAME  example.com.

When someone visits blog.example.com, DNS resolves it to example.com's IP address. The browser connects to that IP, but the URL bar still shows blog.example.com. The web server at the destination must be configured to accept requests for both hostnames.

When to Use CNAME

• Pointing subdomains to cloud services (app.example.com to myapp.herokuapp.com)
• Pointing www to the apex domain
• When you don't need the URL to change in the browser

Limitations

• Doesn't work at the apex domain (use ALIAS instead)
• The URL in the browser doesn't change
• Cannot redirect to a specific path (e.g., can't redirect to example.com/blog)
• Cannot coexist with other record types at the same name

For a deeper comparison, see CNAME vs A Record.

Method 2: HTTP 301 Redirect (Permanent)

A 301 redirect tells browsers and search engines that a page has permanently moved to a new URL:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

Browsers cache 301 redirects aggressively. Once a browser sees a 301, it may remember the redirect indefinitely and go directly to the new URL on subsequent visits without contacting the original server. This makes 301 redirects very efficient for permanent moves but difficult to reverse if you make a mistake.

Example: Redirect Non-WWW to WWW

Nginx:

server {
    listen 80;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

When to Use 301

• Permanently moving a site to a new domain
• Consolidating http:// to https://
• Redirecting example.com to www.example.com (or vice versa)
• Migrating from an old URL structure to a new one

SEO Impact

301 redirects pass most link equity (SEO value) to the new URL. Search engines will eventually update their index to show the new URL. This is the recommended method for domain migrations when you want search rankings to transfer to the new domain.

Method 3: HTTP 302 Redirect (Temporary)

A 302 redirect indicates a temporary move:

HTTP/1.1 302 Found
Location: https://maintenance.example.com/

Unlike 301 redirects, browsers do not cache 302 redirects permanently. Each visit checks the original URL, so the redirect can be removed at any time and visitors will immediately see the original content.

When to Use 302

• Temporary maintenance pages
• A/B testing different URLs
• Geolocation-based routing to different content
• Any redirect that might be reversed in the future

SEO Impact

302 redirects tell search engines to keep the original URL in their index, since the redirect is temporary. Use 302 when you intend to bring the original URL back.

307 and 308: Modern Alternatives

HTTP/1.1 also defines 307 (Temporary Redirect) and 308 (Permanent Redirect). These behave like 302 and 301 respectively, but explicitly preserve the HTTP method. If a POST request hits a 301 or 302, some browsers may change it to GET. A 307 or 308 guarantees the method is preserved, which matters for API redirects and form submissions.

Method 4: HTTPS Record (DNS-Level)

The newer HTTPS record type can signal to browsers that a domain supports HTTPS, eliminating the need for an HTTP-to-HTTPS redirect:

example.com.  3600  IN  HTTPS  1 . alpn="h2,h3"

This doesn't replace HTTP redirects but reduces the latency of the initial HTTP to HTTPS upgrade for supporting browsers. Combined with the SVCB record, it provides a DNS-native way to advertise service endpoints.

Method 5: ALIAS Records for Apex Domains

When you need CNAME-like behavior at the apex domain, an ALIAS record resolves the target hostname server-side and returns the resulting IP addresses:

example.com.  3600  ALIAS  myapp.herokuapp.com.

This is not a redirect -- the browser still sees example.com in the URL bar -- but it solves the apex domain problem without requiring a static IP address. DNScale supports ALIAS records natively.

Common Redirect Scenarios

Redirect HTTP to HTTPS

DNS setup (point both to the same server):

example.com.      3600  A  192.0.2.1
www.example.com.  3600  A  192.0.2.1

Web server handles the redirect:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

For additional HTTPS security, consider setting up SSL/TLS certificates and publishing CAA records to control which certificate authorities can issue certificates for your domain.

Redirect Apex to WWW

DNS setup:

example.com.      3600  A      192.0.2.1
www.example.com.  3600  CNAME  myapp.example.com.

Web server on 192.0.2.1:

server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

Redirect Old Domain to New Domain

DNS setup (old domain points to a redirect server):

olddomain.com.      3600  A  192.0.2.99
www.olddomain.com.  3600  A  192.0.2.99

Redirect server:

server {
    listen 443 ssl;
    server_name olddomain.com www.olddomain.com;
    return 301 https://newdomain.com$request_uri;
}

When migrating domains, lower the TTL on the old domain's DNS records before the switch. This ensures the redirect takes effect quickly. See DNS propagation for timing details.

Redirect Subdomain to External Service

DNS setup:

docs.example.com.  3600  CNAME  example.gitbook.io.

No redirect needed -- the CNAME handles it at the DNS level. The content is served from GitBook but accessed via your subdomain. The destination server must accept requests for docs.example.com and present a valid SSL certificate for that hostname.

Email and Redirect Interactions

Be careful when redirecting domains that also handle email. MX records must remain functional at the domain level. If you use a CNAME at the apex for redirection purposes (which is technically invalid but some providers allow), it will break MX, TXT, and NS records at that name. Always use A records or ALIAS records at the apex if you need email delivery to work alongside redirects.

301 vs. 302 vs. CNAME: Decision Guide

Setting Up DNS for Redirects in DNScale

For most redirect scenarios, you need DNS records pointing to the server that will issue the HTTP redirect.

Using the Dashboard

1. Navigate to your zone in DNScale
2. Add an A record pointing to your redirect server's IP
3. Or add a CNAME record pointing to the destination domain (for subdomain aliases)

Using the API

# Point the domain to your redirect server
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "A",
    "content": "192.0.2.99",
    "ttl": 3600
  }'

Verifying Redirects

After configuring DNS and your web server, verify that redirects work correctly:

# Check the HTTP response code and Location header
curl -I http://example.com
 
# Follow redirects and show each step
curl -vL http://example.com 2>&1 | grep -E "< HTTP|< Location"
 
# Verify DNS is pointing to the correct server
dig +short example.com @ns1.dnscale.eu

Related Topics

• CNAME Records Explained -- how CNAME aliases work
• CNAME vs A Record -- choosing the right record type
• What Is an ALIAS Record -- CNAME-like behavior at the apex
• What Is an HTTPS Record -- signal HTTPS support via DNS
• DNS Propagation Explained -- why redirect changes take time
• SSL/TLS Certificates -- secure your redirect endpoints with HTTPS

Conclusion

DNS records and HTTP redirects work together to route users to the right destination. Use CNAME for subdomain aliases where the URL doesn't need to change, and HTTP 301/302 redirects for permanent or temporary URL changes. For apex domain aliasing, ALIAS records provide a clean solution. DNScale makes it easy to configure the DNS side -- just point your records to the right servers and let your web server handle the redirect logic.