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.

20 Lines or Less: Security Headers and DNS

What could you do with your code in 20 Lines or Less? That's the question we like to ask from, for, and of (feel free to insert your favorite preposition here) the DevCentral community, and every ...
Published Mar 14, 2016
Version 1.0
application delivery
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
Kai_Wilke's avatar
Kai_Wilke
Icon for MVP rankMVP
Aug 09, 2016

Thanks Jason for including one (two!) of my solutions in the 20LinesOrLess series... 😉

@Jie: The 

DNS::answer clear
is required in this case to sanitize the existing DNS answer, to make sure that only the blacklist response is send to the client. If you skip the 
DNS::answer clear
, then it may become a RR DNS response. But you could also directly DNS respond to the request using the DNS_REQUEST event (not implemented in this specific iRule). In this case you don't need to 
DNS::answer clear
the answer, since you would build the answer completely from the scratch...

Cheers, Kai