We assume here that an on-premises intranet user wants to use a service in the AWS cloud. The service has been made highly available by two services. A high availability service will point to the active and available service by changing the IP address in the Route53 naming service.

This page explains what needs to be done to allow on-premises service consumers to get an IP address from am Route53 service. Customers who implemented Microsoft Active Directory will have to follow this blog post. The remainder of this page will deal with DNS implementations.

The problem is, that Route53 is serving only EC2 instances in a VPC. It not exposing it's service back over the VPN tunnel to the intranet.

The solution for this problem are DNS forwarders called "bind forwarders". This page explains how to create such a bind forwarder. Users will actually want to create two bind forwarders in two different availability zones to avoid a single point of failure.

The final architecture will look as follows:

We will create two bind forwarders in two AWS Availabilty Zones. Corporate clients will submit their queries to the corporate DNS server. The corporate DNS server will then relay the requests to the bind forwarders. The bind forwarders will query Route53 for the final resolution. We assume the the VPC will operate in a separate subdomain of the intranet. This will simply the routing for the corporate DNS server. The diagram to the left shows how two application servers register or deregister themselves in Route53 win step 1 and 2. Step 3 to 5 shows how the name resolution request will be pulled from Route53. This page describes how a bind forwarder can be configured. We assume that the we have the following network topology: Intranet IP range: 10.0.0.0/8 Intranet domain: mycompany.corp AWS VPC IP range: 10.78.0.0/16 AWS VPC domainname: awslab.mycompany.corp IP address bind forwarder 1: 10.79.7.17 IP address bind forwarder 2: 10.79.8.17 Route53 IP address: 10.79.0.2 AWS regions: us-east-1

Creation of EC2 Instances

Create two EC instances. The T2 instance type is likely to be sufficient:

• Pick the two IP addresses from above. It'll be important that the subnets are located in different Availability Zones
• Pick Amazon Linux
• Use Security Groups with the following inbound settings
  • ssh, tcp, port 22 open to 10.0.0.0/8
  • DNS(UDP), port 53 open to 10.0.0.0/8
  • DNS(TCP), port 53 open to 10.0.0.0/8
• Use a certificate
• Disk requirements minimal

Configuration of the named Service

The named service is providing the task we need.

Login a ec2-user to the instance and execute the following commands:

sudo yum install bind

Install the packages required for the named services.

Create the file /etc/named.conf. You may use the vi editor:

sudo vi /etc/named.conf

replace the content of this file with this content:

acl goodclients {
   10.0.0.0/8;
   localhost;
   localnets;
};

options {
   directory "/var/named";
   version "not currently available";
   allow-query { goodclients; };
   forwarders {10.79.0.2;};
   forward only;
};

logging{
   channel simple_log {
   file "/var/log/named/bind.log" versions 3 size 5m;
   severity warning;
   print-time yes;
   print-severity yes;
   print-category yes;
   };
   category default{
      simple_log;
   };
   category client{
      simple_log;
   };
};

zone "us-east-1.compute.internal" IN {
   type forward;
   forwarders {10.79.0.2;};
};

zone "awslab.mycompany.corp." IN {
   type forward;
   forwarders {10.79.0.2;};
};

Change all network specific values (bold) with the ones which match your configuration.

Create a log File for named Service

sudo mkdir /var/log/named
sudo touch /var/log/named/bind.log
sudo chmod ug+w bind.log

Start the Service

Execute the command:

sudo service named start

Make the service permanent and have it started after a reboot:

sudo chkconfig named on

Perform this setup for both of your EC2 instances.