DNS was created way back in 1983 with a couple of original RFCs, then many subsequent RFCs to enhance it. DNS is the address book for the entire internet – a multi-level database and lookup mechanism distributed throughout the world. Since DNS is mapping domain names to actual network resources, you can be sure DNS performance and security are critical for any web-based application you are offering, managing or using.
DNS is our root of trust – you just hope when you type in an IP address you’re really going to where you want to go. From a security perspective, it’s such a dream situation for bad guys – big juicy targets, and older, hard-to-secure technology. What could go wrong? Well, it turns out that plenty can go wrong. The fact that DNS has been around so long is part of the problem. It was designed way before the current horrific infosec situation, with new data breaches occurring on a regular basis to some of the largest companies in the world. In addition, makeshift security measures have been “Frankensteined” without forethought on to the old infrastructure. Not surprisingly, there are plenty of DNS exploits running around in the wild. Here are some examples:
DNS Security Threats
- DNS Cache poisoning. Remote DNS data is locally cachable to speed up local lookups and improve performance. DNS Cache poisoning works two basic ways: the attacker can either trick a DNS server into caching a false hostname-IP mapping, or the attacker can spoof the NS entry of target domain to his evil IP.
- Malicious Zone files / DNS server configuration corruption
- Unauthorized zone file dynamic updates
- DNS Zone Transfer Attack which exploits the capability of a DNS server to copy a zone of its database to another DNS server
- Resolver cache poisoning / data interception – can be addressed by restricting access of the resolver to users on your network
- DNS Distributed Denial of Service (DDoS) amplification attack with amplified replies to impact the victim
- Reflection attacks are where the attacker delivers traffic reflected from a third party so that the victim can’t tell who the attacker is. The Distributed, Reflected DoS (DrDoS) Attack takes advantage of the recursive name servers throughout the internet. It uses a spoofed IP source address and the DNS server replies to the victim & amplifies packet size.
When problems like a lack of security in DNS arise, engineers (being the problem-solvers they are) are going to attempt to propose solutions. Domain Name System Security Extensions (DNSSEC ) are specs from the IETF to help secure DNS. The first RFC around DNSSEC was published by the IETF in 1997.
DNSSEC provides authentication and data integrity not addressed with DNS. DNSSEC acts as an anchor for a chain of trust and protects against cache poisoning. DNSSEC can protect additional information via TXT records.
But with the advantages of DNSSEC, there are issues introduced. Large responses associated with DNSSEC tend to make DDoS problems even worse. In addition, DNSSEC can cause problems with split zone deployments. It can also hand back incorrect answers as a feature, which is sort of a mixed blessing. DNSSEC doesn’t solve data privacy issues with DNS. Crawling zones is mitigated but not solved. So the decision to use DNSsec isn’t exactly “slam dunk” decision yet. It’s the kind of a situation where adding security features to an old infrastructure just doesn’t work as well as designing security into the infrastructure in the first place.
Here’s some technical advice on securing and configuring a DNS from NIST.
Of course, since I work for AlienVault, I’d like to give Unified Security Management (USM) a plug here – it’s got technology including Security Information and Event Management (SIEM) and Intrusion Detection Systems (IDS) as well as vulnerability management – all of which are great ways to address the potential security issues with DNS.
About the author – Kate Brew is an advisor to NetBeez with over 20 years of experience in IT product management and marketing with Tivoli, SolarWinds, and AlienVault.