What about… moving to the cloud?
It all started more than five years ago, using SugarCRM for managing customer relationships.
Then it was immediately time to migrate to Google Apps from the dodgy local mail server sitting inside the office on a dark corner.
After that, it was the turn of the accounting software: Saasu, an online accounting suite.
I have decided I’m now over maintaining multiple Name Servers around the world, and I just need something I do not need to worry much about.
Something with the infrastructure-as-a-service model.
Now it is the turn of my DNS to be cloud based.
Introduction
I am going to show you how to migrate your BIND server files to Amazon Route 53 cloud DNS service.
Unfortunately it seems like Route 53 does not currently have a ‘mass update’ functionality or even an ‘importing’ functionality from the GUI.
That means we will have to interact with the API provided by Amazon to be able to migrate our BIND zone files.
Getting started
First of all, let’s assume you are migrating just the DNS for the domain “mycooldomain.com”.
Of course, before getting started, you will have to have an Amazon Web Services account ready to go.
At this point I would expect you to create the zone entry for the domain “mycooldomain.com” through the Amazon’s web interface, and get back the unique zone id that Amazon’s assigns to the domain itself.
From now on, let’s call the zone id MYZONEID.
At this point we need a couple of PERL scripts that will help us with this migration. Those scripts are actually available on the tools that Amazon provides.
The first script will process the data:
wget http://awsmedia.s3.amazonaws.com/catalog/attachments/bindtoroute53.pl
This allows us to format the data from a normal BIND zone file to the XML format that Amazon’s API requires.
The second script will post the previously formatted XML data to Amazon’s web services:
wget http://awsmedia.s3.amazonaws.com/catalog/attachments/dnscurl.pl
To be able to run the above scripts, I had to install a couple of components with CPAN:
install Net::DNS
notest force install Net::DNS::ZoneFile
You will probably have to play around with this to get it working. It all depends on your local Linux installation and configuration.
Data transformation
The command to execute, to be able to read and export your current BIND zone file would look something like:
./bindtoroute53.pl --ignore-origin-ns --ignore-soa --origin mycooldomain.com < /path/of/zones/mycooldomain.com.zone > /path/of/amazon/export/amazon_mycooldomain.com.xml
The above command will produce the file “amazon_mycooldomain.com.xml” that will be our input file, that we will be using for Amazon’s API.
We then have to create the file “~/.aws-secrets” with correct file permissions (chmod 600 ~/.aws-secrets), containing your Amazon Web Services credentials in the following format:
%awsSecretAccessKeys = (
'work' => {
id => 'myAmazonid',
key => 'myAmazonkey',
},
);
Let’s test the API to see if it connects properly and if it retrieves the zone information:
./dnscurl.pl --keyname work -- https://route53.amazonaws.com/2010-10-01/hostedzone/MYZONEID
If we get a valid response, we can proceed further with the migration.
Migration
Before migrating your DNS entries, you probably should know that Amazon allows at most 100 DNS entries created for each API call.
If you have to migrate more than 100 records, you will have to split the XML files accordingly.
Now you are ready to do the actual migration with the command:
./dnscurl.pl --keyname work -- -H "Content-Type: text/xml; charset=UTF-8" -X POST --upload-file /path/of/amazon/export/amazon_mycooldomain.com.xml https://route53.amazonaws.com/2010-10-01/hostedzone/MYZONEID/rrset
Double check the result, either with Amazon’s GUI or with “dnscurl.pl” to retrieve the DNS entries for a specific zone, and output the result to a file:
./dnscurl.pl --keyname work -- https://route53.amazonaws.com/2010-10-01/hostedzone/MYZONEID/rrset > /path/to/output/mycooldomain.com_saved.xml
Going live
How do we verify if it all worked, before completing the migration?
Well you will have to get the list of Name Servers that Amazon assigned to “mycooldomain.com” (let’s call it AMAZON_NS_X) from the GUI and then use the Linux command “dig” to verify the responses from those Name Servers:
dig @AMAZON_NS_X subdomain.mycooldomain.com
If the response is the same as the one with the current Name Servers:
dig subdomain.mycooldomain.com
then we are ready to go, and we can push the change live.
To actually push the change live, we have to modify our Name Server list on the domain’s registrar, to point to Amazon’s Name Servers instead of the current ones.
Once the Name Servers are applied, you will be running your DNS in the cloud.
One step closer to be fully cloud based!