Turbot Dynamic DNS and Route 53 Resolver Configuration

Overview

Why Dynamic DNS?

DNS entries for addressing resources with dynamically changing private IP addresses can be difficult to manage with traditional DNS models. Specific dynamic examples include:

  • Addressing of EC2 instances with dynamically assigned IP addresses requires a large pre-loading of DNS entries or extensive automation of DNS.
  • RDS instances, with failover.
  • Elastic Load Balancers, balancing traffic.
  • ElastiCache instances, providing failover and read balancing.

This document outlines a proposed solution from Turbot to provide dynamically managed, private DNS entries for AWS resources.

Turbot Solution

An internal subdomain should be allocated that will be used for DNS entries associated with AWS accounts. This subdomain, hosted by Route 53, will then automatically be managed and updated by Turbot based on the dynamic resources created in the AWS accounts under management.

Here is the core configuration that Turbot will manage automatically:

  • In the Turbot master account (aaa), a Route 53 record would be created for {clusterId}.example.com.
  • On-premise DNS servers will delegate DNS resolution for the {clusterId}.example.com subdomain to the Route 53 record.
  • Each AWS account in Turbot will then have a Route 53 record created for {accountId}.{clusterId}.example.com. The master account record for {clusterId}.example.com will delegate resolution to these account level subdomains.
  • Resources will be dynamically assigned DNS names by Turbot in a consistent way based on their metadata.

The flexible & logical naming scheme for DNS of resources

With a fully automated system, this allows flexibility on naming – including creating multiple logical names for each resource. DNS entries can be added based on:

  • IP address (e.g. ip-10-1-2-3)
  • AWS ID (e.g. i-abcd1234)
  • Server name scheme (e.g. custabcuva3003)
  • Tags (e.g. my-app.app; my-custom-value.my-custom-key)

Entries are combined into useful constructs based on logical definitions. For example:  

  • Multiple servers with the same tag are automatically placed into a round-robin DNS configuration for that name.
  • Entries can span multiple regions for the same account (e.g. same name given to two servers in different regions), but will also have region-specific entries for more specific addressing.

Here are some specific examples of the names that would be created by AWS service:

  • EC2 servers:
    • {instanceId}.{accountId}.{clusterId}.example.com: A Record
    • {ip-address-with-dashes}.{accountId}.{clusterId}
    • {name}.{accountId}.{clusterId}.example.com: CNAME to {instanceId}.
    • {name} is a best guess calculation from the Name tag.
    • {tagValue}.{tagKey}.tags.ec2.{region}.{accountId}.{clusterId}.example.com
  • RDS, Redshift & ElastiCache:
    • {name}.{region}.rds.{accountId}.{clusterId}.example.com
    • {serviceName} is rds, redshift or elasticache
    • {name} is the RDS instance name
    • CNAME to RDS AWS record
    • {tagValue}.{tagKey}.tags.{serviceName}.{region}.{accountId}.{clusterId}.example.com
    • CNAME to {name}.{region} record • {tagValue} and {tagKey} are sanitized
    • In the default region, these shortcut names are also created:
    • {name}.rds.{accountId}.{clusterId}.example.com
    • {tagValue}.{tagKey}.tags.rds.{accountId}.{clusterId}.example.com

This is very different from the old model of fixed per server DNS. It’s a model with a huge number of possibilities to make it easier for application teams to name and manage their servers. For example:

  • Bob starts an EC2 development instance and sets the Name tag to Bob. He can immediately login to the server as bob.{accountId}.{clusterId}.example.com.

AWS assigned IP addresses (e.g. ip-10-1-2-3) work immediately since a single zone is created for each VPC. Services like EMR are immediately available for use with no complex DNS structure.


Security Considerations of using Public Route 53 records

Turbot’s proposed solution requires the use of Route 53 public zones, which requires discussion from a security perspective.

Route 53 offers both public and private DNS records. Unfortunately, private zones are not practical since they only work within a single VPC and require the use of AWS DNS. In a multi-account environment, with internal corporate DNS servers, they are not suitable for use.

Discovery of public records is impractical:

  • Delegation of the {clusterId}.example.com domain is only visible from internal facing example.com DNS servers.
  • AWS randomly assigns DNS servers to hosted zones.
  • So, an attacker would have to know the DNS name for {clusterId}.example.com and then brute force query all AWS DNS servers to find the record.

Resource records are also impractical to find:

  • Each account {accountId}.{clusterId}.example.com has randomly assigned DNS servers from AWS.
  • AWS does not allow AXFR to list zones, so there is no way to ask {clusterId}.example.com for a list of the account subdomains.
  • AWS does not allow AXFR to list zones, so there is no way to ask {accountId}.{clusterId}.example.com for a list of resource records.
  • Resource records served by {accountId}.{clusterId}.example.com are highly dynamic and generally based on random structures like the EC2 instance ID, etc. Guessing these records directly is highly impractical.

In summary:

  • DNS entries (IP addresses) are only useful once inside the network.
  • Finding DNS entries for internal resources before entering the network is difficult to the point of being impractical.
  • Any attacker once inside the network would have the same information available anyway.


Turbot Policy Configurations

Route 53 Public Hosted Zones:

  • Turbot > DNS > Infrastructure Zone > Enforce: Managed by Turbot
  • Turbot > DNS > Account Infrastructure Zone > Enforce: Managed by Turbot
  • Turbot > DNS > Infrastructure Domain Name Template > "Enter your Domain structure" -- IE. test.turbot.com
  • Turbot > DNS > Account Infrastructure Domain Name Template > {{ account.id }} -- this would use turbots internal accoint id. IE. xyz.test.turbot.com

Route 53 Resolver:

  • AWS > Route 53 > Resolver Inbound Endpoint Configuration > Enforce: Configuration
  • AWS > Route 53 > Resolver Inbound Endpoint Configuration Availability Zone > Can be set to a value of "2,3,4,5,6 or Maximum available"
  • AWS > Route 53 > Resolver Inbound Endpoint Configuration Name Template > Configure the name of your Inbound Endpoint.
  • AWS > Route 53 > Resolver Inbound Endpoint Configuration Security Group Name Template > Define the name of the SG which is used in the creation of the inbound endpoint.
  • AWS > Route 53 > Resolver Outbound Endpoint Configuration > Enforce: Configuration
  • AWS > Route 53 > Resolver Outbound Endpoint Configuration Availability Zone > Can be set to a value of "2,3,4,5,6 or Maximum available"
  • AWS > Route 53 > Resolver Outbound Endpoint Configuration Name Template > Configuring the name of your outbound endpoint.
  • AWS > Route 53 > Resolver Outbound Endpoint Configuration Security Group Name Template > Defining the name of the SG which is used in the creation of the outbound endpoint.

 

Route 53 Setup after Turbot Configuration:

  • Navigate to the AWS console of the account in question to configure the route 53 resolver rules.

Route 53 > Resolver > Rules - Create Rule:

  • Set Parameters below:
  • Name - "Name of the Rule"
  • Rule Type = Forward
  • Domain Name = "Enter on-prem Domain"
  • Outbound Endpoint = Select the Outbound Endpoint Turbot created.

Target IP Addresses:

  • Add in the IP addresses that are used for DNS for the on-premise server you are trying to create forward rules for.
  • Add Tags (Optional)
  • Press Submit AWS will now create the Resolver rule.

 

Was this article helpful?
0 out of 0 found this helpful