Forum Discussion
Kai_Wilke
Mar 02, 2016MVP
Hi
the last posted iRule is somewhat invalid (a closing curly brace
}
is missing and the LF formating is screwed).
I've reconstructed and optimized the logic as best as possible. But because of the missing curly brace, I'm not sure if the iRule still does what you need...
The iRule would block DNS request from client IPs which are not defined in the
admin_datagroup
datagroup. If the client IPs is in the admin_datagroup
the [string tolower [DNS::question name]]
gets matched with the Blacklist_Class
datagroup. If the [DNS::question name] is in the blacklist and [DNS::question type]
= A
then respond with $static::blacklist_reply_IPV4
. If not [DNS::question type]
= A
then use DNS::last_act reject
to determine the result of the DNS request...
when RULE_INIT {
Set IPV4 address that is returned for Blacklist matches for A records
set static::blacklist_reply_IPV4 "10.10.10.10"
Set TTL used for all Blacklist replies
set static::blacklist_ttl "100"
}
when DNS_REQUEST {
if { [DNS::header "rd"] == 1 } then {
if { not [class match [IP::client_addr] eq "admin_datagroup" ] } then {
DNS::drop
} elseif { [class match [string tolower [DNS::question name]] eq Blacklist_Class] } then {
if { [DNS::question type] eq "A" } then {
DNS::answer insert "[DNS::question name]. $static::blacklist_ttl IN A $static::blacklist_reply_IPV4"
DNS::header ra "1"
} else {
DNS::last_act reject
}
DNS::return
}
}
}
Note: I've integrated the DNS_RESPONSE event funtionality to the DNS_REQUEST event, since it doesn't make much sense to resolve the query, if the request parameters are already indicating a intercepted response.
Note: I didn't test the iRule at all. The optimization are purely based on experiences...
Cheers, Kai