The BIG-IP GTM: Configuring DNSSEC
This is the fourth in a series of DNS articles that I'm writing. The first three are: Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express and Zone Transfers The Domain Name System (DNS) is a key component of the Internet's critical infrastructure. So, if the foundation of the Internet itself relies on DNS, then let's take a quick look at how stable this foundation really is. After all, DNS was born in the early 1980s...back when REO Speedwagon and Air Supply were cranking out hits on the radio. The question is...does the DNS of the 1980s have any issues we need to worry about today? Well as it turns out, DNS was not initially built with security in mind. When a user types a web address in his browser, he expects to be reliably directed to that website. Unfortunately, that doesn't always happen. One common example is seen when an attacker disrupts the user's request and redirects to a malicious site. Several DNS vulnerabilities like this have led the way to an interest in DNS Security Extensions (DNSSEC) to secure this critical part of our Internet infrastructure. What is DNSSEC? DNSSEC is a suite of extensions that add security to the DNS protocol by enabling responses to be validated. With DNSSEC, the DNS protocol is much less susceptible to certain types of attacks (like the DNS spoofing situation described above). DNSSEC uses digital signatures to validate DNS responses so that the end user can be assured he is visiting the correct website. Based on the design features of DNSSEC, it is most effective when deployed at each step in the DNS lookup process...from root zone to the final domain name. If you leave any of the steps unsigned, it creates weakness in the process and you won't be able to trust the entire chain. Keep in mind that DNSSEC doesn't encrypt the data, it just signs it to attest to the validity of the response. When a user requests a site, DNS kicks into gear by translating the domain name into an IP address. It does this through a series of recursive lookups that form a "chain" of requests. The picture below shows an example of a user requesting f5.com and the DNS system chaining together requests in order to match the domain name to the IP address so that he can access the website. This is all well and good, but the issue that forms the need for DNSSEC is that each stop in this chain inherently trusts the other parts of the chain...no questions asked. So, what if an attacker could somehow manipulate one of the servers (or even the traffic on the wire) and send the wrong IP address back to the user? The attacker could redirect the user to a website where malware is waiting to scan the unsuspecting user's computer. The picture below shows the same chain of requests, but this time an attacker has manipulated the last response so that the incorrect IP address is returned to the user. Not good. DNSSEC addresses this problem by validating the response of each part of the chain by using digital signatures. These signatures help build a "chain of trust" that DNS can rely on when answering requests. To form the chain of trust, DNSSEC starts with a "trust anchor" and everything below that trust anchor is trusted. Ideally, the trust anchor is the root zone. Fortunately for all of us, ICANN published the root zone trust anchor, and root operators began serving the signed root zone in July, 2010. With the root zone signed, all other zones below it can also be signed, thus forming a solid and complete chain of trust. In fact, ICANN also lists the Top Level Domains (TLD) that are currently signed and have trust anchors published as DS records in the root zone (most of the TLDs are signed). The following picture (taken from iiw.idcommons.net) shows the process for building the chain of trust from the root zone. DNSSEC uses two kinds of keys: Key Signing Keys and Zone Signing Keys. The Key Signing Key is used to sign other keys in order to build the chain of trust. This key is sometimes cryptographically stronger and has a longer lifespan than a Zone Signing Key. The Zone Signing Key is used to sign the data that is published in a zone. DNSSEC uses the Key Signing Keys and Zone Signing Keys to sign and verify records within DNS. BIG-IP Configuration The BIG-IP Global Traffic Manager (GTM) will not only respond to DNS requests, but it will also sign DNSSEC validated responses. But before you can configure the GTM to handle nameserver responses that are DNSSEC-compliant, you have to create DNSSEC keys and zones. The first step is to create the Zone Signing Key(s) and the Key Signing Key(s). The Zone Signing Key specifies the keys that the system uses to sign requests to a zone. The BIG-IP responds to DNSSEC requests to a specific zone by returning signed nameserver responses based on the currently available generations of a key. The Key Signing Key works the same as the Zone Signing Key except that it applies to keys instead of zones. To create these keys, navigate to Global Traffic >> DNSSEC Key List and create a new key. Note: this menu looks slightly different starting in version 11.5 (it's listed under "DNS" instead of "Global Traffic") but the Key Creation is still the same. On this page, you can create a Zone Signing Key and a Key Signing Key, and you can also specify several other settings like HSM use, algorithm selection, and key management action. Note that you can let the BIG-IP automatically manage your key actions or you can choose to do it manually. Configuration Settings The Bit Width for the key can be either 1024, 2048, or 4096 bits. The default is 1024. The TTL value specifies the length of time the BIG-IP stores the key in cache. A key can be cached between 0 and 4294967295 seconds (by the way, 4294967295 seconds is a little more than 136 years!). The default value is 86400 seconds (one day). This value must be less than the difference between the values of the rollover period and expiration period (referred to as the "overlap period"). Setting this value to 0 seconds indicates that client resolvers do not cache the key. The Rollover Period specifies the interval after which the BIG-IP creates a new generation of an existing key. The valid range for values for the Rollover Period is from 0 to 4294967295 seconds. The default is 0 seconds, which means the key does not roll over. This value of the rollover period must be greater than or equal to one third of the value of the expiration period and less than the value of the expiration period. The Expiration Period specifies the interval after which the BIG-IP deletes an existing key. The valid range for values is from 0 to 4294967295 seconds. The default is 0 seconds, which means the key does not expire. The value of the expiration period must be more than the value of the rollover period. Also, the overlap period must be more than the value of the TTL. FYI...the National Institute of Standards and Technology (NIST) recommends that a Zone Signing Key expire between 30-90 days, and that a Key Signing Key expire once a year. The Signature Validity Period specifies the interval after which the BIG-IP no longer uses the expired signature. The valid range for values is from 0 to 4294967295 seconds. The default is 7 days. This value must be greater than the value of the signature publication period. If you set this value to 0, the server verifying the signature never succeeds because the signature is always expired, so don't set it to 0! The Signature Publication Period specifies the interval after which the BIG-IP creates a new signature. The valid range for these values is from 0 to 4294967295 seconds. The default value is 4 days, 16 hours (two-thirds of a week). This value must be less than the value of the signature validity period. If you set this value to 0, the system does not cache the signature. TTL Values, Key Values, and Overlaps The following diagram shows an example of key generation timelines with rollover periods and overlaps. This diagram is useful when reviewing the configuration settings and values discussed in the section above. Notice that the expiration period must be greater than the rollover period, and the TTL must be less than the overlap period. You wouldn't want a key to expire before it rolls over; likewise, you wouldn't want a TTL period to outlast the overlap period...if it did, the key could still be valid after the expiration period. After you create and configure the Zone Signing Key(s) and Key Signing Key(s), the next step is to create a DNSSEC zone. A DNSSEC zone maps a domain name to a set of DNSSEC keys. In the BIG-IP, you create DNSSEC zones by navigating to Global Traffic >> DNSSEC Zone List and create a new zone. On this page, you can name the zone, configure state settings, assign algorithms, and activate zone keys. The hash algorithm options are SHA-1 (default) or SHA-256. The Zone Signing Key box specifies the zone keys that the BIG-IP uses to sign requests to a zone. The Key Signing Key works similar to the Zone Signing Key, except it is used to sign keys instead of requests. The following screenshot shows the options available for creating DNSSEC zones. To fully secure a zone, the parent zone needs to have copies of the child's public key. The parent zone then signs the child's public key with their own key and sends it up to their parent...this pattern is followed all the way to the root zone. Once you have created the DNSSEC keys and zones, you can submit the Delegation Signer (DS) record to the administrators of your parent zone. They will sign the DS record with their own key and upload it to their zone. You can find the DS record for your zone here: /config/gtm/dsset-dnssec.zone.name There's a lot to DNSSEC, and this article wasn't written to capture it all, but I hope it sheds a little light on what DNSSEC is and how you can create zones and keys on your BIG-IP. Stay tuned for more BIG-IP GTM articles in the coming days, weeks, and months. Until then, keep those DNS requests flowing, and make sure they are valid with DNSSEC! One last thing...did you know that F5 has an awesome Reference Architecture dedicated to Intelligent DNS Scale? The F5 Intelligent DNS Scale solution ensures that you can access your critical web, application, and database services whenever you need them...check it out!
F5 Friday: The 2048-bit Keys to the Kingdom
There’s a rarely mentioned move from 1024-bit to 2048-bit key lengths in the security demesne … are you ready? More importantly, are your infrastructure and applications ready? Everyone has likely read about DNSSEC and the exciting day on which the root servers were signed. In response to security concerns – and very valid ones at that – around the veracity of responses returned by DNS, which underpins the entire Internet, the practice of signing responses was introduced. Everyone who had anything to do with encryption and certificates said something about the initiative. But less mentioned was a move to leverage longer RSA key lengths as a means to increase the security of the encryption of data, a la SSL (Secure Socket Layer). While there have been a few stories on SSL vulnerabilities – Dan Kaminsky illustrated flaws in the system at Black Hat last year – there’s been very little public discussion about the transition in key sizes across the industry. The last time we had such a massive move in the cryptography space was back when we moved from 128-bit to 256-bit keys. Some folks may remember that many early adopters of the Internet had issues with browser support back then, and the impact on the performance and capacity of infrastructure were very negatively impacted. Well, that’s about to happen again as we move from 1024-bit keys to 2048-bit keys – and the recommended transition deadline is fast approaching. In fact, NIST is recommending the transition by January 1st, 2011 and several key providers of certificates are already restricting the issuance of certificates to 2048-bit keys. NIST Recommends transition to 2048-bit key lengths by Jan 1st 2011: Special Publication 800-57 Part 1 Table 4 VeriSign Started focusing on 2048-bit keys in 2006; complete transition by October 2010. Indicates their transition is to comply with best practices as recommended by NIST GeoTrust Clearly indicates why it transitioned to only 2048-bit Keys in June 2010 Entrust Also following NIST recommendations : TN 7710 - Entrust is moving to 2048-bit RSA keys. GoDaddy "We enforced a new policy where all newly issued and renewed certificates must be 2048-bit“. Extended Validation (EV) required 2048-bit keys on 1/1/09 Note that it isn’t just providers who are making this move. Microsoft uses and recommends 2048-bit keys per the NIST guidelines for all servers and other products. Red Hat recommends 2048+ length for keys using RSA algorithm. And as of December 31, 2013 Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits. That means sites that have not made the move as of that date will find it difficult for customers and visitors to hook up, as it were. THE IMPACT on YOU The impact on organizations that take advantage of encryption and decryption to secure web sites, sign code, and authenticate access is primarily in performance and capacity. The decrease in performance as key sizes increase is not linear, but more on the lines of exponential. For example, though the key size is shifting by a factor of two, F5 internal testing indicates that such a shift results in approximately a 5x reduction in performance (as measured by TPS – Transactions per Second). This reduction in performance has also been seen by others in the space, as indicated by a recent Citrix announcement of a 5x increase in performance of its cryptographic processing. This decrease in TPS is due primarily to heavy use of the key during the handshaking process. The impact on you is heavily dependent on how much of your infrastructure leverages SSL. For some organizations – those that require SSL end-to-end – the impact will be much higher. Any infrastructure component that terminated SSL and re-encrypted the data as a means to provide inline functionality (think IDS, Load balancer, web application firewall, anti-virus scan) will need to also support 2048-bit keys, and if new certificates are necessary these, too, will need to be deployed throughout the infrastructure. Any organization with additional security/encryption requirements over and above simply SSL encryption, such as FIPS 140-2 or higher, are looking at new/additional hardware to support the migration. Note: There are architectural solutions to avoid the type of forklift upgrade necessary, we’ll get to that shortly. If your infrastructure is currently supporting SSL encryption/decryption on your web/application servers, you’ll certainly want to start investigating the impact on capacity and performance now. SSL with 1024-bit keys typically requires about 30% of a server’s resources (RAM, CPU) and the increase to 2048-bit keys will require more, which necessarily comes from the resources used by the application. That means a decrease in capacity of applications running on servers on which SSL is terminated and typically a degradation in performance. In general, the decrease we’ve (and others) have seen in TPS performance on hardware should give you a good idea of what to expect on software or virtual network appliances. As a general rule you should determine what level of SSL transaction you are currently licensed for and divide that number by five to determine whether you can maintain the capacity you have today after a migration to 2048-bit keys. It may not be a pretty picture. ADVANTAGES of SSL OFFLOAD If the advantages of offloading SSL to an external infrastructure component were significant before the move from 1024-bit keys to 2048-bit keys makes them nearly indispensable to maintaining performance and capacity of existing applications and infrastructure. Offloading SSL to an external infrastructure component enabled with specialized hardware further improves the capacity and performance of these mathematically complex and compute intensive processes. ARCHITECTURAL SOLUTION to support 1024-bit key only applications If you were thinking about leveraging a virtual network appliance for this purpose, you might want to think about that one again. Early testing of RSA operations using 2048-bit keys on 64-bit commodity hardware shows a capacity in the hundreds of transactions per second. Not tens of thousands, not even thousands, but hundreds. Even if the only use of SSL in your organization is to provide secure web-based access to e-mail, a la Microsoft Web Outlook, this is likely unacceptable. Remember there is rarely a 1:1 relationship between connections and web applications today, and each connection requires the use of those SSL operations, which can drastically impact the capacity in terms of user concurrency. Perhaps as important is the ability to architect around limitations imposed by applications on the security infrastructure. For example, many legacy applications (Lotus Notes, IIS 5.0) do not support 2048-bit keys. Thus meeting the recommendation to migrate to 2048-bit keys is all but impossible for this class of application. Leveraging the capabilities of an application delivery controller that can support 2048-bit keys, however, allows for the continued support of 1024-bit keys to the application while supporting 2048-bit keys to the client. ARE YOU READY? That’s a question only you can answer, and you can only answer that by taking a good look at your infrastructure and applications. Now is a good time to evaluate your SSL strategy to ensure it’s up to the challenge of 2048-bit keys. Check your licenses, determine your current capacity and requirements, and compare those to what can be realistically expected once the migration is complete. Validate that applications currently requiring 1024-bit keys can support 2048-bit keys or whether such a migration is contraindicated by the application, and investigate whether a proxy-based (mediation) solution might be appropriate. And don’t forget to determine whether or not compliance with regulations may require new hardware solutions. Now this is an F5 Friday post, so you knew there had to be some tie-in, right? Other than the fact that the red-ball glowing ball on every BIG-IP just looks hawesome in the dim light of a data center, F5 solutions can mitigate many potential negative impacts resulting from a migration of 1024-bit to 2048-bit key lengths: BIG-IP Specialized Hardware BIG-IP hardware platforms include specialized RSA acceleration hardware that improves the performance of the RSA operations necessary to support encryption/decryption and SSL communication and enables higher capacities of the same. EM (Enterprise Manager) Streamlines Certificate Management F5’s centralized management solution, EM (Enterprise Manager), allows an organization to better manage a cryptographic infrastructure by providing the means to monitor and manage key expirations across all F5 solutions and collect TPS history and usage when sizing to better understand capacity constraints. BIG-IP Flexibility BIG-IP is a full proxy-based solution. It can mediate between clients and applications that have disparate requirements, such as may be the case with key sizes. This allows you to use 2048-bit keys but retain the use of 1024-bit keys to web/application servers and other infrastructure solutions. Strong partnerships and integration with leading centralized key management and crypto vendors that provide automated key migration and provisioning through open and standards-based APIs and robust scripting capabilities. DNSSEC Enhance security through DNSSEC to validate domain names. Although it has been suggested that 1024-bit keys might be sufficient for signing zones, with the forced migration to 2048-bit keys there will be increased pressure on the DNS infrastructure that may require a new solution for your DNS systems. THIS IS IN MANY REGARDS INFOSEC’S “Y2K” In many ways a change of this magnitude is for Information Security professionals their “Y2K” because such a migration will have an impact on nearly every component and application in the data center. Unfortunately for the security folks, we had a lot more time to prepare for Y2K…so get started, go through the checklist, and get yourself ready to make the switch now before the eleventh hour is upon us. Related blogs & articles: The Anatomy of an SSL Handshake [Network Computing] DNSSEC Readiness [ISC.org] Get Ready for the Impact of 2048-bit RSA Keys [Network Computing] SSL handshake latency and HTTPS optimizations [semicomplete.com] Pete Silva Demonstrates the FirePass SSL-VPN Data Center Feng Shui: SSL WILS: SSL TPS versus HTTP TPS over SSL SSL performance - DevCentral - F5 DevCentral > Community > Group ... DevCentral Weekly Roundup | Audio Podcast - SSL iControl Apps - #12 - Global SSL Statistics > DevCentral > F5 ... Oracle 10g SSL Offload - JInitiator:X509CertChainInvalidErr error ... Requiring an SSL Certificate for Parts of an Application ... The Order of (Network) OperationsCarrier Grade DNS: Not your Parents DNS
Domain Name System (DNS) is one of the overlooked systems in the deployment of 4G and Next Generation All IP Networks. The focus tends to be on revenue-generating applications that provide ROI for these major investments. For these to be successful the CSP's have first got to be able to deploy these networks, and provide a high quality of experience in order to be sure that these services are truly revenue generating. However, most CSP’s have overlooked some of the basic IP functions in order to provide these revenue generating applications. The building blocks for these applications are a quality, efficient, scalable, and feature-rich IP architecture. One of the key items that are required for this IP architecture is Carrier Grade DNS. DNS has been a long-standing requirement for Internet services for CSP's. However with these all IP networks, DNS is being used for new capabilities along with supporting increases in data traffic for standard content and Internet services. For years CSP's and employed cheap, inexpensive, and basic DNS systems on their network. This was done to provide basic DNS services and to minimize cost. However with and developing networks, these basic DNS deployments will not support the requirements of the future. DNS services are starting to be used for new and unique capabilities, which include managing traffic on both the internal network along with external content that is located on the Internet. Along with this new functionality, DNS is also required to provide security of DNS transactions and have the ability to mitigate against DNS attacks, along with providing for authoritative DNS zone management, resolution, and non-authoritative support, such as caching. The significant challenge for communication service providers is to provide these DNS capabilities while still maintaining a manageable Capex and Opex. This challenge can only be met by deploying a carrier grade DNS solution. The carrier grade DNS solution comprises all the basic capabilities of DNS, along with including a logical scaling capability, security for DNS transactions, and an ability to intelligently manage authoritative zones. Historically, traditional DNS solutions have addressed scaling by simply adding more hardware. This method is a Capex nightmare. With the increases in data and data demands, these problems with DNS scaling will grow exponentially. The only solution to this problem is the ability to deploy an intelligent DNS system that allows the communication service provider the ability to manage how DNS queries and how DNS authoritative responses are managed and delivered to subscribers. Since DNS is key in the ability to identify the location of web content it is vulnerable to both DNS hijacking attacks and denial of service (DoS) or distributed denial of service (DDoS) attacks. To prevent DNS hijacking attacks, carrier grade DNS solutions must be incorporated DNSSEC. By incorporating DNSSEC, responses to subscribers are guaranteed the identity of the answering authoritative DNS. DoS/DDoS attacks cannot be prevented. The only strategy they can be taken against DoS/DDoS is to mitigate the impact of these attacks. The best way to address the mitigation the impact of DoS/DDoS attacks is through a distributed carrier grade DNS architecture. By using such technologies as Global Server Load Balancing (GSLB) and IP Anycast, a distributed carrier grade DNS architecture can isolate and limit the impacts of DoS/DDoS attacks. GSLB allows the communication service provider to manage how DNS requests are answered based upon the location of the contents and the requester. IP Anycast allows for multiple systems to share the same IP address thereby distributing the number of systems answering request. By using these distributed systems DoS/DDoS attacks can be isolated and minimize the number of systems impacted. As we have seen over the past year, data use on CSP networks is going to continue to increase. To provide a successful ARPU model, a Carrier Grade DNS that provides for high availability, economical scalability, subscriber security, and high performance in essential. With all of the many challenges in a CSP network, basic IP infrastructure can be overlooked. An intelligent management system of these IP essential systems is the first step in reducing an ever expanding Capex and providing for a high quality of experience for your subscribers. Related Articles DNS is Like Your Mom F5 Friday: No DNS? No … Anything. Audio White Paper - High-Performance DNS Services in BIG-IP ... DevCentral Weekly Roundup | Audio Podcast - DNS F5 Friday: When the Solution to a Vulnerability is Vulnerable You ... F5 News - DNS DNS Monitor Using Dig - DevCentral Wiki The End of DNS As We Know It F5 Video: DNS Express—DNS Die Another Day Ray Vinson – DNSThe DNS of Things
Hey DNS - Find Me that Thing! There's a new craze occurring in homes, highways, workplaces and everywhere imaginable - the Internet of Things or as I like to call it, The Internet of Nouns. Sensors, thermostats, kitchen appliances, toilets and almost every person, place or thing will have a chip capable of connecting to the internet. And if you want to identify and find those things with recognizable words instead of a 128-bit IP address, you're going to need DNS. DNS translates the names we type into browser or mobile app into an IP address so the services can be found on the internet. It is one of the most important components of the internet, especially for human interaction. With the explosion of mobile devices and the millions of apps deployed to support those devices, DNS growth has doubled in recent years. It is also a vulnerable target. While the ability to adjust the temperature of your house or remotely flush your toilet from around the globe is cool, I think one of the biggest challenges of the Internet of Nouns will be the strain on DNS. Not only having to resolve the millions of additional 'things' getting connected but also the potential vulnerabilities and risks introduced when your washing machine connects to the internet to find the optimal temperature and detergent mix to remove those grass, wine and blood stains. Recent research suggests that the bad guys are already taking advantage of these easy targets. Arstechnica reports that the malware that has been targeting routers has now spread to DVRs. Not my precious digital video reorder!! Last week, Sans found a Bitcoin mining trojan that can infect security camera DVRs. As they were watching a script that hunted the internet for data storage devices, they learned that the bot was coming from a DVR. Most likely, they say, it was compromised through the telnet defaults. In another report, ESET said it found 11 year old malware that had been updated with the ability to compromise a residential broadband router's DNS settings. The malware finds a vulnerable router and changes the default DNS entries to either send the person to a rogue site to install more malware (join the bot, why don't ya) or to just redirect them to annoying sites. Imagine if the 50+ connected things we will soon have in our homes also joined the bot? Forget about needing compute and bandwidth from machines around the globe, you can zero in on a neighborhood to launch an attack. Nominum research shows that DNS-based DDoS amplification attacks have significantly increased in the recent months, targeting vulnerable home routers all over. A simple attack can create tens-of-gigs of traffic to disrupt networks, businesses, websites, and regular folks anywhere in the world. More than 24 million home routers on the Internet have open DNS proxies which expose ISPs to DNS-based DDoS attacks and in February 2014 alone, more than 5.3 million of these routers were used to generate attack traffic. These are especially hard to track since it is difficult to determine both the origination and target of the attack. Lastly, Ultra Electronics AEP says 47% of the internet remains insecure since many top level domains (TLDs) have failed to sign up to use domain name system security extensions (DNSSEC). These include heavy internet using countries like Italy (.it), Spain (.es) and South Africa (.za), leaving millions of internetizens open to malicious redirects to fake websites. Unless the top level domain is signed, every single website operating under a national domain can have its DNS spoofed and that's bad for the good guys. We often don't think about the Wizard behind the curtain until we are unable resolve an internet resource. DNS will become even more critical as additional nouns are connected and we want to find them by name. F5 DNS Solutions can help you manage this rapid growth with complete solutions that increase the speed, availability, scalability, and security of your DNS infrastructure. And I do imagine a time when our current commands could also work on, for instance, the connected toilet: /flushdns. Just couldn't let that one go. ps Related: “Internet of Things” is the new Windows XP—malware’s favorite target Win32/Sality newest component: a router’s primary DNS changer named Win32/RBrute 24 million home routers expose ISPs to massive DNS-based DDoS attacks 24 million reasons to lock down DNS amplification attacks Half the internet lacks DNS security extensions F5 Intelligent DNS Scale Technorati Tags: f5,dns,dnssec,ddos,security,iot,things,big-ip,malware,silva,trojan Connect with Peter: Connect with F5:
DNS Reimagined keeps your Business Online
Whether your services are deployed in a data center or migrated to a hybrid cloud environment, DNS knows where to send your users to their cool new app or favorite social media experience. Invariably DNS points the way to a connected session. Yes, it’s at this IP address. Or, it’s not available here but accessible at that address location, all in milliseconds. So with all kinds of new mobile devices, apps, and services, DNS requests (.com/.net) continue to climb 100% over the last 5 years. In 2014, there are 10 billion devices alone with 77 billion mobile apps downloaded. It’s estimated that there will be 50 to 75 billion devices by 2020. Along with all the other products already connected or coming, the Internet of Things sending DNS requests is about to become much larger. In addition, we don’t like to wait. If a mobile user has to wait more than 10 seconds, they’ll leave for another experience and revenue potential is lost. At the same time, as more online experiences move to the hybrid cloud, these virtual services are in a myriad of locations all requiring DNS to inform the client where the data is in order for the user to have a connected session. More locations means more latency and DNS needs to perform with fast responses in order to keep users engaged. Since DNS is essentially the yellow pages of the internet resolving queries, it’s critical to have a highly scalable, exponential performing, and secure DNS infrastructure in order to deliver an optimized user experience. F5 reimagines the traditional DNS delivery infrastructure as a paradigm shift to the edge of the network moving DNS services and app routing closest to the client based on geolocation. BIG-IP Global Traffic Manager (GTM) with DNS delivery services, including Authoritative DNS, delivers very high performance responding to DNS queries on behalf of the DNS master server. In addition, much lower latency comes with Caching and Resolving services at the edge for internal users or subscribers, and increased DNS security services for DDoS mitigation and DNSSEC all come on an ICSA network firewall certified solution. Finally, implementing DNSSEC signing protects against man-in-the-middle and cache poisoning attacks that would redirect the user to a malicious session. The results are an easy integration into existing DNS infrastructure, and the performance capabilities well into the tens of millions of DNS query responses per second on higher end solutions to keep your web sites and apps available during all kinds of scenarios. Users will see a much faster and more secure query response allowing for a far better user experience and greater potential for business growth. Now your DNS infrastructure is ready to scale exponentially and securely to meet the growing demand and you have global app routing for an optimized and highly available sessions. Automatically, your users’ DNS request for that customized online experience materializes, or that new business analytics site located at a closer location to them quickly loads. And, malformed DNS queries, invalid requests, are dropped to mitigate attacks. With large increases in DNS requests; automatic responses are sent at very high performance to keep online sessions available. These and many more options for DNS services and customization support apps and services uptime, keeping your business alive. Now more recently you might have been informed that you need to move a portion of your apps and services to a hybrid cloud environment to meet cloud computing, disaster recovery, and cost reduction goals. As you ponder how to deliver a similar experience to users, consider what type of DNS and global app routing you need to replicate in various virtual and cloud environments in order to accomplish your new objective. To learn more about how DNS supports the internet and how F5 supports cloud-hosted services, read the F5 Synthesis: DNS Shrugged article to help you accomplish your new mission. For more information on Intelligent DNS and Global App Management: Intelligent DNS Services Scalable, Secure DNS and Global App ServicesLightboard Lessons: DNSSEC
DNS is absolutely critical to your life on the Internet. But, did you know that DNS was designed back in the 1980s and didn't really consider security as a key component? DNSSEC was developed to help with that problem. In this edition of Lightboard Lessons, I discuss the basics of DNSSEC and talk about how the BIG-IP can help protect your critical DNS infrastructure. Related Resources: Configuring DNSSEC on the BIG-IPA Living Architecture
You often hear people say, 'oh, this is a living document,' to indicate that the information is continually updated or edited to reflect changes that may occur during the life of the document. Your infrastructure is also living and dynamic. You make changes, updates or upgrades to address the ever changing requirements of your employees, web visitors, customers, partners, networks, applications and anything else tied to your systems. This is also true for F5's Reference Architectures. They too are living architectures. F5's Reference Architectures are the proof-points or customer scenarios that drive Synthesis to your data center and beyond. When we initially built out these RA's, we knew that they'd be continuously updated to not only reflect new BIG-IP functionality but also show new solutions to the changing challenges IT faces daily. We've recently updated the Intelligent DNS Scale Reference Architecture to include more security (DNSSEC) and to address the highly hybrid nature of enterprise infrastructures with Distributed DNS. F5’s end-to-end Intelligent DNS Scale reference architecture enables organizations to build a strong DNS foundation that maximizes the use of resources and increases service management, while remaining agile enough to support both existing and future network architectures, devices, and applications. It also provides a more intelligent way to respond and scale to DNS queries and takes into account a variety of network conditions and situations to distribute user application requests and application services based on business policies, data center conditions, network conditions, and application performance. It ensures that your customers—and your employees—can access your critical web, application, and database services whenever they need them. In this latest DNS RA rev, DNSSEC can protect your DNS infrastructure, including cloud deployments, from cache poisoning attacks and domain hijacks. With DNSSEC support, you can digitally sign and encrypt your DNS query responses. This enables the resolver to determine the authenticity of the response, preventing DNS hijacking and cache poisoning. Also included is Distributed DNS. Meaning, all the DNS solution goodness also applies to cloud deployments or infrastructures where DNS is distributed. Organizations can replicate their high performance DNS infrastructure in almost any environment. Organizations may have Cloud DNS for disaster recovery/business continuity or even a Cloud DNS service with signed DNSSEC zones. F5 DNS Services enhanced AXFR support offers zone transfers from BIG-IP to any DNS service allowing organizations to replicate DNS in physical, virtual, and cloud environments. The DNS replication service can be sent to other BIG-IPs or other general DNS servers in Data Centers/Clouds that are closest to the users. In addition, Organizations can send users to a site that will give them the best experience. F5 DNS Services uses a range of load balancing methods and intelligent monitoring for each specific app and user. Traffic is routed according to your business policies and current network and user conditions. F5 DNS Services includes an accurate, granular geolocation database, giving you control of traffic distribution based on user location. DNS helps make the internet work and we often do not think of it until we cannot connect to some resource. With the Internet of Nouns (or Things if you like) hot on our heels, I think Port 53 will continue to be a critically important piece of the internet puzzle. ps Related: Intelligent DNS Scale Resources F5 Synthesis DNS Reimagined keeps your Business Online DNS Does the Job The DNS of Things DNS Doldrums The Internet of Things and DNS Technorati Tags: f5,big-ip,dns,reference architecture,dnssec,iot,things,name_resolution,silva,security,cloud,synthesis Connect with Peter: Connect with F5:DNSSEC: Is Your Infrastructure Ready?
A few months ago, we teamed with Infoblox for a DNSSEC webinar. Jonathan George, F5 Product Marketing Manager, leads with myself and Cricket Liu of Infoblox as background noise. He’s a blast as always and certainly knows his DNS. So, learn how F5 enables you to deploy DNSSEC quickly and easily into an existing GSLB environment with BIG-IP Global Traffic Manager (GTM). BIG-IP GTM streamlines encryption key generation and distribution by dynamically signing DNS responses in real-time. Running time: 49:20 </p> <p>ps</p> <p>Resources:</p> <ul> <li><a href="http://www.f5.com/news-press-events/web-media/" _fcksavedurl="http://www.f5.com/news-press-events/web-media/">F5 Web Media</a></li> <li><a href="http://www.youtube.com/user/f5networksinc" _fcksavedurl="http://www.youtube.com/user/f5networksinc">F5 YouTube Channel</a></li> <li><a href="http://www.f5.com/products/big-ip/global-traffic-manager.html" _fcksavedurl="http://www.f5.com/products/big-ip/global-traffic-manager.html">BIG-IP GTM</a></li> <li><a href="http://www.f5.com/pdf/white-papers/dnssec-wp.pdf" _fcksavedurl="http://www.f5.com/pdf/white-papers/dnssec-wp.pdf">DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks (whitepaper)</a> | <a href="http://devcentral.f5.com/s/weblogs/interviews/archive/2009/12/04/audio-tech-brief-dnssec-the-antidote-to-dns.aspx" _fcksavedurl="http://devcentral.f5.com/s/weblogs/interviews/archive/2009/12/04/audio-tech-brief-dnssec-the-antidote-to-dns.aspx">Audio</a></li> <li><a href="http://www.cricketondns.com" _fcksavedurl="http://www.cricketondns.com">Cricket on DNS</a></li> <li><a href="http://www.youtube.com/user/InfobloxInc" _fcksavedurl="http://www.youtube.com/user/InfobloxInc">Infoblox YouTube Channel</a></li> </ul> <p>Technorati Tags: <a href="http://devcentral.f5.com/s/weblogs/psilva/psilva/psilva/archive/2011/05/09/" _fcksavedurl="http://devcentral.f5.com/s/weblogs/psilva/psilva/psilva/archive/2011/05/09/">F5</a>, <a href="http://technorati.com/tags/webinar" _fcksavedurl="http://technorati.com/tags/webinar">webinar</a>, <a href="http://technorati.com/tags/Pete+Silva" _fcksavedurl="http://technorati.com/tags/Pete+Silva">Pete Silva</a>, <a href="http://technorati.com/tags/security" _fcksavedurl="http://technorati.com/tags/security">security</a>, <a href="http://technorati.com/tag/business" _fcksavedurl="http://technorati.com/tag/business">business</a>, <a href="http://technorati.com/tag/education" _fcksavedurl="http://technorati.com/tag/education">education</a>, <a href="http://technorati.com/tag/technology" _fcksavedurl="http://technorati.com/tag/technology">technology</a>, <a href="http://technorati.com/tags/internet" _fcksavedurl="http://technorati.com/tags/internet">internet, </a><a href="http://technorati.com/tags/big-ip" _fcksavedurl="http://technorati.com/tags/big-ip">big-ip</a>, <a href="http://technorati.com/tag/dnssec" _fcksavedurl="http://technorati.com/tag/dnssec">dnssec</a>, <a href="http://technorati.com/tags/infoblox" _fcksavedurl="http://technorati.com/tags/infoblox">infoblox</a> <a href="http://technorati.com/tags/dns" _fcksavedurl="http://technorati.com/tags/dns">dns</a></p> <table border="0" cellspacing="0" cellpadding="2" width="378"><tbody> <tr> <td valign="top" width="200">Connect with Peter: </td> <td valign="top" width="176">Connect with F5: </td> </tr> <tr> <td valign="top" width="200"><a href="http://www.linkedin.com/pub/peter-silva/0/412/77a" _fcksavedurl="http://www.linkedin.com/pub/peter-silva/0/412/77a"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="o_linkedin[1]" border="0" alt="o_linkedin[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_linkedin.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_linkedin.png" width="24" height="24" /></a> <a href="http://devcentral.f5.com/s/weblogs/psilva/Rss.aspx" _fcksavedurl="http://devcentral.f5.com/s/weblogs/psilva/Rss.aspx"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="o_rss[1]" border="0" alt="o_rss[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_rss.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_rss.png" width="24" height="24" /></a> <a href="http://www.facebook.com/f5networksinc" _fcksavedurl="http://www.facebook.com/f5networksinc"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="o_facebook[1]" border="0" alt="o_facebook[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" width="24" height="24" /></a> <a href="http://twitter.com/psilvas" _fcksavedurl="http://twitter.com/psilvas"><img style="border-bottom: 0px; border-left: 0px; display: inline; border-top: 0px; border-right: 0px" title="o_twitter[1]" border="0" alt="o_twitter[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" width="24" height="24" /></a> </td> <td valign="top" width="176"> <a href="http://bitly.com/nIsT1z?r=bb" _fcksavedurl="http://bitly.com/nIsT1z?r=bb"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_facebook[1]" border="0" alt="o_facebook[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" width="24" height="24" /></a> <a href="http://bitly.com/rrAfiR?r=bb" _fcksavedurl="http://bitly.com/rrAfiR?r=bb"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_twitter[1]" border="0" alt="o_twitter[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" width="24" height="24" /></a> <a href="http://bitly.com/neO7Pm?r=bb" _fcksavedurl="http://bitly.com/neO7Pm?r=bb"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_slideshare[1]" border="0" alt="o_slideshare[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_slideshare.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_slideshare.png" width="24" height="24" /></a> <a href="http://bitly.com/mOVxf3?r=bb" _fcksavedurl="http://bitly.com/mOVxf3?r=bb"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_youtube[1]" border="0" alt="o_youtube[1]" src="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_youtube.png" _fcksavedurl="http://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_youtube.png" width="24" height="24" /></a></td> </tr> </tbody></table></body></html> ps Resources: F5 Web Media F5 YouTube Channel BIG-IP GTM DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks (whitepaper) | Audio Cricket on DNS Infoblox YouTube ChannelThe Skeleton in the Global Server Load Balancing Closet
Like urban legends, every few years this one rears its head and makes its rounds. It is certainly true that everyone who has an e-mail address has received some message claiming that something bad is going on, or someone said something they didn’t, or that someone influential wrote a letter that turns out to be wishful thinking. I often point the propagators of such urban legends to Snopes because the folks who run Snopes are dedicated to hunting down the truth regarding these tidbits that make their way to the status of urban legend. It would nice, wouldn’t it, if there was such a thing for technical issues; a technology-focused Snopes, if you will. But there isn’t, and every few years a technical urban legend rears its head again and sends some folks into a panic. And we, as an industry, have to respond and provide some answers. This is certainly the case with Global Server load balancing (GSLB) and Round-Robin DNS (RR DNS). CLAIM : DNS Based Global Server Load Balancing (GSLB) Doesn’t Work STATUS : Inaccurate ORIGINS The origins of this skeleton in GLSB’s closet is a 2004 paper written by Pete Tenereillo, “Why DNS Based Global Server Load Balancing (GSLB) Doesn’t Work.” It is important to note that at the time of the writing Pete was not only very experienced with these technologies but was also considered an industry expert. Pete was intimately involved in the early days of load balancing and global server load balancing, being an instrumental part of projects at both Cisco and Alteon (Nortel, now Radware). So his perspective on the subject certainly came from experience and even “inside” knowledge about the way in which GSLB worked and was actually deployed in the “real” world. The premise upon which Pete bases his conclusion, i.e. GSLB doesn’t work, is that the features and functionality over and above that offered by standard DNS servers are inherently flawed and in theory sound good, but don’t work. His ultimate conclusion is that the only way to implement true global high-availability is to use multiple A records, which are already a standard function of DNS servers. DNS based Global Server Load Balancing (GSLB) solutions exist to provide features and functionality over and above what is available in standard DNS servers. This paper explains the pitfalls in using such features for the most common Internet services, including HTTP, HTTPS, FTP, streaming media, and any other application or protocol that relies on browser based client access. … An Axiom The only way to achieve high-availability GSLB for browser based clients is to include the use of multiple A records It would be easy to dismiss Pete’s concerns based on the fact that his commentary is nearly seven years old at this point. But the basic principles upon which DNS and GSLB are implemented today are still based on the same theories with which Pete takes issue. What Pete missed in 2004 and what remains missing from this treatise is twofold. First, GSLB implementations at that time, and today, do in fact support returning multiple A records, a.k.a. Round-Robin DNS. Second, the features and functionality provided over and above standard DNS do, in fact, address the issues raised and these features and functionality have, in fact, evolved over the past seven years. Is returning multiple A records to LDNS the only way of achieving High Availability? How is advanced health checking an important component of providing High Availability? Many people misuse the term ‘high availability’ by indicating that it only equates to when a site is either up or down. This type of binary thinking is misguided and is purely technical in focus. Our customers have all indicated that high availability also includes performance of the application or site. The reason is that by business definitions if a site or application is too slow it is unavailable. Poor performance directly impacts productivity, one of the key performance indicators used to measure the effectiveness of business employees and processes. As a result, high availability can be achieved in a number of different ways. Intelligent GSLB solutions, through advanced monitoring and statistical correlation, take into account not only whether the site is up or down, but such detail as hop count, packet loss, round-trip time, and data-center capacity to name a few. These metrics then transparently provide users with most efficient and intelligent way of steering traffic and achieving high availability. Geolocation is another means of steering traffic to the appropriate service location, as well as any number of client and business-specific variables. Context is important to application delivery in general, but is a critical component of GSLB to maintain availability – including performance. The round robin handling of the A records by the Local DNS (LDNS) is a well known problem in the industry. When multiple A records are handed back to the LDNS for an address resolution, the LDNS shuffles the list and returns the A records list back to the client without honoring the order in which it received it. The next time the client requests an address, the LDNS responds with a different ordered list of A records. This LDNS behavior makes it very difficult to predict the order in which A records are being returned to the client. In order to overcome this problem, many prefer to configure a GSLB solution to send back one A record to the LDNS. When compared with just a ‘plain’ DNS server that would send back any one of the site addresses with a TTL value, an intelligent GSLB sends back the address of the best performing site, based on the metrics that are important to the business, and sets the TTL value. A majority of the LDNS that are RFC compliant will honor the TTL value and resolve again after the TTL value has expired. The GSLB performs advanced health checking and sends back the address of the best performing site taking into account metrics like application availability, site capacity, round trip time, hops and completion rate hence providing the best user experience and meeting applicable business service level agreements. In the event of a site failure (when the link is down or because of a catastrophic event), existing clients would connect to the unavailable site for the period of time equal to the TTL value. The GSLB sets a TTL value of 30 seconds when returning an A record back to the LDNS. As soon as the 30 second time period expires, the LDNS resolves again and the GSLB uses its advanced health checking capability and determines that one of the multiple sites is unavailable. The GSLB then starts to direct users transparently to the best performing site by returning the address of that site back to the LDNS. A flexible GSLB will also provides a Manual Resume option that gives them the option of letting the unavailable site stay down to mitigate the commonly known back end database synchronization problem. An intelligent GSLB also has the option of sending multiple A records that allows delivery of content from the best performing sites. For example, let’s say an enterprise wants to deliver their content using 10 sites and wants to provide high availability. Using sophisticated health checking, the GSLB can determine the two best performing sites and return their addresses to the users. The GLSB would track each site’s performance and send back the best sites based on current network and site conditions (context) for every resolution. Slow sites or sites that are down would never be sent back to the user. What about the issues with DNS Browser Caching? Of all the issues raised by Pete in his seminal work of 2004, this is likely the one that is still relevant. Browser technology has evolved, yes, but the underlying network stack and functionality has not, mainly because DNS itself has not changed much in the past ten years. Most modern browsers may or may not (evidence is conflicting and documentation nailing it down scant) honor DNS TTL but they have, at least, reduced the caching interval on the client side. This may or may not - depending on timing - result in a slight delay in the event of a failure while resolution catches up but it does not have nearly the dramatic negative impact it once had. In early days, a delay of 15 minutes could be expected. Today that delay can generally be counted in seconds. It is, admittedly, still a delay but one that is certainly more acceptable to most business stakeholders and customers alike. And yet while the issue of DNS browser caching is still technically accurate, it is not all that relevant; the same solution Pete suggests to address the issue – RR DNS – has always been available as an option for GSLB. Any technology, when not configured to address the issue for which it was implemented, can be considered a failure. This is not a strike against the technology, but the particular implementation. The instances of browser caching impacting site availability and performance is minimal in most cases and for those organizations for which such instances would be completely unacceptable it is simply a matter of mitigation using the proper policies and configuration. > SUMMARY What it comes down to is that Pete, in his paper, is pushing for the use of Round-Robin DNS (RR DNS). Modern Global Server Load Balancing (GSLB) solutions fully support this option today and generally speaking always have. However, the focus on the technical aspects completely ignores the impact of business requirements and agreements and does not take into consideration the functions and features over and above standard DNS that assist in supporting those requirements. For example, health-checking has come a long way since 2004, and includes not only simply up-down indicators or even performance-based indicators but is now able to incorporate a full range of contextual variables into the equation. Location, client-type, client-network, data center network, capacity… all these parameters can be leveraged to perform “health” checks that enable a more accurate and ultimately adaptable decision. Interestingly, standard DNS servers leveraged to implement a GSLB solution are not capable of nor do they provide the means by which such health checks can be implemented. Such “health monitoring” is, however, a standard offering for GSLB solutions. NEW FACTORS to CONSIDER Given the dynamism inherent not only to local data centers but global implementations and the inclusion of cloud computing and virtualization, GSLB must also provide the means by which management and maintenance and process automation can be accomplished. Traditional DNS solutions like BIND do not provide such means of control; they are enabled with the ability to participate in the collaborative processes necessary to automate the migration and capacity fulfillment functions for which virtualization and cloud computing are and will be used. Thus a simple RR DNS implementation may be desirable, but the solution through which such implementations will be implemented must be more modern and capable of addressing management and business concerns as well. These are the “functions and features” over and above standard DNS servers that provide value to organizations regardless of the technical details of the algorithms and methods used to distribute DNS records. Additionally, traditional DNS solutions – while supporting new security initiatives like DNSSEC – are less able to handle such initiatives in a dynamic environment. A GSLB must be able to provide dynamic signing of records to enable global server load balancing as a means to support DNSSEC. DNSSEC introduces a variety of challenges associated with GSLB that cannot be easily or efficiently addressed by standard DNS services. Modern GLSB solutions can and do address these challenges while enabling integration and support for other emerging data center models that make use of cloud computing and virtualization. This skeleton is sure to creep out of the closet yet again in a few years, primarily because DNS itself is not changing. Extensions such as DNSSEC occasionally crop up to address issues that arise over time, but the core principles upon which DNS have always operated are still true and are likely to remain true for some time. What has changed are the data center architectures, technology, and business requirements that IT organizations must support, in part through the use of DNS and GSLB. The fact is that GSLB does work and modern GSLB solutions do provide the means by which both technical and business requirements can be met while simultaneously addressing new and emerging challenges associated with the steady march of technology toward a dynamic data center. So You Put an Application in the Cloud. Now what? F5 Friday: Hyperlocalize Applications for Everyone Location-Aware Load Balancing Cloud Needs Context-Aware Provisioning What is a Strategic Point of Control Anyway? German DPA Issues Legal Opinion on Cloud Computing As Cloud Computing Goes International, Whose Laws Matter? Load Balancing in a CloudDNS is Like Your Mom
Both are taken for granted but provide vital services without which you and your digital presence would be lost. In the case of DNS, that should be taken literally. Mom. She’s always there, isn’t she? She kissed away your bumps and bruises. You treated her like Google before you had access to the web and, like Google, she came through every time you needed to write a report on butterflies or beetles or the pyramids at Giza. You asked her questions, she always had an answer. You didn’t spend as much time with her as you grew older (and discovered you knew way more than she did, didn’t you?) but when you needed money or life kicked you in the face, she was there for you, as always. Steady, reliable, good old mom. You’d be lost without her, wouldn’t you? Go ahead – give her a call, shoot her an e-mail, write on her Facebook wall, order some flowers. I’ll wait. Now that we’re ready, consider that there are some components of your infrastructure that are just as valuable to your organization’s digital presence as your Mom is to you. Unfortunately we also tend to take them for granted. TAKEN FOR GRANTED DNS is rarely mentioned these days except when it’s the target of an attack. Then we hear about it and for a few moments DNS is as it should be – a critical data center service. It’s like Mother’s Day, only without the dandelions posing as flowers and Hallmark cards. But once the excitement over the attack is over, DNS goes back into the bowels of the data center and keeps chugging along, doing what it does without complaint, patiently waiting to be appreciated once again. Okay, okay. Enough of the guilt trip. But the truth is that DNS is often overlooked despite its importance to just about everything we do. It is the first point of contact with your customers, and it is the gatekeeper to your entire domain. Without it, customers can’t find you and if they can’t find you, you can’t do business. It’s the cornerstone, the foundation, the most critical service on the Internet. And yet it remains largely unprotected. The reasons for that are many, but primarily it’s because DNS needs to interact with the public, with the unknown. Its purpose in the architecture of the Internet is to be the authoritative source of where a given service resides. Queries to the root servers happen on the order of millions of times a second. Other DNS services are similarly stressed. There are two primary concerns for DNS: Load Authenticity Load is a concern because it’s possible to “take out” a DNS server simply by overloading it with requests. It’s a denial of service attack on your entire organization that takes away the ability of clients to find you; making you all but invisible to the entire Internet. The second problem is one that’s more recent, but just as dangerous: authenticity. This issue speaks to the ability to “hijack” your DNS or poison the cache such that customers looking for your latest gadget or service or what have you end up listening to Justin Bieber instead. Okay, maybe that’s too harsh an image. Maybe they redirect to a competitor’s site, or to a porn site, or something less horrifying than Bieber. You get the picture – it’s bad for you and your organization’s reputation when this happens. Point is, your DNS services can be hijacked and the result is that your sites and applications are effectively lost to the general public. Customers can’t find you, remote or roaming employees can’t access business critical applications, and you might find yourself associated with something with which you’d rather not have your organization tied. DON’T MAKE DAD ANGRY Your DNS infrastructure is critical. DNS itself is an aging protocol, yes, but it does what it’s supposed to do and it does so in a scalable, non-disruptive way. But it does need some attention, particularly in the area of load and authenticity. To help relieve some of the stress of increasing load and the potentially devastating impact of an overload from attack, consider the benefits of load balancing DNS. Load balancing DNS – much in the same way as load balancing web services and applications – provides a plethora of options in architecture and resource distribution that can address heavy load on DNS infrastructure. cloud computing can play a role, here, if the DNS services are virtualized in the architecture by an upstream application delivery solution. The strategy here is to scale out DNS as needed to meet demand. That’s of particular importance if the upstream components (if there are any) are not capable of detecting and responding to a DNS-based DDoS attack. It’ll cost you a pretty penny to scale out your DNS farm to respond, but on the scales balancing uptime of your entire digital presence with costs, well, even the business understands that trade-off. Don’t discount the impact of a dynamic data center on DNS. DNS wasn’t designed to be constantly updated and yet the nature of highly virtualized and cloud computing environments requires just that – rapid changes, frequently. That will have an impact on your DNS infrastructure, and can negatively impact the costs associated with managing IP addresses. This is the core of the economy of scale problem associated with the network in relation to cloud computing and virtualization. It’s why automation and orchestration – process – will become critical to the successful implementation of IT as a Service-based initiatives. Yet another facet of DNS that might have been thus far overlooked. To address the Justin Bieber problem, i.e. hijacking or poisoning of a DNS cache, implement DNSSEC. It’s one of the few “new” standards/specifications relating to DNS to hit the wires (literally) and it’s a good one. DNSSEC, if you aren’t familiar, leverages the foundation of a public key infrastructure to sign records such that clients can be assured of authenticity. Because miscreants aren’t likely to have the proper keys and certificates with which to sign responses, hijacking your name services really can’t happen in a fully DNSSEC-compliant world. Problem is, it’s not a fully DNSSEC compliant world. Yet. Movement is slow, but the root servers are being protected with DNSSEC and that means it’s time for organizations everywhere to start considering how to implement a similar solution in their own infrastructure. Because it’s quite possible that one day, clients will reject any non-secured response from a DNS service. And if you think your mom feels bad when you don’t answer her calls (damn caller ID anyway) your DNS service will feel even badder. Or the business will, which is probably worse – cause that’s like your dad getting on your case for not answer your phone when your mom calls. DNS CRITICAL to CLOUD-BASED STRATEGIES As we continue to move forward and explore how IT can leverage cloud-based compute to extend and enhance our IT strategies we find more and more that DNS is a critical component to those strategies. Extending the data center to include external, cloud-deployed applications requires that customers be able to find them – which means DNS. When migrating applications between locations for any reason, DNS becomes a key player in the move – ensuring new and existing connections are properly directed to the right location at the right time. DNS is one of the core technologies required to implement a cloud bursting strategy . DNS is the foundation upon which dynamic and mobile compute can be leveraged both internal and external to the data center. DNS is key to cloud computing, whether it’s public, private, or hybrid. DNS is old, yes. It’s outdated, yes. It is like just like your mom. And like your mom, it should be treated with the respect it deserves given its critical role in just about every facet of your organization’s digital “life”. It’s DNSSEC Not DNSSUX VeriSign: We will support DNS security in 2011 New DNS exploit now in the wild and having a blast The Official, Unofficial, DNS Security Extensions Blog The End of DNS As We Know It Taking Down Twitter as easy as D.N.S. Building a Cloudbursting Capable Infrastructure Cloud Balancing, Cloud Bursting, and Intercloud Achieving Enterprise Agility in the Cloud (Cloudbursting with VMware, BlueLock, and F5) DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks DNSSEC Solutions DNSSEC: Compliance is Easier Than you Think
