big-ip
12040 TopicsADC01 – Weak DNS Practices
Introduction DNS is often the unsung hero of application delivery, quietly humming along until something goes wrong. This cornerstone of internet infrastructure translates human readable domain names into machine friendly IP addresses, bridging the gap between users and applications. While vital, DNS frequently gets overlooked, leading to unforeseen performance, availability, scalability, and security issues in application delivery. In today's interconnected world, where seamless application delivery is critical across industries such as finance, healthcare, insurance, telecommunications, hi-tech, energy, government, retail and e-commerce, automotive, and manufacturing, weak DNS practices can wreak havoc. Since stakes are high and user expectations demand near instantaneous responsiveness and reliability, the principles discussed here apply universally. Businesses in any sector must recognize DNS as more than just a basic utility because it is a foundational layer of their application delivery strategy. AI Reference Architecture Use Case example: Enhancing DNS Security and Performance with F5 BIG-IP To better understand how optimized DNS practices strengthen application delivery, let’s consider the following real world use case: Steps in the DNS Optimization Process: Client Initiates DNS Query: A client, located on the external network, initiates a DNS query to resolve a domain name. Query Passes Through F5 BIG-IP: The F5 BIG-IP acts as a secure DNS proxy, validating the query and applying DNSSEC (Domain Name System Security Extensions) for added cryptographic security. DNSSEC ensures that queries are not tampered with and originate from a legitimate source. Authoritative DNS Responds: The validated query is routed securely to the authoritative DNS server cluster within the internal network. The authoritative DNS responds with the appropriate IP address. Response Returned to Client: The optimized, secure response is returned to the client with minimal latency, leveraging DNSSEC and optimized TTL (Time-to-Live) settings for better user experience. This workflow illustrates how incorporating F5 BIG-IP into your DNS architecture can enhance application security, scalability, and performance. Consequences of Weak DNS Practices Impact on Performance DNS inefficiencies are a hidden bottleneck for application performance. In 2023, nearly 27% of user complaints about poor application performance stemmed from DNS related slowdowns (Auvik). When DNS servers aren’t optimized or critical security features like DNS Security Extensions (DNSSEC) are absent, the impact cascades across application performance: Latency increases: Low TTL (Time-to-Live) settings overload DNS servers with repeated queries, slowing down responses for users spread across regions. Vulnerability to hijacking: Without DNSSEC, attackers can intercept or redirect traffic to slower or malicious servers, significantly impacting response times and user experience. Impact on Availability DNS disruptions, either due to attacks or misconfigurations, can lead to major availability issues. For instance: DNS hijacking or cache poisoning: Attackers inject fake records into DNS servers, redirecting users to harmful websites. Without DNSSEC, these vulnerabilities remain exploitable, leading to user mistrust. Low or mismatched TTL settings: These settings exacerbate availability problems by overwhelming DNS servers during failovers or scaling events, making applications inaccessible during critical times. Cloud-based global applications, which rely on dynamic DNS updates to remain accessible, worsen the problem when DNS configurations cannot keep pace with the scaling requirements of infrastructure. Impact on Scalability Scalability is a fundamental goal for any global application. Yet, weak DNS practices create bottlenecks: Dynamic DNS updates: Insecure or improperly authenticated dynamic DNS updates disrupt routing, crippling the application’s ability to handle increased user demand. Unprepared DNS infrastructure: With global audiences and fluctuating traffic volumes, under-provisioned or misconfigured DNS servers can experience elevated latency and outages, hindering business growth and reducing global reach. Impact on Operational Efficiency Operational inefficiencies arise from frequent DNS queries (due to low TTLs) and insecure configurations. IT teams become mired in troubleshooting and responding to incidents like DDoS attacks, instead of focusing on broader strategic goals. Moreover, the resources directed toward mitigating DNS-related issues inflate operational costs unnecessarily, wasting valuable time and money. The Undeniable Need for Best Practices To avoid these pitfalls, organizations need to prioritize robust DNS architectures. Here are key practices to implement: DNSSEC for Security DNSSEC (Domain Name System Security Extensions) operates as a safeguard against cache poisoning and DNS hijacking attacks. Implementing DNSSEC ensures the cryptographic validation of DNS records, mitigating risks from unauthorized changes. This adds a layer of trust and reliability to your DNS infrastructure and by extension to user experiences. DNSSEC is no longer a luxury, but a necessity for securely connecting users across the globe. Optimized TTL Settings for Balance TTL settings determine how long DNS information is cached by resolvers before they query authoritative DNS servers. Too short a value results in frequent DNS lookups, increasing server load and latency. Conversely, excessively long TTL values cause outdated information during dynamic scaling. Organizations should analyze traffic patterns and application behavior to strike the right balance. Regular revisions of TTL settings ensure that user queries are routed efficiently without bottlenecking operations. Secure Dynamic DNS Update Dynamic DNS updates are essential for cloud-based infrastructures where IP addresses frequently change. However, insecure update mechanisms are a gold mine for attackers, providing opportunities to alter DNS records maliciously. By using authentication and encryption mechanisms for DNS updates, organizations can protect records and optimize routing seamlessly. Distributed DNS Architecture Relying on a single DNS service provider or a centralized DNS setup increases the risks of downtime. By spreading DNS across multiple geographically independent providers and locations, organizations ensure better fault tolerance and reliability. Global Implications of Weak DNS In 2023, 90% of organizations faced DNS attacks, with financial losses averaging $1.1 million per incident (EfficientIP). These attacks are not just a cost center but also a real time disruption that tarnishes brand reputation and user trust. Each organization encounters an average of 7.5 DNS attacks annually, underlining the broad spectrum of vulnerabilities across industries. Global operations are particularly susceptible to DNS misconfigurations and weaknesses. Whether through hijacking traffic, launching DDoS campaigns, or exploiting TTL mismanagement, attackers leverage DNS vulnerabilities to cripple applications and compromise sensitive data. To scale securely, organizations need DNS practices aligned with industry standards, steering away from outdated configurations or reliance on "default" infrastructure. Final Thoughts Weak DNS practices are a silent killer of application performance, availability, scalability, and operational efficiency. The good news? These challenges are entirely avoidable. By implementing DNSSEC, optimizing TTL settings, securing dynamic DNS updates, and adopting distributed DNS strategies, organizations can dramatically reduce these risks. In the digital landscape of today, where milliseconds can dictate millions in revenue, DNS cannot be an afterthought. It must be a core pillar of application delivery strategies, ensuring that every user query is answered rapidly, reliably, and securely. DNS influences every aspect of the user experience. It’s the first impression your application makes. Don’t squander it. As your applications scale to meet global demand, strong DNS practices will ensure they deliver consistently, no matter where users click “Buy Now.” Reference Articles Scaling, Securing, and Optimizing DNS Hyperscale and Protect Your DNS While Optimizing Global App Delivery Intelligent DNS Firewall for Service Providers F5 DNS: Global Server Load Balancing The Application Delivery Top 10 ADSP Platform overview AI reference architecture The BIG-IP GTM: Configuring DNSSEC Configuring BIG-IP for Zone Transfer and DNSSEC107Views0likes0CommentsAn Irule for Client Ssl Profile that Allows Unassigned TLS Extension Values (17516)
Hello Community, I have a requirement to allow enriched https header enrichment. The SSL negotiation (I'm doing ssl termination on F5) fails because the enriched header from client contains reserved tls extension values. (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtmltls-extensiontype-values-1). The Client Hello request in the SSL Handshake was captured and contained an Extensions list, which included a reserved TLS Extension value (17156), which the F5 isn't presenting in Server Hello. I need an irule that can allow that Extension to be added on the client ssl profile so the ssl handshake doesn't fail.3.5KViews0likes28CommentsIIS X-Forward-For ISAPI Filter
A recent customer issue came up where they were load balancing servers but we unable to get the true client address logged in their IIS logs. They had their servers fronted by a BIG-IP and when clients would make requests the address passed to the server was the internal address and not that of the client. This is a common issue with proxies and fortunately there is a standard for forwarding client information. It is the HTTP X-Forwarded-For header which is handled by most proxies. So, I set out to find an existing ISAPI filter to replace the c-ip (client ip) log value in IIS with the contents of the X-Forwarded-For header (if it exists). I was amazed to find that I couldn't find a single instance of any open source (or even commercial) filter that would do this. So, I dug out Visual Studio and whipped up a filter that does just that. It's very basic and contains no user configuration so all you need to do is plug it into your Web Applications list of ISAPI Filters within the IIS Administration and you're set to go. We've released the source under the iControl End User License Agreement (available in any iControl SDK download). You can download it here. If you find a way to optimize this filter, please let me know and I'll update the sources here. After 24-hours of posting, a customer already returned some performance testing on the filter indicating that it only effected the traffic by less than 1 percent. I'm sure there are ways to optimize the memory allocation in the filter to speed this up a bit more, but I'll leave that for the community to work on. Oh, and it should be noted that the X-Forwarded-For header isn't supported the same way across all proxy products so you'll want to make sure you test this out before using it. It is expecting the header to only contain an IP Address as it does a straight substitution on the value in the c-ip section of the log entry. Enjoy! -Joe8.3KViews0likes36CommentsF5 BIG-IP Multi-Site Dashboard
Code is community submitted, community supported, and recognized as ‘Use At Your Own Risk’. A comprehensive real-time monitoring dashboard for F5 BIG-IP Application Delivery Controllers featuring multi-site support, DNS hostname resolution, member state tracking, and advanced filtering capabilities. A 170KB modular JavaScript application runs entirely in your browser, served directly from the F5's high-speed operational dataplane. One or more sites operate as Dashboard Front-Ends serving the dashboard interface (HTML, JavaScript, CSS) via iFiles, while other sites operate as API Hosts providing pool data through optimized JSON-based dashboard API calls. This provides unified visibility across multiple sites from a single interface without requiring even a read-only account on any of the BIG-IPs, allowing you to switch between locations and see consistent pool, member, and health status data with almost no latency and very little overhead. Think of it as an extension of the F5 GUI: near real-time state tracking, DNS hostname resolution (if configured), advanced search/filtering, and the ability to see exactly what changed and when. It gives application teams and operations teams direct visibility into application pool state without needing to wait for answers from F5 engineers, eliminating the organizational bottleneck that slows down troubleshooting when every minute counts. https://github.com/hauptem/F5-Multisite-Dashboard577Views4likes2CommentsThree Things I've Learned Recently While Deploying F5 CIS on OpenShift
Not every CIS deployment issue is actually a CIS issue. This article walks through three lessons learned from recent OpenShift deployments where the real culprit turned out to be NetworkPolicies, image selection, and version management rather than the controller itself.181Views3likes0CommentsRecursive DNS resolution (DoT), allowing queries UDP/53 while BIG-IP forwards over TCP/853
How can I configure BIG-IP to perform recursive DNS resolution over DNS-over-TLS (DoT), allowing standard DNS clients to send queries over UDP/53 while BIG-IP forwards those queries securely over TCP/853? It is possible without a external resolver ?120Views0likes2CommentsAdvanced WAF IP Exceptions Manager
This solution introduces a dedicated Python-based GUI tool for managing IP whitelist exceptions in F5 BIG-IP Advanced WAF policies. The tool was developed to simplify a common operational workflow: searching WAF policies, adding IP or CIDR-based exceptions, checking whether an IP already exists across policies, deleting outdated exceptions, applying policy changes, and tracking actions through an activity log. The solution is especially useful in large environments where manual exception handling can create operational overhead, inconsistent policy configuration, or audit challenges. It demonstrates how focused automation can deliver practical value without requiring a large orchestration platform or full CI/CD pipeline.169Views1like0CommentsAPI Discovery and Enforcement with API Security Local Edition
API Security Local Edition is a self-hosted platform that discovers APIs from BIG-IP traffic insights, builds and maintains an inventory with risk scoring, and pushes enforcement back to BIG-IP. This article covers the architecture, the data flows between components, and the operator workflow from discovery to enforcement.
565Views5likes3CommentsUse F5 APM as Forward Proxy
Hello All, I have one BIG-IP with APM license and I wan to use it as a forward proxy. I have used this iApp https://devcentral.f5.com/codeshare/apm-explicit-proxy and now I have: DNS Resolver Tunnel for traffic HTTP profile Virtual Server (Proxy) listening on 8080 Although this is configured, when I point to this proxy with my browser it doesn’t seem to work. I suppose that now I have to create two more separate virtual servers listening on ports 80 and 443 for handling http and https traffic. Am I right? The question is once I have configured this two virtual servers how can I forward traffic to Internet? If the VS haven’t got pool members, does it check the routing table? Or I have to create an iRule with something like this: When HTTP::request { Forward } When HTTP::response { Forward } Also, I don’t want to inspect SSL traffic, I Would like to use the Proxy as a passthrough but only allow certain https sites, Do I need to inspect SSL traffic to filter by URLs? Thanks in advantageSolved728Views0likes4Comments