Tag Archives: route53

Configuring Route53 and ELB on Amazon EC2

25 Aug

Introduction

  • UPDATE: It’s now been determined that Route53 is not a good solution for Private IP/DNS records such as the ones used for Postgres, MYSQL, REDIS etc.
    See https://forums.aws.amazon.com/thread.jspa?threadID=62864 for more information. The only alternative now is to use startup (/etc/init.d)
    scripts to update configuration and/or /etc/hosts files on Apache instances to set the private DNS/IP addresses of Postgres, Redis etc.

This wiki page covers installation and configuration of the Route 53 DNS service and Elastic Load Balancing services.

Route 53 and Elastic Load Balancing (ELB)

  • Amazon EC2 instances don’t have static IP and DNS names assigned to them
  • Every time you stop/start an instance we lose the IP address assigned to that instance
  • Several configuration files such as Config.php, pg_hba.conf etc need to be configured with an IP address or hostname.
  • Route 53 is an Amazon EC2 DNS service we can use to map user friendly DNS names to the various EC2 instances
  • However, Route 53 by itself doesn’t resolve the issue of static IP/DNS names as it’s doesn’t assign IP addresses to EC2 instances.
  • ELB can be used to load balance EC2 instances and we get a static DNS name for the each load balancer in the process

Setup Elastic Load Balancing (ELB)

ELB introduction

Creating a Load Balancer

  • Follow the instructions on the Create Load Balancer wizard to assign create and assign instances to the Load Balancer.

Security Settings

  • After creating the Load Balancer you will have to update the Security group for each corresponding instance. This is required so that inbound connection from the load balancer to the instance can bypass the firewall.
  • You’ll need the Load Balancer owner alias and load balancer security group ID. These can be found on the Load Balancer Description tab.
  • Add the owner alias/security group id, for example amazon-elb/amazon-elb-sg to the Inbound Security Group settings for the corresponding instance.

Route 53

  • Amazon Route 53 is a Domain Name System (DNS) web service.
  • DNS records are organized into “hosted zones” that you configure with Route 53’s API.
    • For example, the top-level domains abc.com, abc.com and abc.net would EACH be a hosted zone on Route53.
  • When you create a hosted zone you will get a list of name servers for your hosted zone. You will have inform the registrar (godaddy, network solutions etc) with whom you registered your domain name to update the name servers for your domain to the ones associated with your hosted zone.
  • You can add, delete or change records in each hosted zone.
    • For example, we could create a record that maps the subdomain http://www.abc.com to the application server load balancer appserver-load-balancer.us-east-1.elb.amazonaws.com
    • We can also create records that map wildcard subdomain names
    • For example, a record *.abc.com that points to appserver-load-balancer.us-east-1.elb.amazonaws.com

Configuring Route53 using a GUI

  • There are several third-party Route 53 GUI tools available. I used https://www.interstate53.com/
    and it was a solid, easy to use interface. No CLI. No XML.

Configuring Route53 using the Amazon Perl Curl Tool and XML

DNS Alias Mapping for EC2 Loadbalancers

CNAME aliases vs Alias to ELB

  • There are 2 types of “alias record types” that can be created on Route53
    • CNAME aliases where you map one domain name to another
    • Alias to ELB where you map a domain name to a ELB name
  • For our app, we are using Alias to ELB mapping

Postgres pg_hba.conf configuration file and reverse DNS issue

  • We are unable to specify hostnames in the pg_hba.conf file and will use 0.0.0.0 allowing all IPs.
  • This is not a security hole and is discussed below.
The issue is related to the way Postgres performs reverse dns lookups on the hostname specified in the pg_hba.con file. Here is a snippet for the docs:
http://developer.postgresql.org/pgdocs/postgres/auth-pg-hba-conf.html 
-----
If a host name is specified (anything that is not an IP address or a special key word is processed as a potential host name), that name is compared with the result of a reverse name resolution of the client's IP address (e.g., reverse DNS lookup, if DNS is used). Host name comparisons are case insensitive. If there is a match, then a forward name resolution (e.g., forward DNS lookup) is performed on the host name to check whether any of the addresses it resolves to are equal to the client's IP address. If both directions match, then the entry is considered to match.
------

To simulate the reverse and forward dns lookups I used the "dig" network utility.

So while performing the reverse dns lookup the external/Publc IP is returned. But while doing the forward DNS lookup the internal/Private DNS name is returned. Which leads to the mismatch of the DNS names and Postgres marks the hostname resolution as failure. This error is very unique to the way Postgres parses the pb_hba.conf file and does not affect any other DNS related functionality.

To work around this issue we specify "ALL IPs" allowed in the pg_hba.conf file. This is not a security hole because the we have a security group/firewall configuration already in place that allows connections ONLY from the app server instance to the postgres instance.

BTW, according to the documentation specifying a hostname in the pg_hba.conf has an additional performance impact due to the reverse/forward dns lookups. So this setup actually works for us from performance standpoint as well..