Skip to Content
Author's profile photo Chris Kernaghan

ElasticIp addresses wrong – Dynamic DNS good

This post has been cooking for a while, and goes with the 4 part series John Moy and Sascha Wenninger have completed on Installing NetWeaver Gateway in the AWS Cloud. As I have been working in the Amazon cloud I have been working on larger and larger landscapes, but never really moving above the magic 10 or 11 hosts needing static IP addresses. This means that I can request the AWS increase my allowance of 5 ElasticIp addresses to 10 without really getting into too much grief, although over time I have known that this is a short road to nowhere and I would need a better solution. Route53 to the rescue, last year AWS released Route53, their own homegrown DNS service, and all seemed right with the world – well except for the fact that it had been a very long time since I had configured DNS, there were no GUI tools for it and I was too busy to learn it since I was in the middle of an upgrade project. So I soldiered on using ElasticIp addresses, for no better reason than I was being lazy and it was easy.

Now that I have had some time to do some more digging and maintenance on my AWS landscape, I have found a nice and simple way of configuring the DNS on my servers to use Route53 and to allow me to stop using IP addresses or hosts files and use the correct tools for server addressing.

  • The 1st thing that is required is that you must have a purchased domain – 

(Side Story : I do not have a recommendation on a registrar but the one thing I would look for in any small print is who actually owns the domain once the initial term is up – there was a number of high profile cases where the company bought a domain through a registrar, built a good reputation over a few years and then wanted to transfer the domain. The registrar refused to let the company transfer the domain, because the registrar had actually bought the domain – they let the company lease it until it became valuable and then tried to sell it to the company at an inflated profit.)

  • Once you have your domain, then you need to sign up to Route53, a simple task if you are already an EC2 user
  • From the AWS Web console it is now possible to create a HostedZone


  • Once the Hosted zone is created it will create a Unique Id for the zone and a number of service records


(Hosted zone console details)


(Hosted zone full details)


(Hosted zone service records)

Now we have our hosted zone and the capability to put records into Route53, we just need a way to populate it with records and this is different obviously depending on whether you use Windows or Linux.The trick is to have the host update it’s DNS once it starts up, as AWS EC2 is based on hourly billing, most sensible people do not have their servers running 24*7 – so they shut them down when not in use. The annoying part is that when they start up again, they have a different IP address, the instructions below will detail how it works.

Linux – CentOs, RedHat, AmazonLinux

This part of the post is something I cannot claim total credit for, at most 30%, the rest belongs to Simon McCartney (He is a great guy, excellent #DevOp, and general font of useful information) – there are 5 components to this solutions

1. – this is a perl script which will work enumerate Route53 services

     It is advisable to use the following commands to ensure you have all the required software at the right version

               sudo yum install perl-Digest-HMAC

               sudo yum install perl-XML-XPath

2. .aws-secrets file – this file holds your AWS Keys, the location is specified in the file

3. route53DynDNS.bash – this is the base script which use the DNSCurl perl script to set the hostname and IP records in Route53

4. Startup script – rd.local file is used to run scripts upon startup


Windows – to be honest, this is much simpler

I used the application Route53DDNS which I found on GitHub – in this you set the Fully Qualified Hostname of the server


Also the AWS credentials


In order to get it running once the system starts a scheduled task needs to be set up so that it runs once the system starts and without a user logging on


Once you have this set up then the system (Windows or Linux) will update the Route53 accordingly and you will be able to use DNS to administrate your connections much more effectively. The only wrinkle that I forsee is the AWS Firewall and it’s configuration, I suspect that I am going to have to do something script based to ensure that inter-server communication through the firewall is kept open and easy – but that’s for another post I fear.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sascha Wenninger
      Sascha Wenninger

      Hi Chris,

      thank you very much for sharing that solution! It does seem like a better (more sustainable and also simpler) option than using Elastic IPs like I wrote about. We already use Route 53 for our AWS instance as it seems to be a pretty good service, and this approach will let us get a little more value out of it still (plus, I love the 30+ DNS servers scattered around the globe for  zippy DNS performance).

      Thanks for sharing!


      Author's profile photo Chris Kernaghan
      Chris Kernaghan
      Blog Post Author

      Thanks, sorry it took a few more days than anticipated to get it up here 🙂


      Author's profile photo Martin English
      Martin English

      nice explanation of the need for these techniques, and some useful tools. I've been tinkering with other tools to do my Route53 stuff, but this looks a hell of a lot simpler !!


      Author's profile photo Martin English
      Martin English

      Serendipity strikes again 🙂

      For automated starting and stopping of your SAP system and DBMS (and anything else you have running like the oracle tnslsnr) when you reboot your *nix server, look at Start/Stop SAP along with your Unix Server Start/Stop


      Author's profile photo Chris Kernaghan
      Chris Kernaghan
      Blog Post Author

      I saw that post yesterday and thought it looked interesting - especially when a lot of Unix environments run with silo'd teams, that restart on reboot would speed up the process.

      The only wrinkle I see in it, is that it does not have any error handling, what if the database got corrupted because it was an uncommanded shutdown - Oracle is not very good at automatically picking itself up off the floor. Would prefer to see some notifications coming out from the script to ensure the automatic startup does not make things worse.

      I have used automatic startups on my EC2 environment for Windows/SQL Server/SAP, it works very well as SQL Server is really controlled by the O/S services.


      Author's profile photo Ian Daniel
      Ian Daniel

      Hi Chris,

      This is exactly what I want to achieve, so thanks for sharing. I've made some progress and I can find a downloadable exe for the program here

      And I've got it running on my EC2 instance.

      In the domain name field, I put in

      In terms of the networking setup I think I'm missing something, I put an elastic IP address into Route53 as an A record:

      EIP <--

      The log of Route53DNS seems to suggest it has picked it up and it looks like it works - got an OK at the end of it.

      The bit I don't get is I seem to need one EIP per server, which is the limitation we're trying to avoid - what am I doing wrong?