With the recent announcement from Google that they are selling their Domains business to Squarespace, many Google Domains customers are looking for alternatives. One popular alternative is AWS Route 53 due to their relatively low cost and large feature set. We have documented the process of moving from Google Domains to Route 53 for several popular use cases.
Moving Domain Service
To avoid interruptions in domain service (and traffic to your site) be sure to move your domain service prior to changing your registrar from Google Domains to Route 53. As soon as you migrate your domain registration away from Google Domains, they will stop their name servers from responding for your domain so it is important that the name servers associated with your domain are migrated first. If you are simply "parking" a domain, you can skip these steps and go directly to moving your domain registration (see below).
The steps to move your domain service for a domain are as follows:
1. Log in to your AWS console with the account you plan to use for administering your domains
2. Go to the Route 53 service console and create a new "Hosted Zone" for your domain (e.g. example.com). This will create 4 NS records similar to ns-513.awsdns-00.net, ns-1963.awsdns-53.co.uk etc.
3. Create the required DNS records (CNAME, A, MX, etc.) as required by your domain matching those found in your current Google Domains configuration
4. Back in Google Domains, create Custom name servers as described here with the AWS name servers from Route 53 (the values of the NS records)
5. Wait until the name servers have been updated. You can check the name servers associated with your domain using the 'whois' command (e.g. whois example.com).
Moving your Domain Registration from Google Domains to Route 53
Once you are satisfied that your name servers have been transferred over to Route 53 you can go ahead and move your domain registration. The steps are as follows:
1. Log in to your Google Domains account and your AWS console
2. In Google Domains, unlock your domain and turn off domain privacy
3. Get an authorization code from Google
4. In Route 53, request domain transfer using the authorization code from Google
5. Check for a couple of emails from both Google and AWS to confirm the transfer
URL Redirection with AWS
If you are using your domains to redirect traffic from one domain to another (something that was simple in Google Domains, see here) you will need to follow these additional steps in AWS:
1. Request a certificate in the AWS Certificate Manager (instructions can be found here). Make sure to request the certificate from the region 'East (N. Virginia) Region (us-east-1)' and that your certificate includes all necessary domains and subdomains (for example, example.com, www.example.com, *.example.com etc.)
2. Set up a S3 bucket for the domain you need to forward traffic from (e.g. example.com).
3. Go to the example.com S3 bucket under properties, scroll all the way down to enable static web hosting (note: the S3 bucket endpoint is generated by AWS)
4. Click the 'Edit' button to enable static web hosting and set redirect requests for an object providing the host name (e.g. redirect example.com to omg.com/example):
5. Create a CloudFront distribution for example.com and follow these steps:
a. CName should include both www.example.com and example.com
b. Select the cert you created in step 1 (you will get an error if you pick a cert that is created in a region other than US-East-1).
c. Using the example.com S3 bucket as the origin (it should be in the drop-down if the S3 bucket is set up correctly).
d. Edit behavior to redirect http to https:
Since this set-up is redirecting traffic to another AWS S3 static hosting, you do not need to configure PolicyForCloudFrontPrivateContent under bucket permissions in S3.
Troubleshooting Steps
1. Check all your emails making sure there are no pending confirmations
2. Run the 'whois' command to check the name servers associated with your domain. At the bottom of the output you should see the name servers listed something like this:
Name Server: ns2.amzndns.net
Name Server: ns1.amzndns.com
Name Server: ns2.amzndns.com
Name Server: ns1.amzndns.net
If the name servers listed are not from AWS then your registration may not be complete.
3. Use the 'dig' command to check if your domain is being translated by various name servers. It should be installed by default on macOS and Linux but you may need to install it on Windows if it's not already installed. Either download and install BIND from here or use your favorite method to install software.
a. First run 'dig example.com' to see if your default name server knows how to translate your domain.
b. If your default name server can't find your domain, run 'dig example.com @8.8.8.8' to see if Google's public domain server can find your domain.
c. If the above attempts come back with errors try running 'dig example.com @AMZNDNS' where AMZNDNS is one of the name servers listed form the 'whois' command above
If the AWS name servers are translating your domain but the public name servers are not, there may be something preventing your domain from "propagating" (such as a DNSSEC configuration error, see below).
4. For URL forwarding within AWS, check the CloudFront distribution URL making sure the redirect is working and your server is responding
Check DNSSEC Status in Route 53 for the following:
Check both your "Hosted Zone" and "Registered Domains" entries in Route 53 making sure the configuration statuses match. If the DNSSEC settings do not match your domain will not 'propagate' from the AWS domain servers and you may see "SERVFAIL" responses from dig.
Comments
Post a Comment