ABOUT DEVCENTRAL

DevCentral News Technical Forum Technical Articles Technical CrowdSRC Community Guidelines DevCentral EULA Get a Developer Lab License Become a DevCentral MVP

RESOURCES

Product Documentation White Papers Glossary Customer Stories Webinars Free Online Courses F5 Certification LearnF5 Training

SUPPORT

Manage Subscriptions Professional Services Professional Services Create a Service Request Software Downloads Support Portal

PARTNERS

Find a Reseller Partner Technology Alliances Become an F5 Partner Login to Partner Central

---

©2024 F5, Inc. All rights reserved.

This is the latest in a series of DNS articles that I've been writing over the past couple of months.  This article is taken from a fantastic solution that Joe Cassidy developed.  So, thanks to Joe for developing this solution, and thanks for the opportunity to write about it here on DevCentral.  As a quick reminder, my first six articles are:

1. Let's Talk DNS on DevCentral
2. DNS The F5 Way: A Paradigm Shift
3. DNS Express and Zone Transfers
4. The BIG-IP GTM: Configuring DNSSEC
5. DNS on the BIG-IP: IPv6 to IPv4 Translation
6. DNS Caching

The Scenario

Let's say you are an F5 customer who has external GTMs and LTMs in your environment, but you are not leveraging them for your main website (example.com).  Your website is a zone sitting on your windows DNS servers in your DMZ that round robin load balance to some backend webservers. 

You've heard all about the benefits of the cloud (and rightfully so), and you want to move your web content to the Amazon Cloud.  Nice choice!  As you were making the move to Amazon, you were given instructions by Amazon to just CNAME your domain to two unique Amazon Elastic Load Balanced (ELB) domains.  Amazon’s requests were not feasible for a few reasons...one of which is that it breaks the RFC.  So, you engage in a series of architecture meetings to figure all this stuff out. 

Amazon told your Active Directory/DNS team to CNAME www.example.com and example.com to two AWS clusters: us-east.elb.amazonaws.com and us-west.elb.amazonaws.com.  You couldn't use Microsoft DNS to perform a basic CNAME of these records because of the BIND limitation of CNAME'ing a single A record to multiple aliases.  Additionally, you couldn't point to IPs because Amazon said they will be using dynamic IPs for your platform.  So, what to do, right?

The Solution

The good news is that you can use the functionality and flexibility of your F5 technology to easily solve this problem.  Here are a few steps that will guide you through this specific scenario:

• Redirect requests for http://example.com to http://www.example.com and apply it to your Virtual Server (1.2.3.4:80).  You can redirect using HTTP Class profiles (v11.3 and prior) or using a policy with Centralized Policy Matching (v11.4 and newer) or you can always write an iRule to redirect!

• Make www.example.com a CNAME record to example.lb.example.com; where *.lb.example.com is a sub-delegated zone of example.com that resides on your BIG-IP GTM.

• Create a global traffic pool “aws_us_east” that contains no members but rather a CNAME to us-east.elb.amazonaws.com.
• Create another global traffic pool “aws_us_west” that contains no members but rather a CNAME to us-west.elb.amazonaws.com. 

The following screenshot shows the details of creating the global traffic pools (using v11.5).  Notice you have to select the \"Advanced\" configuration to add the CNAME.

• Create a global traffic Wide IP example.lb.example.com with two pool members “aws_us_east” and “aws_us_west”.  The following screenshot shows the details.

• Create two global traffic regions: “eastern” and “western”.  The screenshot below shows the details of creating the traffic regions.

• Create global traffic topology records using \"Request Source: Region is eastern\" and \"Destination Pool is aws_us_east\".  Repeat this for the western region using the aws_us_west pool.  The screenshot below shows the details of creating these records.

• Modify Pool settings under Wide IP www.example.com to use \"Topology\" as load balancing method.  See the screenshot below for details.

How it all works...

Here's the flow of events that take place as a user types in the web address and ultimately receives the correct IP address.

• External client types http://example.com into their web browser

• Internet DNS resolution takes place and maps example.com to your Virtual Server address:  IN A 1.2.3.4

• An HTTP request is directed to 1.2.3.4:80

• Your LTM checks for a profile, the HTTP profile is enabled, the redirect request is applied, and redirect user request with 301 response code is executed

• External client receives 301 response code and their browser makes a new request to http://www.example.com

• Internet DNS resolution takes place and maps www.example.com to IN CNAME example.lb.example.com

• Internet DNS resolution continues mapping example.lb.example.com to your GTM configured Wide IP

• The Wide IP load balances the request to one of the pools based on the configured logic:  Round Robin, Global Availability, Topology or Ratio (we chose \"Topology\" for our solution)

• The GTM-configured pool contains a CNAME to either us_east or us_west AWS data centers

• Internet DNS resolution takes place mapping the request to the ELB hostname (i.e. us-west.elb.amazonaws.com) and gives two A records

• External client http request is mapped to one of the returned IP addresses

And, there you have it.  With this solution, you can integrate AWS using your existing LTM and GTM technology!  I hope this helps, and I hope you can implement this and other solutions using all the flexibility and power of your F5 technology.

Not sure how this article is relevant since the CNAME pool would need to be against a FQDN.  For example anything you do with AWS the pool members would need to be a FQDN since the IPs change based upon whatever AWS wants to do.

The original article for 11.x was perfect.  Right now though that advanced button is gone in the newer versions so no clue on how to do with strictly using a GTM.

What is odd - the LTM you can put pool members with a FQDN but not with the GTM Pool members those must be a IP or server.

Not sure how this article is relevant since the CNAME pool would need to be against a FQDN.  For example anything you do with AWS the pool members would need to be a FQDN since the IPs change based upon whatever AWS wants to do.

The original article for 11.x was perfect.  Right now though that advanced button is gone in the newer versions so no clue on how to do with strictly using a GTM.

What is odd - the LTM you can put pool members with a FQDN but not with the GTM Pool members those must be a IP or server.

Redirecting DNS Queries Using a CNAME Pool

Redirecting DNS Queries Using a CNAME Pool

\"What is odd - the LTM you can put pool members with a FQDN but not with the GTM Pool members those must be a IP or server.\"

That's not actually correct. You can use a Wide IP or an FQDN as a static entry as pool members.
In my work environment we use FQDNs when we don't care about health checking and Wide IPs when we do. We rely on federation with LTMs that are able to resolve our cloud endpoints and health check them. It's an object heavy configuration, but it does work.

Why not just use a script for the health monitor on the GTM?  We are trying to figure out a way to load balance between internal and external AWS resources to save $$$.

We have several issues and I think right now the big one is ensure health checking against the FQDN.   Which maybe using a \"Scripted\" health check approach would be the answer so we can keep all of this on the GTM.

Another issue we are hitting is randomly some of the AWS won't resolve every time.  Wondering if it has to do with caching so looking to try and simplify maybe our solution.