Implementing Client Subnet in DNS Requests

Update 2018-07-14: Starting with BIG-IP DNS 14.0 Client Subnet is available as a checkbox feature: https://devcentral.f5.com/s/articles/using-client-subnet-in-dns-requests-31948

Original Article:

Sending end-users to the right data center

Using an iRule and edns-client-subnet (ECS) we can improve the accuracy of F5 GTM’s topology load balancing.  In a global world you expect to send your end-users to the closest regional data center. An end-user request from Tokyo will be sent to a data center in Tokyo and an end-user in California will be sent to a data center in California. GTM does this using topology load balancing, but centralized DNS resolvers like Google DNS or OpenDNS can interfere with GTM’s ability to provide accurate topology load balancing. An end-user in Tokyo, Japan using OpenDNS will be sent to a data center in California instead of Tokyo. The end-user is sent to the wrong data center because the original DNS request appeared to originate from an OpenDNS server in California instead of the end-user’s location in Tokyo.

Fortunately there is a draft protocol to address these challenges using a protocol EDNS Client Subnet (ECS). ECS enables DNS servers to provide more accurate topology information that can improve end-user experience. ECS is similar to X-Forwarded-For headers used with HTTP. X-Forwarded-For header is a technique for preserving the original client IP address for cases when the BIG-IP translates the source IP address of HTTP traffic. ECS injects information about the original client IP subnet into the DNS request.

Today, with version 11.5.x and 11.6.0 the BIG-IP we can use an iRule to implement a solution that is interoperable with the current draft protocol for testing and evaluation.

Implementing the protocol

After reading through the draft specification you can see that ECS requires the ability to interpret ECS information that is sent with the DNS query as well as respond with an appropriate response that indicates to the DNS resolver that the DNS server supports ECS. Fortunately we have two LTM iRule events “DNS_REQUEST” and “DNS_RESPONSE” that allows us to receive and respond with the appropriate messages. We can leverage the GTM DNS_REQUEST iRule event to capture the information and the whereis command to act on the information.

A graphical representation of the solution

The iRule code can be found on the codeshare. Here’s a sample output of the results of using the iRule with OpenDNS’s servers (requires a request to OpenDNS support to enable your DNS servers to receive ECS from OpenDNS) and Google DNS.

Rule /Common/ecs_topology_www : LDNS LOC: 208.69.37.XXX NA US California {}  
Rule /Common/ecs_topology_www : ECS LOC: 210.226.XXX.0 AS JP Tokyo {}  
Rule /Common/ecs_topology_www : Asia

ECS iRule using OpenDNS

Rule /Common/ecs_topology_www : LDNS LOC: 173.194.93.XXX NA US California {}  
Rule /Common/ecs_topology_www : ECS LOC: 210.226.XXX.0 AS JP Tokyo {}  
Rule /Common/ecs_topology_www : Asia

ECS iRule using Google DNS

Implementing a draft now

ECS is still a draft protocol and may change over time. Using a F5 iRule we can interoperate with the protocol to provide better granularity for topology load balancing. The example above was done in a lab environment to demonstrate what’s possible.  Improvements that could be made to the example include:

• More accurate implementation of the draft (it works, but I didn’t read the draft that closely)
• Limiting ECS responses to Google/OpenDNS/ECS DNS resolvers
• Implementing a ECS resolver (possible?)

Using an iRule we can solve today’s problem using a draft protocol!