GTM Pool Members Gone After Maintenance? It's Probably This One Setting
You finish a maintenance window, everything looks good on LTM, and then someone notices Wide IPs are resolving to fewer destinations than before. You check the GTM pools and the members are just... gone. The virtual servers are fine on LTM. GTM just doesn't know about them anymore — and more importantly, it doesn't remember if they were ever pool members. This happens more often than it should, and it almost always comes back to the same thing: virtual-server-discovery enabled doing exactly what it was designed to do, at exactly the wrong moment. What's Actually Going On When virtual-server-discovery is set to enabled on a GTM server object, GTM keeps its view of LTM virtual servers in sync via iQuery. It automatically adds new virtual servers, updates existing ones, and — this is the part that causes problems — deletes virtual servers that LTM stops reporting on. That delete behavior is the issue. Any time iQuery reports zero virtual servers, even temporarily, GTM treats it as a mass deletion event. The virtual servers get pulled from the server object, and with them, their pool memberships. When LTM eventually reports on those virtual servers again, GTM re-discovers them as brand new objects with no memory of which pools they belonged to. Two scenarios trigger this consistently. Scenario 1: LTM Software Upgrade This is the one that catches most people. During an upgrade, LTM reboots and goes through a phase where iQuery can connect but the full configuration hasn't finished loading yet. From GTM's perspective, LTM is reachable but reporting no virtual servers. GTM interprets that as a deletion event, clears out the discovered virtual servers, and empties the pools. When LTM finishes loading and the virtual servers come back, GTM re-discovers them — but the pool memberships are gone. You're left manually rebuilding what was there before the maintenance window started. The telltale sign is pool members coming back in blue/CHECKING state. That only happens to newly discovered objects. GTM treated a returning virtual server as a brand new one — because as far as it's concerned, it is. The GTM log won't show a deletion event, only the re-add. That gap in the logs is a known blind spot with virtual-server-discovery enabled, and it's exactly why the problem is hard to diagnose after the fact. What you'll typically see in /var/log/gtm after the LTM comes back: alert gtmd[xxxxx]: 011a1005:1: SNMP_TRAP: Pool your_pool state change green --> red (No enabled pool members available) alert gtmd[xxxxx]: 011a3004:1: SNMP_TRAP: Wide IP your.wideip.example.com state change green --> red (No enabled pools available) And then shortly after, the virtual servers re-appear in CHECKING state as GTM re-discovers them — but with no pool bindings. Scenario 2: LTM HA Failover This one surprises people because the LTM pair is still running — it's just switching active units. After a failover, the new active device may not have its iQuery connections fully re-established yet. GTM sees the iQuery state as inconsistent, virtual server status updates stop coming through, and members disappear from the discovered list. What makes this harder to diagnose is that tmsh show gtm iquery may show "connected" — but connected doesn't mean the config sync is working correctly. In a GTM sync group, only the device assigned local ID 0 (the GTM with the lowest IP address) is responsible for writing auto-discovery results to the configuration. If that specific device loses its iQuery connection during the failover window, discovery events are missed entirely — even if every other GTM in the group can still reach the LTM. So you can have a situation where five out of six GTMs look perfectly healthy, iQuery shows connected everywhere, and yet pool members are still disappearing — because the one device that matters for discovery is the one with the broken connection. You can check which device in your sync group holds local ID 0 with: tmsh list sys db gtm.peerinfolocalid If that device's iQuery connection to the LTM is the one that dropped during the failover window, that's your answer — even if everything else looks fine. The Fix: enabled-no-delete Both scenarios share the same root cause: GTM's auto-delete behavior treating a temporary iQuery disruption as a permanent deletion event. The fix is the same for both: gtm server /Common/site1-ltm { addresses { 10.1.1.1 { device-name site1-ltm } } datacenter /Common/dc1 monitor /Common/bigip virtual-server-discovery enabled-no-delete } With enabled-no-delete, GTM still auto-discovers new virtual servers and keeps existing ones updated. The only thing that changes is that it will never delete a virtual server just because LTM temporarily stopped reporting it. Your pool memberships survive both scenarios above. Mode Adds new VS Updates VS Deletes VS Pool memberships survive iQuery disruption? disabled No No No Yes — nothing changes enabled Yes Yes Yes No — any disruption can empty pools enabled-no-delete Yes Yes No Yes — preserved The Trade-Off enabled-no-delete won't clean up after you when you intentionally decommission a virtual server on LTM. The stale GTM object stays in the discovered list until you remove it manually. In environments with a lot of VS churn, this can accumulate over time. The question is which failure mode you'd rather manage: pool members silently disappearing during a maintenance window, or occasionally needing to clean up stale objects after a planned decommission. For most production environments, the latter is far easier to deal with — and far less likely to wake someone up at 2am. How to Make the Change Via tmsh: tmsh modify gtm server /Common/site1-ltm \ virtual-server-discovery enabled-no-delete tmsh save sys config Via GUI: Go to DNS → GSLB → Servers Select the server object Set Virtual Server Discovery to Enabled (No Delete) Click Update This takes effect immediately and does not affect existing discovered virtual servers or current pool memberships. Cleaning Up Stale Objects When you intentionally decommission a virtual server on LTM, remove the leftover GTM object manually: # List virtual servers under a GTM server object tmsh list gtm server /Common/site1-ltm virtual-server # Remove a specific stale entry tmsh modify gtm server /Common/site1-ltm \ virtual-servers delete { /Common/old-vs-name } tmsh save sys config Make this part of your standard VS decommission runbook and stale objects will never pile up. Quick Diagnostic When Members Go Missing Before assuming it's a discovery issue, check iQuery health across all GTM devices first: tmsh show gtm iquery Look for: State: should be connected to all entries Reconnects: A high count suggests instability even if the connection looks up Configuration Time: None means the config has never successfully synced from that LTM Then confirm which GTM holds local ID 0 and verify its connectivity specifically: tmsh list sys db gtm.peerinfolocalid If the local ID 0 device is the one with the broken iQuery connection, that's your answer — regardless of what the other devices are showing. Wrapping Up Whether it's an LTM upgrade or an HA failover, the pattern is the same: iQuery goes quiet for a moment, GTM interprets silence as deletion, and your pool memberships are gone. It's working as designed — just not in a way that's useful to you. enabled-no-delete is a one-line change that stops this from happening. The cleanup overhead it introduces is predictable and manageable. The alternative — rebuilding pool memberships after an unplanned event — is not. Have you run into either of these scenarios in your environment? Drop a comment below, especially if you've seen the local ID 0 shift cause issues during a rolling GTM upgrade.
Use Fully Qualified Domain Name (FQDN) for GSLB Pool Member with F5 DNS
Normally, we define a specific IP (and port) to be used as GSLB pool member. This article provides a custom configuration to be able to use Fully Qualified Domain Name (FQDN) as GSLB pool member--with all GSLB features like health-check monitoring, load balancing method, persistence, etc. Despite GSLB as a mechanism to distribute traffic across datacenters having reached years of age, it has not become less relevant this recent years. The fact that internet infrastructure still rely heavily on DNS technology means GSLB is continuously used due to is lightweight nature and smooth integration. When using F5 DNS as GSLB solution, usually we are dealing with LTM and its VS as GSLB server and pool member respectively. Sometimes, we will add a non-LTM node as a generic server to provide inter-DC load balancing capability. Either way, we will end up with a pair of IP and port to represent the application, in which we sent a health-check against. Due to the trend of public cloud and CDN, there is a need to use FQDN as GSLB pool member (instead of IP and port pair). Some of us may immediately think of using a CNAME-type GSLB pool to accommodate this. However, there is a limitation in which BIG-IP requires a CNAME-type GSLB pool to use a wideIP-type pool member, in which we will end up with an IP and port pair (again!) We can use "static target", but there is "side-effect" where the pool member will always consider available (which then triggers the question why we need to use GSLB in the first place!). Additionally, F5 BIG-IP TMUI accepts FQDN input when we configure GSLB server and pool member. However, it will immediately translate to IP based on configured DNS. Thus, this is not the solution we are looking for Now this is where F5’s BIG-IP power (a.k.a programmability) comes into play. Enter the realm of customization... We all love customization, but at the same time do not want that to be overly complicated so that life becomes harder on day-2 🙃. Thus, the key is to use some customization, but simple enough to avoid unnecessary complication. Here is one idea to solve our FQDN as GSLB pool problem above The customized configuration object includes 1. External health-check monitor: Dynamically resolve DNS to translate FQDN into IP address Perform health-check monitoring against current IP address Result is used to determine GSLB pool member availability status 2. DNS iRules: Check #1: Checks if GSLB pool attached to wideIP contains only FQDN-type member (e.g. other pool referring to LTM VS is also attached to the wideIP) If false, do nothing (let DNS response refer to LTM VS) Otherwise, perform check #2 Check #2: Checks current health-check status of requested domain name If FQDN is up, modify DNS response to return current IP of FQDN Otherwise, perform fallback action as requirement (e.g. return empty response, return static IP, use fallback pool, etc.) 3. Internal Datagroup: Store current IP of FQDN, updated according to health-check interval Datagroup record value contains current IP if health-check success. Otherwise, the value contains empty data Here are some of the codes, where configured; wideIP is gslb.test.com, while GSLB pool member FQDN is arcadia.f5poc.id 1. External health-check monitor config gtm monitor external gslb_external_monitor { defaults-from external destination *:* interval 10 probe-timeout 5 run /Common/gslb_external_monitor_script timeout 120 #define FQDN here user-defined fqdn arcadia.f5poc.id } External health-check monitor script #!/bin/sh pidfile="/var/run/$MONITOR_NAME.$1..$2.pid" if [ -f $pidfile ] then kill -9 -`cat $pidfile` > /dev/null 2>&1 fi echo "$$" > $pidfile # Obtain current IP for the FQDN resolv=`dig +short ${fqdn}` # The actual monitoring action here curl -fIs -k https://${fqdn}/ --resolve ${fqdn}:443:${resolv} | grep -i HTTP 2>&1 > /dev/null status=$? if [ $status -eq 0 ] then # Actions when health-check success rm -f $pidfile tmsh modify ltm data-group internal fqdn { records replace-all-with { $fqdn { data $resolv } } } echo "sending monitor to ${fqdn} ${resolv} with result OK" | logger -p local0.info echo "up" else # Actions when health-check fails tmsh modify ltm data-group internal fqdn { records replace-all-with { $fqdn { } } } echo "sending monitor to ${fqdn} ${resolv} with result NOK" | logger -p local0.info fi rm -f $pidfile 2. DNS iRules when DNS_REQUEST { set qname [DNS::question name] # Obtain current IP for the FQDN set currentip [class match -value $qname equals fqdn] } when DNS_RESPONSE { set rname [getfield [lindex [split [DNS::answer]] 4] "\}" 1 ] #Check if return is IP address of specially encoded FQDN IP, 10.10.10.10 in this example if {$rname eq "10.10.10.10" }{ #Response is only from pool with external monitor, meaning no other pool is attached to wideIP if {$currentip ne ""}{ #Current FQDN health-check success DNS::answer clear # Use current IP to construct DNS answer section DNS::answer insert "[DNS::question name]. 123 [DNS::question class] [DNS::question type] $currentip" } else { #Current FQDN health-check failed #Define action to be performed here DNS::answer clear } } } 3. Internal Datagroup ltm data-group internal fqdn { records { # Define FQDN as record name arcadia.f5poc.id { # Record data contains IP, where this will be continuously updated by external monitoring script data 158.140.176.219 } } type string } *GSLB virtual server configuration Some testing The resolve will follow whichever current IP address for the FQDN. If a returning CNAME response is required, you can do so by modifying DNS irules above. The logic and code are open to any improvement, so leave your suggestions in the comments if you have any. Thanks!The BIG-IP GTM: Configuring DNSSEC
This is the fourth in a series of DNS articles that I'm writing. The first three are: Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express and Zone Transfers The Domain Name System (DNS) is a key component of the Internet's critical infrastructure. So, if the foundation of the Internet itself relies on DNS, then let's take a quick look at how stable this foundation really is. After all, DNS was born in the early 1980s...back when REO Speedwagon and Air Supply were cranking out hits on the radio. The question is...does the DNS of the 1980s have any issues we need to worry about today? Well as it turns out, DNS was not initially built with security in mind. When a user types a web address in his browser, he expects to be reliably directed to that website. Unfortunately, that doesn't always happen. One common example is seen when an attacker disrupts the user's request and redirects to a malicious site. Several DNS vulnerabilities like this have led the way to an interest in DNS Security Extensions (DNSSEC) to secure this critical part of our Internet infrastructure. What is DNSSEC? DNSSEC is a suite of extensions that add security to the DNS protocol by enabling responses to be validated. With DNSSEC, the DNS protocol is much less susceptible to certain types of attacks (like the DNS spoofing situation described above). DNSSEC uses digital signatures to validate DNS responses so that the end user can be assured he is visiting the correct website. Based on the design features of DNSSEC, it is most effective when deployed at each step in the DNS lookup process...from root zone to the final domain name. If you leave any of the steps unsigned, it creates weakness in the process and you won't be able to trust the entire chain. Keep in mind that DNSSEC doesn't encrypt the data, it just signs it to attest to the validity of the response. When a user requests a site, DNS kicks into gear by translating the domain name into an IP address. It does this through a series of recursive lookups that form a "chain" of requests. The picture below shows an example of a user requesting f5.com and the DNS system chaining together requests in order to match the domain name to the IP address so that he can access the website. This is all well and good, but the issue that forms the need for DNSSEC is that each stop in this chain inherently trusts the other parts of the chain...no questions asked. So, what if an attacker could somehow manipulate one of the servers (or even the traffic on the wire) and send the wrong IP address back to the user? The attacker could redirect the user to a website where malware is waiting to scan the unsuspecting user's computer. The picture below shows the same chain of requests, but this time an attacker has manipulated the last response so that the incorrect IP address is returned to the user. Not good. DNSSEC addresses this problem by validating the response of each part of the chain by using digital signatures. These signatures help build a "chain of trust" that DNS can rely on when answering requests. To form the chain of trust, DNSSEC starts with a "trust anchor" and everything below that trust anchor is trusted. Ideally, the trust anchor is the root zone. Fortunately for all of us, ICANN published the root zone trust anchor, and root operators began serving the signed root zone in July, 2010. With the root zone signed, all other zones below it can also be signed, thus forming a solid and complete chain of trust. In fact, ICANN also lists the Top Level Domains (TLD) that are currently signed and have trust anchors published as DS records in the root zone (most of the TLDs are signed). The following picture (taken from iiw.idcommons.net) shows the process for building the chain of trust from the root zone. DNSSEC uses two kinds of keys: Key Signing Keys and Zone Signing Keys. The Key Signing Key is used to sign other keys in order to build the chain of trust. This key is sometimes cryptographically stronger and has a longer lifespan than a Zone Signing Key. The Zone Signing Key is used to sign the data that is published in a zone. DNSSEC uses the Key Signing Keys and Zone Signing Keys to sign and verify records within DNS. BIG-IP Configuration The BIG-IP Global Traffic Manager (GTM) will not only respond to DNS requests, but it will also sign DNSSEC validated responses. But before you can configure the GTM to handle nameserver responses that are DNSSEC-compliant, you have to create DNSSEC keys and zones. The first step is to create the Zone Signing Key(s) and the Key Signing Key(s). The Zone Signing Key specifies the keys that the system uses to sign requests to a zone. The BIG-IP responds to DNSSEC requests to a specific zone by returning signed nameserver responses based on the currently available generations of a key. The Key Signing Key works the same as the Zone Signing Key except that it applies to keys instead of zones. To create these keys, navigate to Global Traffic >> DNSSEC Key List and create a new key. Note: this menu looks slightly different starting in version 11.5 (it's listed under "DNS" instead of "Global Traffic") but the Key Creation is still the same. On this page, you can create a Zone Signing Key and a Key Signing Key, and you can also specify several other settings like HSM use, algorithm selection, and key management action. Note that you can let the BIG-IP automatically manage your key actions or you can choose to do it manually. Configuration Settings The Bit Width for the key can be either 1024, 2048, or 4096 bits. The default is 1024. The TTL value specifies the length of time the BIG-IP stores the key in cache. A key can be cached between 0 and 4294967295 seconds (by the way, 4294967295 seconds is a little more than 136 years!). The default value is 86400 seconds (one day). This value must be less than the difference between the values of the rollover period and expiration period (referred to as the "overlap period"). Setting this value to 0 seconds indicates that client resolvers do not cache the key. The Rollover Period specifies the interval after which the BIG-IP creates a new generation of an existing key. The valid range for values for the Rollover Period is from 0 to 4294967295 seconds. The default is 0 seconds, which means the key does not roll over. This value of the rollover period must be greater than or equal to one third of the value of the expiration period and less than the value of the expiration period. The Expiration Period specifies the interval after which the BIG-IP deletes an existing key. The valid range for values is from 0 to 4294967295 seconds. The default is 0 seconds, which means the key does not expire. The value of the expiration period must be more than the value of the rollover period. Also, the overlap period must be more than the value of the TTL. FYI...the National Institute of Standards and Technology (NIST) recommends that a Zone Signing Key expire between 30-90 days, and that a Key Signing Key expire once a year. The Signature Validity Period specifies the interval after which the BIG-IP no longer uses the expired signature. The valid range for values is from 0 to 4294967295 seconds. The default is 7 days. This value must be greater than the value of the signature publication period. If you set this value to 0, the server verifying the signature never succeeds because the signature is always expired, so don't set it to 0! The Signature Publication Period specifies the interval after which the BIG-IP creates a new signature. The valid range for these values is from 0 to 4294967295 seconds. The default value is 4 days, 16 hours (two-thirds of a week). This value must be less than the value of the signature validity period. If you set this value to 0, the system does not cache the signature. TTL Values, Key Values, and Overlaps The following diagram shows an example of key generation timelines with rollover periods and overlaps. This diagram is useful when reviewing the configuration settings and values discussed in the section above. Notice that the expiration period must be greater than the rollover period, and the TTL must be less than the overlap period. You wouldn't want a key to expire before it rolls over; likewise, you wouldn't want a TTL period to outlast the overlap period...if it did, the key could still be valid after the expiration period. After you create and configure the Zone Signing Key(s) and Key Signing Key(s), the next step is to create a DNSSEC zone. A DNSSEC zone maps a domain name to a set of DNSSEC keys. In the BIG-IP, you create DNSSEC zones by navigating to Global Traffic >> DNSSEC Zone List and create a new zone. On this page, you can name the zone, configure state settings, assign algorithms, and activate zone keys. The hash algorithm options are SHA-1 (default) or SHA-256. The Zone Signing Key box specifies the zone keys that the BIG-IP uses to sign requests to a zone. The Key Signing Key works similar to the Zone Signing Key, except it is used to sign keys instead of requests. The following screenshot shows the options available for creating DNSSEC zones. To fully secure a zone, the parent zone needs to have copies of the child's public key. The parent zone then signs the child's public key with their own key and sends it up to their parent...this pattern is followed all the way to the root zone. Once you have created the DNSSEC keys and zones, you can submit the Delegation Signer (DS) record to the administrators of your parent zone. They will sign the DS record with their own key and upload it to their zone. You can find the DS record for your zone here: /config/gtm/dsset-dnssec.zone.name There's a lot to DNSSEC, and this article wasn't written to capture it all, but I hope it sheds a little light on what DNSSEC is and how you can create zones and keys on your BIG-IP. Stay tuned for more BIG-IP GTM articles in the coming days, weeks, and months. Until then, keep those DNS requests flowing, and make sure they are valid with DNSSEC! One last thing...did you know that F5 has an awesome Reference Architecture dedicated to Intelligent DNS Scale? The F5 Intelligent DNS Scale solution ensures that you can access your critical web, application, and database services whenever you need them...check it out!DNS Express and Zone Transfers
This is the third in a series of DNS articles that I'm writing. The first two are: Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express is a relatively new feature (showed up in v11.1), and it's one of the more powerful features offered by the BIG-IP. DNS Express allows you to transfer DNS zones from your current infrastructure to the BIG-IP. The BIG-IP can then answer requests for those zones...and do it at blazingly fast speeds! Another benefit of DNS Express is that it doesn't run full BIND, so it's not as vulnerable as a typical BIND infrastructure. Related note: as of the date of this article, BIND alone had 71 different CVE vulnerabilities (41 of those were DoS-specific). With all this greatness at our fingertips, I want to show you how to provision the Global Traffic Manager (GTM), create a zone, configure DNS Express, and show a successful zone transfer. I'll be using BIND from the GTM as the Master server (disclaimer: I'm doing this in my virtual lab setup, but you wouldn't normally do this in a production environment). Provision GTM First, navigate to System >> Resource Provisioning and check the box for Global Traffic (GTM). Make sure that this module is licensed (keep in mind that you will have to restart your BIG-IP once you provision GTM). See the screenshot below for details. If GTM is not licensed, then talk to your Sales Engineer. By the way, you can take advantage of our new Good, Better, Best licensing model and save yourself time and money. If you get the "Best" option, then you basically get all the modules F5 has to offer! Create a Listener Once GTM is provisioned, it's time to create a listener for the DNS requests (navigate to Global Traffic >> Listeners). I used the address from my external VLAN as the listener address, but in a production environment you would choose a different listener address. When creating a Listener, you need to choose a DNS Profile that has DNS Express enabled. I verified that DNS Express was enabled on the profile listed below (dns). You can enable/disable options like IPv6 to IPv4 translation, DNS Express, DNSSEC, etc in the DNS profile. So, make sure you configure your DNS profile correctly prior to selecting it when creating a Listener. Configure ZoneRunner Now that the listener is created and configured, you can use the ZoneRunner utility to manage your DNS zones and resource records. You can do several things with ZoneRunner including: configuring a zone configuring the resource records that make up that zone configure a view for access control configure options in the named.conf file I created a master zone and named it "dnstest.com" and then configured the SOA Record and NS Record details (TTL values, server names, etc). I also created two A records (www.dnstest.com and ftp.dnstest.com) and associated IP addresses with each. You can see the details of the zone in the screenshot below: After I created the zone, I configured the Named Configuration file to allow for zone transfer from the local host. You can view/modify the named.conf file directly from the GUI by navigating to Global Traffic >> ZoneRunner >> Named Configuration. The named configuration file will also automatically update as you make changes in the other areas of the ZoneRunner utility, so you don't always have to configure it directly. In my case, I simply viewed the file to ensure the "allow-transfer localhost" was there...and it was! This entry was required for the BIND server to transfer the zone information for dnstest.com to the DNS Express module. In my lab setup, I used BIND from GTM as the Master server, but in a production environment, the Master BIND server would probably reside on an external server. In a typical setup where you host zones external to the BIG-IP, you would have to add the following code to the zone file. In my case, I didn't have to add this code because I set up everything on the BIG-IP. zone "dnstest.com" { type master; file "var/lib/bind/dnstest.com.hosts"; also-notify {1.1.1.1;}; //where 1.1.1.1 is the listener address allow-transfer {1.1.1.2;}; //where 1.1.1.2 is the self IP }; DNS Express DNS Express provides the ability for a BIG-IP to act as a high speed, authoritative secondary DNS server. This allows the BIG-IP to perform zone transfers from multiple primary DNS servers that are responsible for different zones, perform a zone transfer from the local BIND server on the BIG-IP, and serve DNS records faster than the primary DNS servers and the local BIND server. To use DNS Express, you need to create a DNS Express zone. Then, you can transfer zone records from the local BIND server or back-end DNS servers to DNS Express. In order to set up a DNS Express Zone, navigate to Local Traffic >> DNS Express Zones >> DNS Express Zone List and create a new zone. Note that DNS Express is configured under "Local Traffic" as part of the Local Traffic Manager (LTM). The best practice is to use the name that appears at the apex of a BIND zone file (in my case, dnstest.com). The name must begin with a letter and can contain only letters, numbers, and the underscore character (it doesn't have to contain each of these, but it can't contain anything other than these characters). The Target IP Address is for the DNS server from which you want to transfer records. In my setup, I used the default value (127.0.0.1) which is for the BIND server on the BIG-IP. The Notify Action setting of "consume" means that NOTIFY queries are only seen by DNS Express...you can think of it like DNS Express "consumes" all the NOTIFY queries and the backend DNS resources never have to handle them. This is the default setting...and it's awesome! The Test... After everything had been configured, the zone records should have been transferred to DNS Express. In order to test this, I used the "dnsxdump" command from the CLI to verify that all the records were in the DNS Express database. As you can see in the screenshot below, all the records transferred correctly! In addition, I checked out /var/log/ltm to look for the zone transfer message. As you can see in the screenshot below, the zone transfer (AXFR Transfer of zone dnstest.com) succeeded! Now that you know how to configure DNS Express, you have no reason to not use it...so get out there, get it configured, and let the BIG-IP provide you with the best DNS performance you've ever experienced! I also created a quick video showing how to do all the things I just wrote about in this article (provision GTM, create a listener, create a zone, etc). So, if you're more of a "hands-on, visual learner" check out the video...it's located here: https://devcentral.f5.com/s/videos/dns-express-and-zone-transfers Well, that wraps it up for this article. I'll be back soon with more BIG-IP and GTM articles, so check back often!DNS The F5 Way: A Paradigm Shift
This is the second in a series of DNS articles that I'm writing. The first is: Let's Talk DNS on DevCentral. Internet users rely heavily on DNS, and when DNS breaks, applications break. It's extremely important to implement an architecture that provides for DNS availability at all times. It's important because the number of Internet users continues to grow. In fact, a recent study conducted by the International Telecommunications Union claims that mobile devices will outnumber the people living on this planet at some point this year (2014). I'm certainly contributing to those stats as I have a smartphone and a tablet! In addition, the sophistication and complexity of websites are increasing. Many sites today require hundreds of DNS requests just to load a single page. So, when you combine the number of Internet users with the complexity of modern sites, you can imagine that the number of DNS requests traversing your network is extremely large. Verisign's average daily DNS query load during the fourth quarter of 2012 was 77 billion with a peak of 123 billion. Wow...that's a lot of DNS requests...every day! The point is this...Internet use is growing, and the need for reliable DNS is more important than ever. par·a·digm noun \ˈper-ə-ˌdīm\: a group of ideas about how something should be done, made, or thought about Conventional DNS design goes something like this... Front end (secondary) DNS servers are load balanced behind a firewall, and these servers answer all the DNS queries from the outside world. The master (primary) DNS server is located in the datacenter and is hidden from the outside world behind an internal firewall. This architecture was adequate for a smaller Internet, but in today's complex network world, this design has significant limitations. Typical DNS servers can only handle up to 200,000 DNS queries per second per server. Using the conventional design, the only way to handle more requests is to add more servers. Let's say your organization is preparing for a major event (holiday shopping, for example) and you want to make sure all DNS requests are handled. You might be forced to purchase more DNS servers in order to handle the added load. These servers are expensive and take critical manpower to operate and maintain. You can start to see the scalability and cost issues that add up with this design. From a security perspective, there is often weak DDoS protection with a conventional design. Typically, DDoS protection relies on the network firewall, and this firewall can be a huge traffic bottleneck. Check out the following diagram that shows a representation of a conventional DNS deployment. It's time for a DNS architecture paradigm shift. Your organization requires it, and today's Internet demands it. F5 Introduces A New Way... The F5 Intelligent DNS Scale Reference Architecture is leaner, faster, and more secure than any conventional DNS architecture. Instead of adding more DNS servers to handle increased DNS request load, you can simply install the BIG-IP Global Traffic Manager (GTM) in your network’s DMZ and allow it to handle all external requests. The following diagram shows the simplicity and effectiveness of the F5 design. Notice that the infrastructure footprint of this design is significantly smaller. This smaller footprint reduces costs associated with additional servers, manpower, HVAC, facility space, etc. I mentioned the external request benefit of the BIG-IP GTM...here's how it works. The BIG-IP GTM uses F5's specifically designed DNS Express zone transfer feature and cluster multiprocessing (CMP) for exponential performance of query responses. DNS Express manages authoritative DNS queries by transferring zones to its own RAM, so it significantly improves query performance and response time. With DNS Express zone transfer and the high performance processing realized with CMP, the BIG-IP GTM can scale up to more than 10 million DNS query responses per second which means that even large surges of DNS requests (including malicious ones) will not likely disrupt your DNS infrastructure or affect the availability of your critical applications. The BIG-IP GTM is much more than an authoritative DNS server, though. Here are some of the key features and capabilities included in the BIG-IP GTM: ICSA certified network firewall -- you don't have to deploy DMZ firewalls any more...it IS your firewall! Monitors the health of app servers and intelligently routes traffic to the nearest data center using IP Geolocation Protects from DNS DDoS attacks using the integrated firewall services, scaling capabilities, and IP address intelligence Allows you to utilize benefits of cloud environment by flexibly deploying BIG-IP GTM Virtual Edition (VE) Supports DNSSEC with real-time signing and validates DNSSEC responses As you can see, the BIG-IP GTM is a workhorse that literally has no rival in today's market. It's time to change the way we think about DNS architecture deployments. So, utilize the F5 Intelligent DNS Scale Reference Architecture to improve web performance by reducing DNS latency, protect web properties and brand reputation by mitigating DNS DDoS attacks, reduce data center costs by consolidating DNS infrastructure, and route customers to the best performing components for optimal application and service delivery. Learn more about F5 Intelligent DNS Scale by visiting https://f5.com/solutions/architectures/intelligent-dns-scale
Replacing a DNS Server with F5 BIG-IP DNS
First things first, you have decided to deploy F5 BIG-IP DNS to replace a BIND server after receiving notifications from your information assurance officer or your friendly LinkedIn community that additional CVE's have been identified for the version of BIND you are running. In this particular instance you already have a BIG-IP in your DMZ acting as your reverse proxy. You have purchased the best bundle though have only deployed what you know, APM and LTM (common scenario). After upgrading to version 13 after its release in February 2017 and then determining the latest hotfix using https://support.f5.com/csp/article/K9502, you navigate within the TMUI to System > Resource Provisioning and simply provision DNS. Once complete you will need to configure your existing BIND server to allow zone transfers to the BIG-IP. In this case, we will define a self-IP on the BIG-IP. Without the BIG-IP Self IP Defined "allow-transfer { localhost;};" With the BIG-IP Self IP Defined "allow-transfer { localhost; 10.10.10.2;};" Once you have allowed the zone transfer, you will create the zone on the BIG-IP and perform the zone transfer. On the Main tab, click DNS > Zones > ZoneRunner > Zone List . The Zone List screen opens. Click Create.The New Zone screen opens. From the View Name list, select the view that you want this zone to be a member of. Note: The default view is external. In the Zone Name field, type a name for the zone file in this format, including the trailing dot: db.[viewname].[zonename]. For example, db.external.lyons.demo.com. From the Zone Type list, select Master. From the Records Creation Method list, select Transfer from Server. Within Options, include the following allow-update { localhost;}; allow-transfer { localhost; }; also-notify { ::1 port 5353; }; In the Records Creation area, type the values for the SOA and NS record parameters. Click Finished Ok, so you might be asking yourself right about now, "I thought ZoneRunner was a BIND instance?" In this scenario you are correct which is why we are going to slave from on-box BIND to ensure BIND is never accessible externally and we only respond to DNS queries using DNSExpress. Now can you slave from an off-box DNSExpress instance, of course though that is outside the scope of this article. Prior to creating our DNS profile and listeners, we are going to configure DNS logging. For this use case, we are going to configure logging to the on-box syslog instance. In the GUI, navigate to: System > Logs > Configuration > Log Publishers: Create Create a new DNS Log Publisher using the defaults unless defined below. Name: dns-local-syslog Destinations: Move local-syslog to the Selected column In the GUI, navigate to: DNS > Delivery > Profiles > Other > DNS Logging: Create Create a new DNS Profile using the defaults unless defined below. Name: dns-logging Log Publisher: Select dns-local-syslog Log Responses: Enabled Include Query ID: Enabled Note: For the purposes of this article, we are going to enable all DNS logging options. Now that we have logging set up to use by our DNS profile, we are going to going ahead and create that object. In the GUI, navigate to: DNS > Delivery > Profiles > DNS: Create Create a new DNS profile as shown in the table below. Keep the defaults if not noted in the table. Name: AuthoritativeNS Unhandled Query Action: Drop Use BIND Server on Big-IP: Disabled Logging: Enabled Logging Profile: dns-logging Now that we have created our DNS profile, we are going create our DNS listeners. Remember, F5 is a default deny device so without creating something to listen on all attempts to connect to or query the BIG-IP will be denied. We are going to create external Listeners that will be our target IP address when querying BIG-IP DNS. In the GUI, navigate to: DNS > Delivery > Listeners > Listener List: Create Create a two new listeners using the defaults unless defined below. Name: external-listener-UDP Destination: Host: 10.1.100.53 VLAN Traffic: Enabled on.. VLANs and Tunnels: external DNS Profile: AuthoritativeNS Name: external-listener-TCP Destination: Host: 10.1.100.53 VLAN Traffic: Enabled on.. VLANs and Tunnels: external Protocol: TCP DNS Profile: AuthoritativeNS So up to this point we have configured your legacy DNS server to perform a DNS transfer with the BIG-IP, created a zone within ZoneRunner, performed the zone transfer from your legacy DNS device, created a DNS profile and listeners on the BIG-IP. Ok, bear with me we are almost done. Our next step is configuring the local device as a name server and then create a DNSExpress zone that you will be performing a zone transfer to using the on-box BIND instance. So let's begin. In the GUI, navigate to: DNS > Delivery > Nameservers > Nameserver List: Create In this case we will simply provide a Name and leave all other defaults. Name: BIG-IP1 Select Finish In the GUI, navigate to: DNS > Zones > Zones > Zone List: Create Name: lyons.demo.com Server: BIG-IP1 Notify Action: Consume Verify Notify TSIG: Uncheck Zone Transfer Clients: Move BIG-IP1 from Available to Active Select Finish In the GUI, navigate to: DNS > Zones > Zones > Zone List: Create Name: 198.199.10.in-addr.arpa Server: BIG-IP1 Notify Action: Consume Verify Notify TSIG: Uncheck Zone Transfer Clients: Move BIG-IP1 from Available to Active Select Finish Now, our final step...validation. From the cli, simply run a dnsxdump to ensure records have been transferred to DNSExpress as shown below. If you would like to see zone transfers in actions, simply create a resource record within ZoneRunner and run a tail -f on the /var/log/ltm. You are now complete and have a fully functional authoritative DNS server for your organization without the vulnerabilities of BIND or in an effort to simply consolidate services. If you have any problems at all, please don't ever hesitate to reach out directly. Now my answer may be contact support though I have no problem walking through a scenario or troubleshooting attempt with you. Reference Documentation https://support.f5.com/kb/en-us/products/big-ip-dns/manuals/product/bigip-dns-implementations-13-0-0/6.html https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-dns-services-implementations-13-0-0/1.htmlDNS Caching
I've been writing some DNS articles over the past couple of months, and I wanted to keep the momentum going with a discussion on DNS Caching. As a reminder, my first five articles are: Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express and Zone Transfers The BIG-IP GTM: Configuring DNSSEC DNS on the BIG-IP: IPv6 to IPv4 Translation We all know that caching improves response time and allows for a better user experience, and the good news is that the BIG-IP is the best in the business when it comes to caching DNS requests. When a user requests access to a website, it's obviously faster if the DNS response comes directly from the cache on a nearby machine rather than waiting for a recursive lookup process that spans multiple servers. The BIG-IP is specifically designed to quickly and efficiently respond to DNS requests directly from cache. This cuts down on administrative overhead and provides a better and faster experience for your users. There are three different types of DNS caches on the BIG-IP: Transparent, Resolver, and Validating Resolver. In order to create a new cache, navigate to DNS >> Caches >> Cache List and create a new cache (I'm using v11.5). Let's check out the details of each one! Transparent Resolver When the BIG-IP is configured with a transparent cache, it uses external DNS resolvers to resolve DNS queries and then cache the responses from the resolvers. Then, the next time the BIG-IP receives a query for a response that exists in cache, it immediately returns the response to the user. Transparent cache responses contain messages and resource records. The diagram below shows a transparent cache scenario where the BIG-IP does not yet have the response to a DNS query in its cache. In this example, the user sends a DNS query, but because the BIG-IP does not have a response cached, it transparently forwards the query to the appropriate external DNS resolver. When the BIG-IP receives the response from the resolver, it caches the response for future queries. A big benefit of transparent caching is that it consolidates content that would otherwise be cached across many different external resolvers. This consolidated cache approach produces a much higher cache hit percentage for your users. The following screenshot shows the configuration options for setting up a transparent cache. Notice that when you select the "Transparent" Resolver Type, you simply configure a few DNS Cache settings and you're done! The Message Cache Size (listed in bytes) is the maximum size of the message cache, and the Resource Record Cache Size (also listed in bytes) is the maximum size of the resource record cache. Pretty straightforward stuff. The "Answer Default Zones" setting is not enabled by default; meaning, it will pass along DNS queries for the default zones. When enabled, the BIG-IP will answer DNS queries for the following default zones: localhost, reverse 127.0.0.1 and ::1, and AS112. The "Add DNSSEC OK Bit On Miss" setting is enabled by default., and simply means that the BIG-IP will add the DNSSEC OK bit when it forwards DNS queries. Adding this bit indicates to the server that the resolver is able to accept DNSSEC security resource records. Resolver Whereas the Transparent cache will forward the DNS query to an external resolver, the "Resolver" cache will actually resolve the DNS queries and cache the responses. The Resolver cache contains messages, resource records, and the nameservers that the BIG-IP queries to resolve DNS queries. The screenshot below shows the configuration options for setting up a Resolver cache. When you select the Resolver cache, you will need to select a Route Domain Name from the dropdown list. This specifies the route domain that the resolver uses for outbound traffic. The Message Cache Size and Resource Record Cache Size are the same settings as in Transparent cache. The Name Server Cache Count (listed in entries) is the maximum number of DNS nameservers on which the BIG-IP will cache connection and capability data. The Answer Default Zones is the same setting as described above for the Transparent cache. As expected, the Resolver cache has several DNS Resolver settings. The "Use IPv4, IPv6, UDP, and TCP" checkboxes are fairly straightforward. They are all enabled by default, and they simply specify whether the BIG-IP will answer and issue queries in those specific formats. The "Max Concurrent UDP and TCP Flows" specifies the maximum number of concurrent sessions the BIG-IP supports. The "Max Concurrent Queries" is similar in that it specifies the maximum number of concurrent queries used by the resolver. The "Unsolicited Reply Threshold" specifies the number of replies to DNS queries the BIG-IP will support before generating an SNMP trap and log message as an alert to a potential attack. DNS cache poisoning and other Denial of Service attacks will sometimes use unsolicited replies as part of their attack vectors. The "Allowed Query Time" is listed in milliseconds and specifies the time the BIG-IP will allow a query to remain in the queue before replacing it with a new query when the number of concurrent distinct queries exceeds the limit listed in the "Max Concurrent Queries" setting (discussed above). The "Randomize Query Character Case" is enabled by default and will force the BIG-IP to randomize the character case (upper/lower) in domain name queries issued to the root DNS servers. Finally, the "Root Hints" setting specifies the host information needed to resolve names outside the authoritative DNS domains. Simply input IP addresses of the root DNS servers and hit the "add" button. Validating Resolver The Validating Resolver cache takes things to the next level by recursively querying public DNS servers and validating the identity of the responding server before caching the response. The Validating Resolver uses DNSSEC to validate the responses (which mitigates DNS attacks like cache poisoning). For more on DNSSEC, you can check out my previous article. The Validating Resolver cache contains messages, resource records, the nameservers that the BIG-IP queries to resolve DNS queries, and DNSSEC keys. When an authoritative server signs a DNS response, the Validating Resolver will verify the data prior to storing it in cache. The Validating Resolver cache also includes a built-in filter and detection mechanism that rejects unsolicited DNS responses. The screenshot below shows the configuration options for setting up a Validating Resolver cache. I won't go into detail on all the settings for this page because most of them are identical to the Validating Resolver cache. However, as you would expect, there are a few extra options in the Validating Resolver cache. The first is found in the DNS Cache settings where you will find the "DNSSEC Key Cache Size". This setting specifies the maximum size (in bytes) of the DNSKEY cache. The DNS Resolver settings are identical to the Resolver cache. The only other difference is found in the DNSSEC Validator settings. The "Prefetch Key" is enabled by default and it specifies that the BIG-IP will fetch the DNSKEY early in the validation process. You can disable this setting if you want to reduce the amount of resolver traffic, but also understand that, if disabled, a client might have to wait for the validating resolver to perform a key lookup (which will take some time). The "Ignore Checking Disabled Bit" is disabled by default. If you enable this setting, the BIG-IP will ignore the Checking Disabled setting on client queries and will perform response validation and only return secure answers. Keep in mind that caching is a great tool to use, but it's also good to know how much space you are willing to allocate for caching. If you allocate too much, you might serve up outdated responses, but if you allocate too little, you will force your users to wait while DNS recursively asks a bunch of servers for information you could have been holding all along. In the end, it's a reminder that you should know how often your application data changes, and you should configure these caching values accordingly. Well, that does it for this edition of DNS caching...stay tuned for more DNS goodness in future articles!DNS Interception: Protecting the Client
Introduction Everything starts with a DNS request. So why not use it to protect the client? With the recent addition of Secure Web Gateway Services to the F5 line up of modules in TMOS 11.5, it provided the ability to access a URL Categorization database via iRules that contains 150 URL categories and identifies over 60 million URLs. Pair that with the IP Intelligence Services that was introduced in TMOS 11.2 and some DNS iRules, you now have a solution to filter all DNS Requests and Reponses originating from your network. This simple but powerful tool gives you the ability to protect clients which you may not have control over by sending back a Non-Existent Domain in the response to prevent the client from connecting to the malicious server or undesirable content. This iRule solution is applied to a DNS resolver or a catch all (0.0.0.0/0:53) DNS virtual server where the BIG-IP is a default gateway. It allows the BIG-IP to explicitly or transparently intercept all DNS Requests and Responses from the client and apply security filtering controls. This solution is suited to almost any outbound DNS scenario where you need to protect the client from accessing malicious threats or undesirable content intentionally or unintentionally. One example where you may find this solution handy, is on a Guest or BYOD network where you need a transparent method of adding security when you don’t have control of the client. How the solution works Scenario 1: The BIG-IP is configured as a DNS resolver and the client’s DNS settings have been configured via DHCP with the IP of the BIG-IP as the LDNS. Scenario 2: The BIG-IP is a default gateway on the network and a catch all (0.0.0.0/0:53) DNS virtual server transparently intercepts all DNS Requests an Responses. The client’s DNS settings have been configured via DHCP with the IP of a LDNS that has to traverse the BIG-IP. Scenario 3: The BIG-IP is a default gateway on the network and a catch all (0.0.0.0/0:53) DNS virtual server transparently intercepts all DNS Requests an Responses. The client’s DNS settings have been configured via DHCP or manually with a public DNS service (e.g Google, Open DNS, etc.) an the client has to traverse the BIG-IP. The “client” in the above scenarios doesn’t have to be an end user device such as a tablet, it could be a forward proxy server for example. The iRule is applied to the virtual server (VS) with a DNS profile and the events DNS_REQUEST and DNS_RESPONSE are triggered. When the DNS_REQUEST is triggered, the DNS Question Name is passed to the URL Categorization database using CATEGORY::lookup. When the DNS_RESPONSE is triggered, the IP address in the DNS Response can be passed to IP Intelligence database using IP::reputation. Solution Features DNS Request Filtering configurable items: DNS Request Filtering - Enable or Disable all DNS_REQUEST filtering. URL Categories e.g. Adult_Content, Hacking. If the DNS Question (FQDN - e.g. playboy.com) matches a category in the data group (default: dns_request_url_categories_dg), NXDOMAIN will be returned in the response. DNS Question Type e.g. A, AAAA, ANY etc. Only the Question Types configured in the data group (default: dns_request_question_type_dg) will be filtered. FQDN/TLD Whitelist e.g. f5.com or .gov. Any FQDN/TLD in the whitelist data group (default: dns_request_fqdn_whitelist_dg) will bypass DNS_REQUEST filtering regardless of the Question Type or URL Category. DNS Response Filtering configurable items: DNS Response Filtering - Enable or Disable all DNS_RESPONSE filtering. IP/Subnet Whitelist e.g 192.168.0.0/16 or 1.1.1.1. Any IP or IP Subnet in the whitelist data group will bypass DNS_RESPONSE filtering. IPI Threat Categories e.g. Spam Sources, Phishing. If the DNS RDATA (A & AAAA only) matches a category in the data group, NXDOMAIN will be returned in the response. Global Parameters Logging Control - Off, Level 1 (NXDOMAIN and Whitelist Matching) and Level 2 (All DNS Requests & Responses) Requirements - BIG-IP Version / Licensing BIG-IP 11.2+ for IPI Subscription (DNS Response filtering) BIG-IP 11.5+ for URL Categorization or SWG Subscription (DNS Request filtering) Licensing: GTM/DNS or DNS Services add-on to LTM URL Categorization Subscription or SWG Subscription for DNS Request filtering IPI Subscription for DNS Response filtering Configuration 1. Data Groups Multiple data groups are used throughout the solution to make it easy for the administrator to make changes on the fly without having to change the iRule. By default, the following data groups need to be created. The values can be modified to your liking. 1.1 Data Group Name: dns_request_url_categories_dg Purpose: URL Category Names If the DNS Question Name (e.g. playboy.com) matches a category (Adult_Content) in the data group, NXDOMAIN will be returned in the response. To obtain a list of possible URL Categories and their descriptions, run: tmsh list sys url-db url-category { description }. Example categories are included below. TMSH: create ltm data-group internal dns_request_url_categories_dg type string modify ltm data-group internal dns_request_url_categories_dg records add {"Adult_Content"} modify ltm data-group internal dns_request_url_categories_dg records add {"Advanced_Malware_Command_and_Control"} modify ltm data-group internal dns_request_url_categories_dg records add {"Advanced_Malware_Payloads"} modify ltm data-group internal dns_request_url_categories_dg records add {"Bot_Networks"} modify ltm data-group internal dns_request_url_categories_dg records add {"Compromised_Websites"} modify ltm data-group internal dns_request_url_categories_dg records add {"Elevated_Exposure"} modify ltm data-group internal dns_request_url_categories_dg records add {"Emerging_Exploits"} modify ltm data-group internal dns_request_url_categories_dg records add {"Hacking"} modify ltm data-group internal dns_request_url_categories_dg records add {"Keyloggers"} modify ltm data-group internal dns_request_url_categories_dg records add {"Malicious_Embedded_Link"} modify ltm data-group internal dns_request_url_categories_dg records add {"Malicious_Embedded_iFrame"} modify ltm data-group internal dns_request_url_categories_dg records add {"Malicious_Web_Sites"} modify ltm data-group internal dns_request_url_categories_dg records add {"Militancy_and_Extremist"} modify ltm data-group internal dns_request_url_categories_dg records add {"Mobile_Malware"} modify ltm data-group internal dns_request_url_categories_dg records add {"Newly_Registered_Websites"} modify ltm data-group internal dns_request_url_categories_dg records add {"Nudity"} modify ltm data-group internal dns_request_url_categories_dg records add {"Peer-to-Peer_File_Sharing"} modify ltm data-group internal dns_request_url_categories_dg records add {"Phishing_and_Other_Frauds"} modify ltm data-group internal dns_request_url_categories_dg records add {"Proxy_Avoidance"} modify ltm data-group internal dns_request_url_categories_dg records add {"Sex"} modify ltm data-group internal dns_request_url_categories_dg records add {"Spyware"} modify ltm data-group internal dns_request_url_categories_dg records add {"Tasteless"} modify ltm data-group internal dns_request_url_categories_dg records add {"Web_and_Email_Spam"} 1.2 Data Group Name: dns_request_question_type_dg Purpose: DNS Question Types Only the Question Types (e.g. A, AAAA) configured in the data group will be filtered. Example Question Types are included below. TMSH: create ltm data-group internal dns_request_question_type_dg type string modify ltm data-group internal dns_request_question_type_dg records add {"A"} modify ltm data-group internal dns_request_question_type_dg records add {"AAAA"} modify ltm data-group internal dns_request_question_type_dg records add {"ANY"} modify ltm data-group internal dns_request_question_type_dg records add {"CNAME"} modify ltm data-group internal dns_request_question_type_dg records add {"MX"} 1.3 Data Group Name: dns_request_fqdn_whitelist_dg Purpose: FQDN / TLD Whitelisting Any FQDN/TLD (e.g. f5.com or .gov) in the whitelist data group will bypass DNS_REQUEST filtering regardless of the Question Type or URL Category. Example Question Types are included below. TMSH: create ltm data-group internal dns_request_fqdn_whitelist_dg type string modify ltm data-group internal dns_request_fqdn_whitelist_dg records add {"f5.com"} 1.4 Data Group Name: dns_response_ip_whitelist_dg Purpose: IP / Subnet Whitelisting Any IP or IP Subnet in the whitelist data group will bypass DNS_RESPONSE filtering regardless of the IP Reputation. TMSH: create ltm data-group internal dns_response_ip_whitelist_dg type ip modify ltm data-group internal dns_response_ip_whitelist_dg records add {"10.0.0.0/8"} modify ltm data-group internal dns_response_ip_whitelist_dg records add {"172.16.0.0/12"} modify ltm data-group internal dns_response_ip_whitelist_dg records add {"192.168.0.0/16"} 1.5 Data Group Name: dns_response_ipi_categories_dg Purpose: IP Intelligence Category Names TMSH: create ltm data-group internal dns_response_ipi_categories_dg type string modify ltm data-group internal dns_response_ipi_categories_dg records add {"BotNets"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Networks"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Denial of Service"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Illegal"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Infected Sources"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Phishing"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Scanners"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Spam Sources"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Web Attacks"} modify ltm data-group internal dns_response_ipi_categories_dg records add {"Windows Exploits"} 2. iRule iRule Name: dns_request_response_filter_irule -> https://devcentral.f5.com/s/articles/dns-request-and-response-filtering-using-url-db-and-ipi-subscriptions The iRule is applied to the DNS resolver or a catch all (0.0.0.0/0:53) DNS virtual server. The logic is explained below and has been built to cater for most situations. Simply save the iRule to the BIG-IP using the Codeshare link above. DNS Request iRule logic: DNS Response iRule logic: 3. Virtual Servers, Pools, Nodes and DNS Profile 3.1 BIG-IP as a DNS Resolver (Scenario 1) When the BIG-IP is configured as a DNS Resolver, you need to configure a LDNS for the BIG-IP to resolve the requests. In my example I’m using Google’s public DNS servers. Make sure you change the Virtual Server IP and/or any other settings to suit your environment. TMSH: create ltm node google-public-dns-a { address 8.8.8.8 } create ltm node google-public-dns-b { address 8.8.4.4 } create ltm pool google_dns_pool { members replace-all-with { google-public-dns-a:domain google-public-dns-b:domain } } create ltm profile dns dns_interception { cache none defaults-from dns dns64 disabled dns-security none enable-cache no enable-dns-express no enable-dns-firewall no enable-dnssec no enable-gtm no enable-logging no process-rd yes process-xfr no unhandled-query-action allow use-local-bind no } create ltm virtual dns_resolver_udp_vs { destination 10.1.1.1:domain ip-protocol udp profiles replace-all-with { udp_gtm_dns dns_interception } source-address-translation { type automap } rules { dns_request_response_filter_irule } pool google_dns_pool } 3.2 BIG-IP is a default gateway (Scenario 2 and 3) When the BIG-IP is configured as a default GW, you only need to configure the catch all (0.0.0.0/0:53) DNS virtual server and the DNS Profile. Make sure you change the VLAN and/or any other settings to suit your environment. TMSH: create ltm profile dns dns_interception { cache none defaults-from dns dns64 disabled dns-security none enable-cache no enable-dns-express no enable-dns-firewall no enable-dnssec no enable-gtm no enable-logging no process-rd yes process-xfr no unhandled-query-action allow use-local-bind no } create ltm virtual catch_all_dns_udp_vs { destination 0.0.0.0:domain ip-protocol udp profiles replace-all-with { udp_gtm_dns dns_interception } vlans-enabled vlans replace-all-with { vlan1 } rules { dns_request_response_filter_irule } translate-address disabled } Conclusion By combining threat intelligence services with DNS, produces a simple and effective protection in a IoT world.Why an Empty Glass is like a Key Mobile Service Provider Technology
"Speedy Gonzales (1955 short)" by Source (WP:NFCC#4) #MWC15 I was at a restaurant with some colleagues after the day of Mobile World Congress events today in Barcelona. Unfortunately, all the Spanish I learned was from the Warner Bros Speedy Gonzales cartoons. The people of Barcelona are great and most of them have a superb command of the English language. While we were ordering and eating our tapas which we selected off of the menu of options, one of our servers came by to refill our water glasses. I took this opportunity to ask the server for a separate empty glass so I could take some medicine I needed to mix with the water. The server looked at me with a puzzled look and I tried to explain again. ‘Please bring a cup. Empty,” I said as I used hand gestures to simulate an empty glass with the one he had just filled. Again, he gave me a look that signified he did not understand. “Cup. Empty,” I stated once again. He nodded this time and walked off. A minute later he was back with no cup, but our waiter was with him. The waiter said, “I am sorry. He does not understand you. What do you need?” “An empty cup, please.” I held up the medicine packet to show him why I needed it. “Ah. No problem. One moment.” And off they went as the waiter explained to the young gentleman what I needed. Finally, the server arrived with my empty glass. This brings up one of the issues that mobile service providers have that we sometimes gloss over or sweep under the table knowing it is being resolved in the future. The LTE networks need translation services like my waiter provided. Not for English or Spanish, but to switch the conversation from IPv6 to IPv4 and back again. The problem is that LTE networks are architected to use IPv6 addresses using 128 bits of IP address space while the Internet is still mostly IPv4, using 32 bits for each IP address. In addition, many service provider networks are not fully IPv6 either and they need this IP translation service to support the communications through their own infrastructure. Most LTE capable phones are designed to support IPv6. The Internet of Things, when it blows up to 50 billion devices by 2020 will have things with IPv6 addresses. This is necessary because there are not enough IPv4 addresses to support all of these devices. A carrier grade network address translation (CGNAT) solution is needed to provide IP address translation capabilities within the network. CGNAT may not have the buzz of IoT, nor does it have the public momentum of NFV, but it is still an essential technology to incorporate until the service provider networks and Internet fully support IPv6 addresses. CGNAT is deployed in most service provider networks to some extent, but it functionality and performance needs to be expanded to support this surge of new devices connecting to the LTE networks. A complimentary technology that I would be remiss to omit when talking about CGNAT is DNS64 services. DNS64 is the mapping of DNS addresses in IPv4 format to IP addresses in IPv6 format. This is critical because DNS is all about the mapping of names, or fully qualified domain names (FQDNs) to IP addresses which will be either IPv4 or IPv6. Service providers need to keep the CGNAT technologies in mind as they continue to build and expand their LTE networks, especially with the popularity of IoT. In my instance, I was lucky that I had my waiter to provide translation services between Spanish and English. The long term solution is for the server and/or me to learn each other’s respective languages. Only then will the waiter not be needed to always be around so we can have a conversation. In the service provider’s network the CGNAT solution (with DNS64) will always be needed until all of the devices and the Internet support a common a language, IPv6.
Mitigating Unwanted Communication On Your Service Network
With so many new and varied devices such as smartphones, smartwatches, laptops, and tablets accessing a service provider network, with a 2.9 device per-person average worldwide according to a Sophos survey, it’s no wonder there is Operator concern with supporting only desired and approved communication. And with the total number of devices growing to 5 per internet user by 2017 according to Cisco, Service Provider network traffic is going to continue to increase…dramatically. What will Operators connect to their network next? All these new device clients connected to the internet need a secure DNS (Domain Name System) architecture for reliable responses to where that desired service is available. So as the internet of things (IoT) turns into the internet of everything with not just people to machines but machines to machines, with BYOX anything, and with wearables connected to the internet, there are exponentially more chances of malicious traffic accessing a fixed and wireless network. Recently, HP released an Internet of Things study noting 70% of IoT devices were vulnerable to attack with an average of 25 vulnerabilities per product. In a recent IDG Research survey sponsored by F5, 66% of network managers in charge of DNS services were highly concerned about Security…and, rightly so. The growth of services for subscribers to access means more opportunities for attackers to introduce malware and viruses. When a subscriber selects a service, downloads data, views a webpage, or clicks on a browser link, there is a possibility that the response contains malware or viruses unknown to the subscriber. Once a data transfer happens, possible infections occur undetected. Is that a filter or a firewall? To keep your services at peak performance for the best subscriber usage and service availability, malicious communication from rogue programs and web sites must be blocked in your network. Many DNS offerings optionally protect from malicious communication by providing outbound domain filtering, although, it’s commonly called a DNS Firewall. The actual feature is referred to as Response Policy Zones (RPZ), and it helps filter out domains with reputations for malicious activity. Those offerings, that let you choose a domain filtering service and import the database of IP addresses for blocking, give you the most flexibility in customizing where your users and those pesky viruses are able to navigate. RPZ should be a part of an overall strategy of securing your network landscape. Mitigating unwanted communication on your service network When you want to start filtering domains out of your network communication, solutions like BIG-IP Global Traffic Manager (GTM) with DNS security, scale, performance, and control provides DNS firewall benefits including domain filtering with RPZ. You can lower your risk of malware and virus communications on your service provider network and mitigate DNS threats by blocking access to malicious IP domains of your choice using a domain reputation service imported into BIG-IP GTM. In addition, with high speed logging and reporting of blocked domains, you now know which clients on your network have potential infections for rapid inspection and reduction of infection resolution costs. By mitigating unwanted communication, BIG-IP increases service performance for subscribers with the desired traffic traversing your network. The BIG-IP platform is ICSA certified for network security, and it’s easy to select various DNS security services to increase your overall posture. So now you have confidence and control in allowing more Internet of Things to connect with your services while you filter out and mitigate malicious communications. Related: Mobile World Congress 2015: Threats to Mobile Carrier Networks (video) F5 Intelligent DNS - Optimizing the Mobile Core To learn more about how F5 BIG-IP Service Provider solutions support DNS and service performance, visit: Intelligent DNS for Service Providers and Scalable, Secure DNS and Global App Services
