modifying DNS question to add client ip to the DNS:: edns0 options
I have a requirement to modify the incoming DNS request to show client IP address in ENDS option 65523. This is in addition to EDNS Client Subnet option, which we already have enabled through DNS profiles. I am trying achieve to that through below irule but I see some argument and syntax errors. could someone help me fix this irule. when DNS_REQUEST { if { [DNS::edns0 exists] } { # Get the client's IP address set client_ip [IP::client_addr] # Convert client IP to hexadecimal set hex_client_ip [format "%02x%02x%02x%02x" [lindex [split $client_ip .] 0] [lindex [split $client_ip .] 1] [lindex [split $client_ip .] 2] [lindex [split $client_ip .] 3]] # Create a DNS EDNS option with the client's IP in hexadecimal as the value DNS::edns option 65523 $hex_client_ip } }
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!
