With all the recent news about a massive DDoS attack affecting DNS servers on the Internet, this is a good time for me to discuss the next critical feature in the DNS infrastructure. It is important to secure one’s DNS architecture. Not only do you deliver availability by protecting the DNS servers, but you add a measure of data assurance, validating the DNS information integrity.  Not all security threats are Denial of Service (DoS) attacks, though.

It is possible that this attack is a smoke screen for a more targeted attack buried within it. For example, the buried targeted attack may compromise the DNS database and be used for personal identity theft. It is not a fun situation when someone else usurps your identity and uses it to take advantage of your credit rating or even take your hard-earned money out of your bank accounts. Websites are also subject to identity theft. Just like the individual identify theft scenario, it is possible to intercept, redirect or generate content and traffic made to look like a legitimate website.

You might think that when you type a web address such as www.f5.com, you are guaranteed to access the legitimate webpage produced by F5 Networks. Of course, I am here to tell you that this may not be the case. To get from www.f5.com to the website, we have learned in my previous blogs that there is an entire critical infrastructure on the Internet called Domain Name Services (DNS) that translate names like that easy to remember web address to IP addresses like M.N.O.P. A malicious user could be able to manipulate DNS so that the answer you get for www.f5.com is not M.N.O.P but W.X.Y.Z instead.

It is possible to compromise the integrity of DNS services in many ways. Several years ago, a researcher named Dan Kaminsky discovered a flaw in the DNS protocol and its implementation in most DNS servers available called cache poisoning. Kaminsky discovered a method to insert bad information into good DNS servers so that they answered DNS requests with incorrect and usually malicious information, sending unsuspecting people to websites and resources that looked and acted legitimate, but were managed by the malicious person. This attack involved inserting incorrect information into the DNS cache and was appropriately coined as a DNS cache poisoning attack. Unfortunately, if done properly, there is almost no way the innocent person accessing this fake website will know that they are transmitting personal and sensitive information directly to the thieves. This is a DNS vulnerability with a very high potential for misuse that affects every single Communications Service Provider (CSP) worldwide and the entire Internet.

DNSSEC – The Cure for the Internet?

While this DNS cache poisoning flaw was patched in the DNS server software, there are inherent limitations in the DNS protocol that still make this a valid method to attack and compromise DNS servers and websites. In 2008, a researcher, Evgeniy Polyakov, showed that it was possible to cache poison a DNS server that was patched and running current code within 10 hours.  Imagine how quickly it could be done today with modern computing power and high speed Internet access.

The proper solution to this and other vulnerabilities which compromise the integrity of DNS information is DNSSEC. DNSSEC was introduced to specifically correct the open and trusting nature of the protocol’s original design. DNS queries and responses are signed using keys that validate that the DNS answer was not tampered with and that it came from a reliable DNS server. Unfortunately, the design of DNSSEC means many more steps to get DNS resolution since servers need to exchange keys and establish a method of secure and reliable communication. This means that an average recursive DNS query can go from 4 steps to 15 steps or more. Slow DNS responses means that Internet users will see their applications and websites loading slower.

DNSSEC validation

Since DNSSEC involves keys and signatures, this also means that there is additional processing overhead on the servers to generate DNS responses. This overhead slows down the servers and reduces the overall capacity of these servers. In addition, DNSSEC was designed with static pre-signed signatures and DNS responses in mind.  Global Server Load Balancing (GSLB), which is used in cloud network and high availability designs, modifies DNS responses based on dynamic criteria which requires that DNS responses receive a new signature for each individual response. Most DNS servers are not built to handle the creation of DNSSEC signatures dynamically for each DNS response due to the high performance impact. 

As we learned earlier, DNS query capacity is critical to delivering a resilient available DNS infrastructure. CSPs need to be leading the adoption of DNSSEC in the Internet community. Unfortunately, due to these implementation concerns, they have been slow to upgrade their infrastructure to support DNSSEC. There are some options available that mitigate these difficulties, including solutions delivered by F5 Networks.

Are You Asking What I Think You are Asking?

It is important to validate that the queries being sent by the clients are ones that the DNS servers are interested in answering, and are able to. A DNS firewall or other security product can be used to validate and only allow the DNS queries that the DNS server is configured for. When the DNS protocol was designed, there were a lot of features built into the protocol that are no longer valid due to the evolving nature of the Internet. This includes many DNS query types, flags available and other settings.  One would be surprised at what types of parameters are available to mark on a DNS request and how they can be manipulated.  For example, DNS type 17=RP, which is the Responsible Person for that record.  In addition, there are ways to disrupt DNS communications by putting bad data in many of these fields. A DNS firewall is able to inspect these DNS queries and drop the requests that do not conform to DNS standards and do not use parameters that the DNS servers are configured for.

Since we are discussing firewalls, we might as well add to the firewall the ability to mitigate layer 2-4 DDoS attacks such as SYN-flood (note that the majority of DNS requests are UDP so there should be very few TCP SYN packets being sent under normal circumstances), UDP flood, ICMP flood, ACK flood, and others. Filtering and cleaning traffic at this layer reduces the content inspection performance requirements as the firewall delves deeper into the packet payload. Note that this DNS firewall needs to be high performance, since it will be inspecting all of the DNS queries sent to the DNS server and a DDoS to the DNS firewall is just as good as a DDoS to the DNS server.

As one can see, there are multiple levels where one needs to address security for DNS infrastructures. There is no silver bullet, as one would expect, that fixes all the flaws and vulnerabilities within the DNS protocol and most architectures. CSPs need to look at their DNS infrastructure and all aspects of their network to determine all the points where they need to harden their solution.