What Is BIG-IP?
tl;dr - BIG-IP is a collection of hardware platforms and software solutions providing services focused on security, reliability, and performance. F5's BIG-IP is a family of products covering software and hardware designed around application availability, access control, and security solutions. That's right, the BIG-IP name is interchangeable between F5's software and hardware application delivery controller and security products. This is different from BIG-IQ, a suite of management and orchestration tools, and F5 Silverline, F5's SaaS platform. When people refer to BIG-IP this can mean a single software module in BIG-IP's software family or it could mean a hardware chassis sitting in your datacenter. This can sometimes cause a lot of confusion when people say they have question about "BIG-IP" but we'll break it down here to reduce the confusion. BIG-IP Software BIG-IP software products are licensed modules that run on top of F5's Traffic Management Operation System® (TMOS). This custom operating system is an event driven operating system designed specifically to inspect network and application traffic and make real-time decisions based on the configurations you provide. The BIG-IP software can run on hardware or can run in virtualized environments. Virtualized systems provide BIG-IP software functionality where hardware implementations are unavailable, including public clouds and various managed infrastructures where rack space is a critical commodity. BIG-IP Primary Software Modules BIG-IP Local Traffic Manager (LTM) - Central to F5's full traffic proxy functionality, LTM provides the platform for creating virtual servers, performance, service, protocol, authentication, and security profiles to define and shape your application traffic. Most other modules in the BIG-IP family use LTM as a foundation for enhanced services. BIG-IP DNS - Formerly Global Traffic Manager, BIG-IP DNS provides similar security and load balancing features that LTM offers but at a global/multi-site scale. BIG-IP DNS offers services to distribute and secure DNS traffic advertising your application namespaces. BIG-IP Access Policy Manager (APM) - Provides federation, SSO, application access policies, and secure web tunneling. Allow granular access to your various applications, virtualized desktop environments, or just go full VPN tunnel. Secure Web Gateway Services (SWG) - Paired with APM, SWG enables access policy control for internet usage. You can allow, block, verify and log traffic with APM's access policies allowing flexibility around your acceptable internet and public web application use. You know.... contractors and interns shouldn't use Facebook but you're not going to be responsible why the CFO can't access their cat pics. BIG-IP Application Security Manager (ASM) - This is F5's web application firewall (WAF) solution. Traditional firewalls and layer 3 protection don't understand the complexities of many web applications. ASM allows you to tailor acceptable and expected application behavior on a per application basis . Zero day, DoS, and click fraud all rely on traditional security device's inability to protect unique application needs; ASM fills the gap between traditional firewall and tailored granular application protection. BIG-IP Advanced Firewall Manager (AFM) - AFM is designed to reduce the hardware and extra hops required when ADC's are paired with traditional firewalls. Operating at L3/L4, AFM helps protect traffic destined for your data center. Paired with ASM, you can implement protection services at L3 - L7 for a full ADC and Security solution in one box or virtual environment. BIG-IP Hardware BIG-IP hardware offers several types of purpose-built custom solutions, all designed in-house by our fantastic engineers; no white boxes here. BIG-IP hardware is offered via series releases, each offering improvements for performance and features determined by customer requirements. These may include increased port capacity, traffic throughput, CPU performance, FPGA feature functionality for hardware-based scalability, and virtualization capabilities. There are two primary variations of BIG-IP hardware, single chassis design, or VIPRION modular designs. Each offer unique advantages for internal and collocated infrastructures. Updates in processor architecture, FPGA, and interface performance gains are common so we recommend referring to F5's hardware pagefor more information.Using Client Subnet in DNS Requests
BIG-IP DNS 14.0 now supports edns-client-subnet (ECS) for both responding to client requests (GSLB) or forwarding client requests (screening). The following is a quick start on using this feature. What is EDNS-Client-Subnet (ECS) If you are familiar with X-Forwarded-For headers in HTTP requests,ECS solves a similar problem. The problem is how to forward a DNS request through a proxy and preserve information about the original request (IP Address). Some of this discussion I also cover in a previous article,Implementing Client Subnet in DNS Requests . Traditional DNS Requests When a traditional DNS request is made, a client makes a request to a “local” DNS server (LDNS), and that request is forwarded to the authoritative DNS server for that domain. When a topology (send different responses based on the source address) record is evaluated it will use the source IP of the LDNS server. Usually this is OK for most applications, but it would be ideal to be able to forward more precise information from the LDNS server. ECS DNS Requests Using ECS a LDNS server can inject additional meta-data about the request that includes information about the source IP address of the client. In the following example a “Client Subnet” of 192.0.2.0/24 is forwarded to the DNS server. ECS on BIG-IP DNS F5 BIG-IP DNS can use ECS in two ways. Use ECS when handling topology requests Inject ECS when “screening” a DNS server Using ECS with BIG-IP DNS Topology There are two methods of configuring BIG-IP DNS to use ECS. Either at the wide-ip or globally. To configure ECS on a wide-ip: To configure ECS globally. Under DNS Settings. Injecting ECS records BIG-IP DNS can also proxy requests to other DNS servers (BIG-IP DNS or other vendors). When you modify the DNS profile to insert an ECS record. You will observe that the original /32 address will be forwarded to any DNS servers that are in the pool for that particular Virtual Server. The following is a diagram of the above.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!What is BIG-IP DNS?
tl;dr - BIG-IP DNS provides global load balancing (GSLB), DNS services, and basic DDoS protection features. By now we all understand the concepts behind load balancing; creating a virtual access point to distribute traffic across multiple resources. Keeping that idea in mind the next question is how do we advertise our application available across separate data centers? BIG-IP DNS (formerly Global Traffic Manager or GTM) first and foremost is a global load balancer for DNS queries. Using similar algorithms for load balancing decision made by BIG-IP Local Traffic Manager (LTM), BIG-IP DNS routes your DNS traffic to the best suited datacenter either on premise, co-located, or in your preferred cloud provider. BIG-IP DNS also provides DNS resolution services, including caching and traffic throttling to ensure queries made about your applications are always answered and fast. Vocabulary To understand BIG-IP DNS, we'll first define a few product terms. Wide IP - Owns your services FQDN and responds to listener requests. The Wide IP contains one or more pools which in turn contain one or more virtual servers. Server - In this case, the server defined in BIG-IP DNS is either a BIG-IP or other 3rd party system responsible for owning one or more virtual server service. GSLB - Global Server Load Balancing. The GSLB section within BIG-IP DNS configuration is the core of intelligent DNS resolution services. Listener - BIG-IP uses TCP/UDP listeners to respond to DNS queries. Pool - In BIG-IP DNS a pool contains one or more virtual servers. How BIG-IP DNS Works BIG-IP DNS has grown over the years to incorporate many new features, but we'll stick to discussing the core global server load balancing (GSLB) functionality. Let's first take a look at a traditional DNS query (we're assuming no system has example cached): Client queries www.example.com to local DNS (LDNS) LDNS queries ROOT Servers ROOT Servers send the query to the .com TLD server TLD Servers provide the name server IP for example.com to LDNS server (glue records if you got em) example.com name servers lookup www entry and send to LDNS request LDNS Server returns IP for www.example.com to client Client is now browsing. BIG-IP DNS enters the picture at step 5 and adds a few extra steps: BIG-IP DNS Listener receives the query for example.com The Wide-IP associated to example.com makes a load balancing decision on what pool to send the request to The chosen pool makes a secondary load balancing decision on what virtual server to send the request to The virtual server IP is returned to the originating LDNS server Client is more happy because they were routed to a regionally located server with faster response times. In this scenario, the BIG-IP DNS provided a faster application experience for the user by determining the region the user resided and provided the fastest performing server's as the IP for the FQDN requested by DNS. BIG-IP DNS provides more features to enhance the GSLB features including accelerating DNS resolution and acting as a fast secondary DNS server. Below you can learn more about BIG-IP DNS and as always if you have questions or commentplease let us know. DevCentral Basics - What is DNS? Lightboard Lessons: BIG-IP DNS Load Balancing Intro Lightboard Lessons: DNS Scalability & Security Getting Started with BIG-IP DNS (formerly GTM) @F5 University
Configuring the F5 BIG-IP to Perform Name Resolution Using a DNS Resolver Cache
After feedback on both DevCentral and direct email, it seems as though there is still confusion or a lack of clarity around how to configure the BIG-IP to perform name resolution. A common scenario of my own customers is to configure the BIG-IP as an authoritative DNS server as well as a transparent DNS server that forwards lookups to another source. With that, I wanted to take some time to walk through the steps of configuring the BIG-IP to be a resolving cache DNS server. However, before we get started I wanted to provide the F5 support definition of each cache type provided by the BIG-IP. About the transparent DNS cache You can configure a transparent cache on the BIG-IP® system to use external DNS resolvers to resolve queries, and then cache the responses from the resolvers. The next time the system receives a query for a response that exists in the cache, the system immediately returns the response from the cache. The transparent cache contains messages and resource records. About the resolver DNS cache You can configure a resolver cache on the BIG-IP® system to resolve DNS queries and cache the responses. The next time the system receives a query for a response that exists in the cache, the system returns the response from the cache. The resolver cache contains messages, resource records, and the name servers the system queries to resolve DNS queries. About the validating resolver DNS cache You can configure a validating resolver cache on the BIG-IP® system to recursively query public DNS servers, validate the identity of the DNS server sending the responses, and then cache the responses. The next time the system receives a query for a response that exists in the cache, the system returns the DNSSEC-compliant response from the cache. The validating resolver cache contains messages, resource records, the nameservers the system queries to resolve DNS queries, and DNSSEC keys. Ok, now with that out of the way, let's get started! Prerequisites BIG-IP DNS licensed and provisioned. An external internet route. Create a Resolver Cache Navigate to DNS >> Caches >> Cache List. Click Create. Name: demo_resolver_cache Resolver Type: Resolver Click Finished Note: If Root Hints is left default it will use the F5 defined default root hints. If this is an air-gapped or classified network, you will need to define your network's root hint servers. Also if you plan to use only root hints, you may experience some timeouts during name resolution. To improve name resolution, we will create a Forward Zone which allows us to define another authoritative source to do lookups against. Click the cache created in the previous steps. Click the Forward Zones tab. Click Add. Name: . Nameservers: 8.8.8.8 & 9.9.9.9 Click Finished. Create a DNS Profile Navigate to DNS >> Delivery >> Profiles >> DNS. Click Create. Name: demo_dns_profile DNS Cache: Enabled DNS Cache Name: demo_resolver_cache Use BIND Server on BIG-IP: Disabled Click Finished. Create a DNS Listener Navigate to DNS >> Delivery >> Listeners >> Listener List. Click Create. Name: demo_dns_listener Destination: 10.1.20.153 Source Address Translation: Auto Map DNS Profile: demo_dns_profile Click Finished. Validate Successful Name Resolution Navigate to a workstation that will be using the BIG-IP to resolve queries. Launch a command prompt. Type nslookup. Type server 10.1.20.153 Attempt to query external domain names. (e.g. nfl.com, nba.com, nhl.com, abcmouse.com) From the BIG-IP itself, you can also run a dig which is an extremely useful tool. Validate Cache Launch a ssh session to your BIG-IP using putty or the client of your choice. Run the following command. tmsh show ltm dns cache records rrset cache demo_resolver_cache You have now successfully configured your BIG-IP instance to perform name resolution as a recursive DNS server as well as cache DNS responses for faster name resolution. I really hope between this article and others it helps clarify some of the questions out there regarding recursive and authoritative DNS capabilities the BIG-IP provides.
BIG-IP DNS Resource Record Types: Architecture, Design and Configuration
Welcome to my first article on DevCentral! This article starts aseries about BIG-IP DNS (the artist formerly known as GTM). This article and accompanying videos take a look at the support for Domain Name System (DNS) Resource Record (RR) types that were introduced in BIG-IP version 12.0. This enhancement represented a major step forward in the capabilities available on the BIG-IP. I created these videos during the initial introduction of the feature in BIG-IP 12.0 release. Based on the timestamp in the BIG-IP GUI, that would be October of 2015. The information presented here is still relevant for later versions of BIG-IP and will be of benefit to anyone trying to understand the different DNS resource record types available on the BIG-IP. The videos assume you have used BIG-IP DNS before, and you understand the basics of DNS. If you need a refresher on DNS resource records, I present an overview of the new and existing resource records supported by BIG-IP DNS. I then go into the feature itself and the architecture and implementation details for each of the records on BIG-IP DNS. In the last video, I do a configuration walk-through of a NAPTR and SRV wideIP along with the NAPTR and SRV pools. Be sure and see the attachment at the end of the article. It is a zip file that contains a PDF of many of the slides I use in the videos. Executive Summary (9 Minutes) First up is the Executive Summary. This video introduces, at a high level, everything that will be covered in the later videos. It also talks about some things that are not explicitly called out in any of the other content. Technology Overview (8 Minutes) Next is a DNS technology overview for the different resource record types supported by BIG-IP DNS. If you are already familiar with the different DNS RR types (A, AAAA, CNAME, NAPTR, SRV, MX), you can skip this part. If you need a quick refresher on what each record type is and the fields used in them this content is for you! NOTE: This is not a discussion of how the BIG-IP DNS implements these resource records but rather a discussion of the record types themselves in a purely DNS sense. Feature/Architecture Overview If you do not watch any of the other videos in this series, watch these!! I go over the concepts and architecture behind how the different resource records are implemented and configured on BIG-IP DNS with lots of diagrams. The configurations of the different resource record types and all the associated pools can get confusing. These videos will give you a solid foundation to follow the configuration walk-through. I am going to be bold here and say that I guarantee you will learn something you did not know about BIG-IP DNS if you watch the next five videos. As a polling mechanism, hit the “Like” button on the article if I was correct in my prediction. General Information and A/AAAA Records (11:30 Minutes) This video covers general information about the DNS RR implementation along with the A and AAAA record types. For example, the video talks about a new concept in BIG-IP DNS called Non-Terminal and Terminal Pools and what they mean in wideIP configurations. CNAMEs (9 Minutes) This is a long discussion about CNAMEs. Who knew they were so interesting? Well, they are, and it is worth listening to how they are implemented on BIG-IP DNS. NAPTR, SRV and MX Records (5:30 Minutes) NAPTR, SRV and MX records are next. The configuration walk-through later in this article will implement NAPTR and SRV wideIPs. Health Checks (7:30 Minutes) Let’s talk about one of the reasons you have a BIG-IP DNS…health checks! Now that wideIPs can be pool member, the game has changed. Persistence (8 Minutes) Persistence also has some new wrinkles. If you use persistence, you want to watch this. Configuration Walk-through (11:30 Minutes) Finally, we have the configuration walk-through. This is where things get real. In this video, I do a configuration of NAPTR and SRV wideIPs along with the NAPTR and SRV pools. You can see the configuration objects I will create and the order in the diagram below. Conclusion That is all I have for this article. I hope you learned something and most importantly have a better understanding of the different DNS resource record types available on the BIG-IP DNS. I have more articles and videos to come so stay tuned. Be sure and grab the attachment if you want a copy of some of the diagrams used in the videos. Trivia: iQuery uses port 4353 for its communication. Do you know the significance/meaning of that particular port number? Drop a comment at the bottom if you know the answer.Lightboard Lessons: F5 BIG-IP DNS (GTM) iQuery Protocol Overview
In this episode of Lightboard Lessons, I introduce iQuery, the F5 proprietary protocol utilized by BIG-IP DNS to exchange system configuration with other BIG-IP DNS systems and performance metrics with all other BIG-IP systems configured to do so. Resources Communications Between BIG-IP DNS and Other Systems Troubleshooting BIG-IP DNS synchronization and iQuery connections (11.x - 13.x) What is BIG-IP DNS? Getting Started with BIG-IP DNS (GTM) Configuring BIG-IP DNS (GTM)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.htmlThe 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!Using BIG-IP GTM to Integrate with Amazon Web Services
This is the latest in a series of DNS articles that I've been writing over the past couple of months. This article is taken from a fantastic solution that Joe Cassidy developed. So, thanks to Joe for developing this solution, and thanks for the opportunity to write about it here on DevCentral. As a quick reminder, my first six 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 DNS Caching The Scenario Let's say you are an F5 customer who has external GTMs and LTMs in your environment, but you are not leveraging them for your main website (example.com). Your website is a zone sitting on your windows DNS servers in your DMZ that round robin load balance to some backend webservers. You've heard all about the benefits of the cloud (and rightfully so), and you want to move your web content to the Amazon Cloud. Nice choice! As you were making the move to Amazon, you were given instructions by Amazon to just CNAME your domain to two unique Amazon Elastic Load Balanced (ELB) domains. Amazon’s requests were not feasible for a few reasons...one of which is that it breaks the RFC. So, you engage in a series of architecture meetings to figure all this stuff out. Amazon told your Active Directory/DNS team to CNAME www.example.com and example.com to two AWS clusters: us-east.elb.amazonaws.com and us-west.elb.amazonaws.com. You couldn't use Microsoft DNS to perform a basic CNAME of these records because of the BIND limitation of CNAME'ing a single A record to multiple aliases. Additionally, you couldn't point to IPs because Amazon said they will be using dynamic IPs for your platform. So, what to do, right? The Solution The good news is that you can use the functionality and flexibility of your F5 technology to easily solve this problem. Here are a few steps that will guide you through this specific scenario: Redirect requests for http://example.com to http://www.example.com and apply it to your Virtual Server (1.2.3.4:80). You can redirect using HTTP Class profiles (v11.3 and prior) or using a policy with Centralized Policy Matching (v11.4 and newer) or you can always write an iRule to redirect! Make www.example.com a CNAME record to example.lb.example.com; where *.lb.example.com is a sub-delegated zone of example.com that resides on your BIG-IP GTM. Create a global traffic pool “aws_us_east” that contains no members but rather a CNAME to us-east.elb.amazonaws.com. Create another global traffic pool “aws_us_west” that contains no members but rather a CNAME to us-west.elb.amazonaws.com. The following screenshot shows the details of creating the global traffic pools (using v11.5). Notice you have to select the "Advanced" configuration to add the CNAME. Create a global traffic Wide IP example.lb.example.com with two pool members “aws_us_east” and “aws_us_west”. The following screenshot shows the details. Create two global traffic regions: “eastern” and “western”. The screenshot below shows the details of creating the traffic regions. Create global traffic topology records using "Request Source: Region is eastern" and "Destination Pool is aws_us_east". Repeat this for the western region using the aws_us_west pool. The screenshot below shows the details of creating these records. Modify Pool settings under Wide IP www.example.com to use "Topology" as load balancing method. See the screenshot below for details. How it all works... Here's the flow of events that take place as a user types in the web address and ultimately receives the correct IP address. External client types http://example.com into their web browser Internet DNS resolution takes place and maps example.com to your Virtual Server address: IN A 1.2.3.4 An HTTP request is directed to 1.2.3.4:80 Your LTM checks for a profile, the HTTP profile is enabled, the redirect request is applied, and redirect user request with 301 response code is executed External client receives 301 response code and their browser makes a new request to http://www.example.com Internet DNS resolution takes place and maps www.example.com to IN CNAME example.lb.example.com Internet DNS resolution continues mapping example.lb.example.com to your GTM configured Wide IP The Wide IP load balances the request to one of the pools based on the configured logic: Round Robin, Global Availability, Topology or Ratio (we chose "Topology" for our solution) The GTM-configured pool contains a CNAME to either us_east or us_west AWS data centers Internet DNS resolution takes place mapping the request to the ELB hostname (i.e. us-west.elb.amazonaws.com) and gives two A records External client http request is mapped to one of the returned IP addresses And, there you have it. With this solution, you can integrate AWS using your existing LTM and GTM technology! I hope this helps, and I hope you can implement this and other solutions using all the flexibility and power of your F5 technology.
