Adding a new WIP and having it placed in the correct Zone
I have a scenario where when I create a new Wide IP, it is not being put into the correct zone file. For example. 3 zones: example.com wip.example.com xwip.example.com When I create a new Wide IP, like test.wip.example.com, it is being placed into the example.com zone file!!. Is that the correct behavior? It gets more complicated as I also have 2 different views. External Internal which have their own zone files for each of the 3 zones. db.external.example.com db.internal.example.com etc Unfortuntely everything is being placed into the db.external.example.com file no matter what type of record it is...I have to manually move it. Is there a better way to do this? Also, does anyone know what the GTM uses to make it's decision on where to put new WIPs into what zone files? I know ZoneRunner is involved in that part, but I'm not sure how it is making it's zone file destiantion decision.
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
F5 User Management and Views
I installed the F5 Application Visibility and Reporting module on the F5 appliance. I enabled some analytics for an application. I would like to give somebody access to see all of the analytics/application statistics, but none of the configuration for the application. Is this possible?
GTM query regarding Internal and external zone views.
(EDITED 7-1) Relatively new (a returnee of sorts ) to F5 products. We have an implementation of GTM (a redundant pair of instances with one at two different physical locations) that we are trying to ready for production that is intended to replace our internal DMZ nameservers and external authoritative DNS name servers. The thought was to create an internal and external view utilizing one set of DNS servers After setting up wideIPs, we proceeded to migrate our external zones to GTM using the external view. This seemed successful. In the Zone RUnner GUI we then created a internal zone using one of our domains. We then discovered that it seemed populated with the external records even though it was defined as db.internal.(domain).com. Via CLI I was able to confirm that the db.internal.(domain).com. did NOT have these external records, and proceeded to manually enter internal records. I then reloaded the zrd process after validating the BIND files I'm assuming that there must be some misconfiguration in the GTM instance itself as it appears that BIND is properly configured in terms of the views but in the GUI ZoneRunner does not see any internal view domain that shares a domain name with an external view zone. To sum up: -From the GTM GUI if I create a zone as internal only when I attempt to view the zone details I get this error: 01150b21:3: RCODE returned from query: 'NOTAUTH'. -If I attempt to create a record for the internal only zone in the GUI get this error: 115040a:3: Zone not authoritative during update. -From the CLI I can create the internal view zones, check them and successfully add them to the named.conf. named.conf correctly has both views defined and the correct zones assigned. The internal view and external views zones all have the correct information. The permissions all appear to be correct (belonging to the named process). Any ideas on what I may be doing wrong?