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!
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.html
Export GTM/DNS Configuration in CSV - tmsh cli script
Problem this snippet solves: This is a simple cli script used to collect all the WideIP, LB Method, Status, State, Pool Name, Pool LB, Pool Members, Pool Fall back, Last Resort pool info in CSV format. A sample output would be like below, One can customize the code to extract other fields available too. Check out my other codeshare of LTM report. Note: The codeshare may get multiple version, use the latest version alone. The reason to keep the other versions is for end users to understand & compare, thus helping them to modify to their own requirements. Hope it helps. How to use this snippet: Login to the GTM/DNS, create your script by running the below commands and paste the code provided in snippet, tmsh create cli script gtm-config-parser Delete the proc blocks, so it looks something like below, create script gtm-config-parser { ## PASTE THE CODE HERE ## } and paste the code provided in the snippet. Note: When you paste it, the indentation may be realigned, it shouldn't cause any errors, but the list output would show improperly aligned. Feel free to delete the tab spaces in the code snippet & paste it while creating, so indentation is aligned properly. And you can run the script like below, tmsh run cli script gtm-config-parser > /var/tmp/gtm-config-parser-output.csv And get the output from the saved file, open it on excel. Format it & use it for audit & reporting. cat /var/tmp/gtm-config-parser-output.csv Feel free to add more elements as per your requirements. For version 13.x & higher, there requires a small change in the code. Refer the comments section. Thanks to @azblaster Code : proc script::run {} { puts "WIP,LB-MODE,WIP-STATUS,WIP-STATE,POOL-NAME,POOL-LB,POOL-MEMBERS,POOL-FB,LASTRESORT-POOL" foreach { obj } [tmsh::get_config gtm wideip all-properties] { set wipname [tmsh::get_name $obj] set wippools [tmsh::get_field_value $obj pools] set lbmode [tmsh::get_field_value $obj "pool-lb-mode"] set lastresort [tmsh::get_field_value $obj "last-resort-pool"] foreach { status } [tmsh::get_status gtm wideip $wipname] { set wipstatus [tmsh::get_field_value $status "status.availability-state"] set wipstate [tmsh::get_field_value $status "status.enabled-state"] } foreach wippool $wippools { set pool_name [tmsh::get_name $wippool] set pool_configs [tmsh::get_config /gtm pool $pool_name all-properties] foreach pool_config $pool_configs { set pool_lb [tmsh::get_field_value $pool_config "load-balancing-mode"] set pool_fb [tmsh::get_field_value $pool_config "fallback-mode"] if { [catch { set member_name [tmsh::get_field_value $pool_config "members" ]} err] } { set pool_member $err } else { set pool_member "" set member_name [tmsh::get_field_value $pool_config "members"] foreach member $member_name { append pool_member "[lindex $member 1] " } } puts "$wipname,$lbmode,$wipstatus,$wipstate,$pool_name,$pool_lb,$pool_member,$pool_fb,$lastresort" } } } } Tested this on version: 11.6The 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!
Unable to SSH BIG IP F5 GTM
Hi, I have a F5 BIGIP GTM box. I am able to access its GUI. However I am unable to access it via SSH Via doing a SSH via Putty just a black screen appears and nothing else happens. Please if someone can suggest any solution I have checked and my IP address is allowed in the Allowable IP's for SSHDNS 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!
GTM - Topology load balancing failover when one pool is down
Hello All, I am looking for a solution to the problem that has been raised several times, but I do not find a confirmed solution. The situation I am in is described in the following post: GTM Topology across pools issue when one of the po... - DevCentral (f5.com) We have two topology records with the same source, but different destination pools, with different wights: SRC: Region X => DEST: Pool A, wieght 200 SRC: Region X => DEST: Pool B, Wieght 20 When Pool A is down the Topology load balancing for the Wide IP still selects Pool A which is down, and no IP is returned to the client. If the topology load balancing selection mechanism, is not going to take in the status of the destination pool and just stop on first match in its selection mechanism, then why have "Wieght" at all. I do no believe disabling "longest match" would help as this just affects the order the topology rules are searched, it woudl still stop with the first match. The often mentioned solution is to use a single pool with Global Availability load balancing, as mentioned in the post: GTM and Topology - DevCentral (f5.com). The problem I have is that Pool A and Pool B are pools with mulitple generic host servers. I cannot have a pool with all generic host in it as we want to memebers in each Pool are Active/Active and not Active/ Backup Many thanks, Michael
GTM Wideip and pool persistence
Hi there , please help me understand the gtm wideip and pool persistence, gtm wideip persistence — this tells a specific user how long you will stick with the same pool member for dns queries gtm pool TTL: this tells the specific user, how often you would need to query the gtm for dns resolution, for instance, if I connect to a wideip and gets a pool member as response, 10.10.10.10, assume that I have enabled wideip persistence as 3600 s, and pool ttl as 15 sec, I will likely to get 10.10.10.10 for 1 hr, but for every 15 seconds a dns requests sends to wideip to see if the member is still active, is this accurate understanding? please confirmHigh CPU utilization (100%).
I observed high CPU utilization (100%) on F5 device, resource provision ASM nominal. I checked the client-side throughput and server-side throughput both are normal but found management interface throughput is very high and what i noticed this is happening in same time period for last 30 days. What could be the reason for this spike. Many thanks in advanced for your time and consideration.
