Fixing URL-based Redirect Errors for AWS Route 53 and S3

Many of the typical DNS providers offer what we call URL-based redirects. This is something where a 301 HTTP response is applied to the DNS query and an answer of a new DNS name is sent back in order to forward you to the new URL.

This is not something that is natively available in AWS Route 53, but I’ve written about the solution here in the past where we can use S3 buckets and the website hosting and redirection option. The flow that the client will see is:

request URL (e.g. gcondemand.io)

DNS responds with record from Route 53 with an S3 alias

S3 redirects to the new URL using HTTP 301 response

Domains No Longer Forwarding using Route 53 and S3

The only challenge comes when you set up a domain on Route 53 and you are asked which DNS servers are the authoritative NS records to inject. New zones work automatically by injecting AWS name servers which will be dynamic within the AWS environment.

When a zone is transferred, the question will be presented if you want to keep your existing NS settings from the original registrar or if you want to specify your own NS settings which means setting up some NS records that you assume are all good. Here’s the trick: your NS records must contain the same entry as the SOA (Start of Authority) or else bad things will happen in time.

This is an example of a domain that was transferred over, given NS entries, and worked for quite a while. Suddenly, this is what will happen:

But, it worked for a while…

DNS is a magical thing (spoiler: it’s not really magic), and will work for quite a while as the internet continues to dynamically find your zone redirect on the previous name servers. At some point, you will bump into the issue where the records will age out on other servers and when downstream DNS servers go hunting for your records, the zone is pointing to differing NS records.

Fixing your Simple Redirects using Route 53 and S3

Fire up your Route 53 console, choose your hosted zone, and then select the Go To Record Sets button to edit the zone.

You can see by our entries here that we have a mismatch from the SOA and the NS records:

That will fix the first issue of the mismatched NS records and the SOA being different:

For the second part of the fix, go to the Registered Domains section in the Route 53 console, and select the Add or Edit Name Servers section under your zone.

Now, make sure to replace the four records with the matching set of four NS records you’ve used within the Hosted Zone section:

That will get you all sorted out. Don’t forget that DNS is a cached both locally and on remote DNS servers, so it may take up to 5-15 minutes for your local cache to expire and it may take up to a few hours for the remote entries to become corrected.