DNS is the little black book of the Internet (and our networks). Calling little is somewhat of a understatement, as currently the Domain Name System provides name resolution for the Internet (and the Internet is definitely not little).
As such, if you ever left your phone unlocked (and you have devious enough friends) I’m sure you have experienced the fun of sending a message to your girl/boyfrined just to find out that it was routed to your mom/dad.
[That was an extreme oversimplification of what happens when someone messes with records on a DNS server].
DNS servers, resolve names to IP addresses (similar to how a contact list resolves a name to a phone number).
To improve the functionality of DNS in general, DNS uses a hierarchical and distributed structure.
When you access your web browser, and you type an adderss (e.g. www.gmail.com), you OS will contact it’s configured server and ask for an IP address (yes, there are a few steps I left out for brevity....if you are looking for an accurate account of how DNS works, look elsewhere please...).
“Your” DNS server doesn’t hold all the names and addresses on the Internet (hierarchical and distributed, remember?), so it will query the relevant servers (starting at the root, going to the relevant top level domain (TLD) server) and eventually getting an answer.
This answer, is returned to you- and you access your destination. In this case it’s the GMAIL service. The GMAIL website greets you and asks you for your username and password...you provide them. Sadly, you receive a message saying that the servers are under maintenance and that you should reconnect in an hour...Unhappy, you come back in an hour, just to find out that your GMAIL/Facebook/Twitter/etc. account has been hacked.
Well, someone switched between your girlfriends and your mom’s phone numbers on your contact list...kinda.
To improve the DNS servers ability to reply to queries, it uses a local cache. Meaning that once it has resolved a query for WWW.GMAIL.COM it’s going to cache it (for a while-TTL). This saves a lot of traffic, especially for popular queries (how many people access GMAIL/Facebook/Twitter from your network).
A malicious person (love the word malicious), can poison that cache by:
Sending a query for a site (e.g. www.gmail.com)
Sending replies of it’s own for the query
Making it worse by adding additional information about other domains and name server responsible for those domains to the fake reply
Essentially, it’s a race. After the original query is created, bombarding the server with replies hoping it will accept one of them and use them...but wait, how can this happen? Is “our” DNS server so stupid that it doesn’t understand that the replies are coming from someone else? [Yes]
Since the process is managed by UDP, with a predictable port (53) and predictable sequence numbers, the answer is yes.
Once the information is committed to the server’s cache, all subsequent answers will have incorrect information.
So how can this be mitigated: randomization. First of all lets randomize the port that the DNS server is using. Windows 2012 R2 uses a pool of 2500 ports that it can choose from.
dnscmd /info /socketpoolsize
dnscmd /config /socketpoolsize <range>
https://technet.microsoft.com/en-us/library/ee649174(v=ws.10).aspx
https://support.microsoft.com/en-us/kb/956188
Another interesting option to consider is DNS Cache Locking. This feature will protect cached entries until their TTL runs out. In other words, from now on instead of ignoring TTL within the cache, TTL has say. In my humble opinion this is a two edged sword, since if your cache is poisoned, correct replies won’t be able to fix the problem.
On the other hand, if you have been compromised by receiving an answer for one site[gmail] (and this answer included additional information about a bank, which is the real vector of attack), this is useful.
dnscmd /Config /CacheLockingPercent <percent>
Additional and extremely interesting reading on the topic:
http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture17.pdf
https://www.cs.utexas.edu/~shmat/shmat_securecomm10.pdf