DNS Resolution with the RESOLVER::name_lookup Command

When 15.1 released, we deprecated the RESOLV::lookup command. It still works, but there is no commitment that it will continue to work, so now is a good time to begin migrating your code away from it...
Published Jan 26, 2021
Version 1.0
application delivery
BIG-IP
iRules
JRahm's avatar
Icon for Admin rankAdmin
Christ Follower, Husband, Father, Technologist. I love community and I especially love THIS community. My background is networking, but I've dabbled in all the F5 iStuff, I'm a recovering Perl guy, and am very much a python enthusiast. Learning alongside all of you in this accelerating industry toward modern apps and architectures.
View Profile
JRahm's avatar
Icon for Admin rankAdmin
Christ Follower, Husband, Father, Technologist. I love community and I especially love THIS community. My background is networking, but I've dabbled in all the F5 iStuff, I'm a recovering Perl guy, and am very much a python enthusiast. Learning alongside all of you in this accelerating industry toward modern apps and architectures.
View Profile
rob_carr's avatar
rob_carr
Icon for Cirrocumulus rankCirrocumulus
Feb 16, 2021

Hi Jason,

 

Your rule uses CLIENT_ACCEPTED, which would seem to imply that this iRule would be attached to a DNS listener. In my organization BIG-IP DNS listeners are the first stop for all client DNS queries, so attaching an iRule to the listener would lead to hundreds of thousands of evaluations per day that aren't really needed (only a subset of queries need this functionality).

 

Is there any reason why the DNS_REQUEST event couldn't be used (instead of CLIENT_ACCEPTED) and then the iRule associated with a specific Wide IP?