Disable DNS Express to allow recursion of a delegated sub-domain
Problem this snippet solves: If you are using GTM to act both a authoritative slave with DNS Express and as a recursive cache, recursion will not work if a request is made for a delegated sub-domain if the parent domain exists in DNS Express. i.e. domain.com exists in DNS Express but has delegated the dev.domain.com sub-domain to a different set of name server. Any request to dev.domain.com will just get a referral rather than being recursed. This is because of the order of operations in GTM, https://support.f5.com/kb/en-us/solutions/public/14000/500/sol14510.html. Recursion is the very last process that could happen and since DNS Express makes an authoritative referral response no recursion will occur. How to use this snippet: To use this your listener and corresponding DNS profile need to have DNS Express configured and recursion enabled(cache). Then the iRule just needs to be attached to the listener. Code : when DNS_REQUEST { #query DNS Express to look for a sub-domain delegation set rrr [DNS::query dnsx [DNS::question name] [DNS::question type]] #evaluate if the queried zone is defined in DNS Express #empty response indicates DNS Express does not have the requested domain #so we should exit and continue to recursion if {$rrr equals "{} {} {}"}{return} #check if DNS Express response is a delegated sub-domain referral if { [lindex $rrr 0] equals "" && [DNS::type [lindex [lindex $rrr 1] 0]] equals "NS"} { #no ANSWER was returned AND AUTHORITY is an NS record(not a SOA) #this is a referral so we should disble DNS Express to allow for the subdomain to be recursed DNS::disable dnsx } } Tested this on version: 11.6
BIG-IP DNS Express - Private Zone Blocker
Problem this snippet solves: With BIG-IP DNS; you cannot enable/disable configured DNS Express Zones on a per-listener basis. This makes scenarios where a single BIG-IP DNS system has listeners exposed to internal networks with RFC1918 addresses and public Internet networks. DNS Express doesn't support DNS Views, in short. This iRule allows you to configure a datagroup containing "disabled_zones" and the iRule will validate if the query matches a zone listed in disabled_zones. If it gets a match, it simply returns nothing. Additionally, the iRule examines all responses and checks that resource records in the response do not contain RFC1918 addresses and if it finds them, it removes those Resource Records. All code in the "DNS_RESPONSE" event can be commented or deleted if this behavior isn't desired. How to use this snippet: enable iRule on DNS listener (most likely a listener available only to private network clients) and configure "disabled_zones" data group as shown in example. Log lines can be deleted or commented out once proper operation of the rule is confirmed and understood or retained for purposes of auditing queries that are dropped/blocked. Code : when DNS_REQUEST { log "Got request from: [IP::remote_addr] for [DNS::question name]" if {[class match [DNS::question name] ends_with disabled_zones]}{ log "Query for [DNS::question name] is for a disabled zone - Dropping" DNS::return } } when DNS_RESPONSE { log "Got Response = [DNS::answer]" set rrs [DNS::answer] set privateresponse 0 foreach rr $rrs { log "DNS Response rr: $rr" if {[DNS::type $rr] == "A"}{ if {[class match [DNS::rdata $rr] equals private_net]}{ set privateresponse 1 DNS::answer remove $rr } log "DNS RR data: [DNS::rdata $rr]" } } if {$privateresponse}{ log "DNS response contains private addresses" } } Tested this on version: 13.0