As I’m fond of saying, back in the early days of BIND name servers—when I got my start in DNS—they had a whopping two security features: They didn’t accept responses from IP addresses they hadn’t queried (colorfully known as “Martian responses”) and they stuck a random, 16-bit number into outbound queries and verified that the number came back in responses.[1]
For a very long time, DNS servers were mostly the target of attacks. There were the “three K’s”: cache poisoning attacks dreamed up by Eugene Kashpureff, Amit Klein and Dan Kaminsky. (I should point out that only one of them, Kashpureff’s, was ever used in anger. Klein and Kaminsky discovered theirs and reported them responsibly.) There was the Li0n worm, which capitalized on a vulnerability in BIND. And of course, DNS servers of all stripes are commonly both used as amplifiers in DDoS attacks and are themselves the targets of DDoS attacks.
Within the DNS community, we concentrated largely on the security of DNS servers and the DNS system. BIND was enhanced to support access control lists on almost everything: queries, recursive queries, zone transfers, and dynamic updates. We began running DNS servers in chrooted environments, using the principle of “least privilege .” And we introduced Transaction Signatures (TSIG) and the DNS Security Extensions (DNSSEC) to help safeguard DNS data.
It’s only been very recently in DNS’s history that we’ve realized the potential of DNS servers as security tools. With the advent of Response Policy Zones in 2008, we could instrument our DNS servers to issue “benevolent lies” when queried for information we knew could harm the querier and, perhaps equally importantly, we could tell when someone queried our DNS servers for data we knew was malicious.
This begat a blossoming of companies that produce DNS threat intelligence in the form of RPZs and distribute them to subscribers, either for a fee or free of charge (Infoblox does this, as do partners including Farsight Security). Now you can plug a variety of RPZ “feeds” into your DNS infrastructure and enable your DNS servers to protect your users and systems from known malware distribution sites, command-and-control infrastructure, and much more.
RPZs are also enormously useful in helping detect infections and breaches. A laptop that sends a query for a domain name uniquely used by a particular species of malware is almost certainly infected with that malware.
This is in addition to the ancillary role that DNS servers can play in tracking those same infections and breaches. Many security-conscious companies now archive all DNS query logs so that, if a breach is uncovered, they can determine which other systems the bad guy accessed and how he moved through the network. Without this supporting data, IT organizations may not be able to reconstruct that activity.
The most advanced companies and vendors feed DNS telemetric data—what we in the biz call “passive DNS”—into data stores and then run machine learning algorithms over it. Sophisticated ML algorithms can detect all kinds of malicious activity in passive DNS data: queries sent by malware’s Domain Generation Algorithms (DGAs), for example, or queries for lookalike domain names masquerading as well-known, legitimate destinations.
All of this, I think, proves that DNS is an indispensable part of a modern security toolkit, playing both an active and a supporting role in keeping networks secure and tracking malicious activity. This month—Cybersecurity Awareness Month—I hope that you’ll take a look at your own DNS infrastructure and think about how you could enhance it to tighten your defenses.
[1]Also, we later found out that the number wasn’t particularly random.
