Propagating the Name Change back to the On-Premises Intranet
Propagating the Name Change back to the On-Premises IntranetWe 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.
AWS now provides the service Route 53 Resolvers for Hybrid Clouds which solves this problem. |
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:
|
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.
- 3164 views