For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Amit_Grover_171's avatar
Amit_Grover_171
Icon for Nimbostratus rankNimbostratus
Aug 10, 2015

Is it possible to perform DNS SRV query at node level so that traffic will directed on same.

Hi,   In my scenario I am using Outbound SNAT and for outbound traffic from my LTM but traffic should forward in outbound according to its DNS srv which can not be static IP. For this work-aroun...
application delivery
devops
iRules
LTM
TMOS
VernonWells's avatar
VernonWells
Icon for Employee rankEmployee
Aug 11, 2015

As you appear to have discovered, FQDNs will resolve A, AAAA and CNAME chains only. In fact, not only will it not try to perform an SRV lookup, it won't even accept underscores (_) in names.

If your objective is to use an SRV target for the node name, things do become very tricky. There are a few ways to solve this: 1. inline; 2. via the control plane; 3. both.

For 1, you'd need an iRule. That iRule would need to make a sideband connection in order look up the SRV record. Things get really tricky here for at least four reasons: 1. you may get more than one target back; 2. although the target name is not supposed to be an alias, it may be anyway; 3. one or more targets may be down; and 4. you'd have to build the DNS query and response manually (you cannot use 

RESOLV::lookup
, for example, since it only returns A records). You have to figure out how to handle those various issues. The more robust you wish to be, the more complex (and time expensive) the iRule;

For 2, you could periodically (via iCall) perform the SRV lookup, then test reachability, then modify the node address based on the results. This causes a config change, however, which can be a drawback, and does not account for reachability failure after the change but before the next lookup. On the other hand, there is no iRule;

For 3, you could do the periodic call from 2, then populate the information somewhere that is accessible to an iRule (e.g., a data group). This moves the complexity out of the iRule and into the control plane (where the cost becomes more-or-less irrelevant), makes a smaller config change, and could potentially allow for a work-around if the server-side connect fails. However, it still entails a config change. On system that is part of a DSC (e.g., in an active/standby pair), this can be a big issue because it will constantly move the units of the DSC out-of-sync.

The best way is to scrap the use of the SRV for this case, and leverage GTM in order to provide a reachable A record. Then you can use FQDNs as above. This, however, requires adding and configuring GTM somewhere (it could be on the same system as the LTM, of course).