DNS is a network client/server protocol that allows clients to resolve hostnames into IP addresses (and vice-versa).  The DNS protocol and most DNS implementations, both client-side and server-side, have had a very troubled past.  This diary entry will provide a quick description of the DNS protocol and some of the different threats/attacks against it.  There is probably over 100 RFCs dealing with different aspects of DNS, so this diary is only going to hit a couple of the high level points.

The most common form of DNS is a client requesting resolution of a hostname to IP address.  For this, the client sends UDP port 53 packet in the appropriate format to it's configured DNS name server.  That server then looks in it's local cache and if not found, attempts to resolve the query against other DNS servers on the Internet.  There is a complicated hierarchy of DNS servers on the Internet that is seeded by 13 root DNS servers, which point to other nameservers for top-level domains like .com, .net, .uk, .de, etc.  There are only 13 named servers because of the maximum 512 byte UDP limitation in the DNS protocol; in practice many of the servers are load-balanced and/or use anycast so that they are geographically dispersed.

DNS servers have "zone files" that contain the hostname to IP address tables and reverse files that do the opposite.  It is also common/recommended for DNS servers to be setup in a master/slave relationship where the slave servers will download the zone files from the master at configured intervals.  The zone transfer occurs over TCP port 53, for reliability.

DNS uses UDP for speed, but there is a 512-byte size limit on the original DNS protocol.  If a query response exceeds 512-bytes, the server flips on the TC bit in the reply header.  A client receiving this will then retry the query using TCP to receive the full response.  I have often seen firewall administrators get this wrong and filter all TCP 53 to their DNS server (except for external slave DNS servers) and everything works fine until they have long DNS replies and their server is telling clients to retry with TCP, only to be blocked by the organization's firewall.

From a threat perspective, there have been a number of different attacks against the DNS protocol.  The most damaging protocol attack is called cache poisoning and when performed successfully allows an attacker to modify IP/hostname information in a DNS server's cache.  The cache poisoning can happen in different ways and there have been preventions implemented in DNS servers when these weaknesses were discovered, but most experts agree that the only way to effectively prevent against these attacks at a protocol level is with DNSSEC.  Cache poisoning has been seen in the wild over the years and the results were quite spectacular, but the attackers were overzealous and easily identified.  A successful cache poison attack that is surgically executed would be hard to detect.

The second threat against DNS is standard programming errors in client or server daemon code.  BIND is the most common DNS server implementation and there has been remote exploits against it in the past.  Also, there have been problems in numerous client resolver libraries that could be exploited with malicious DNS servers.

It should be noted that an attacker who can see your DNS queries can also forge responses so that he controls the IP address returned.  Until DNSSEC is fully implemented, this is just an architectural weakness (and an unfortunate result of the performance/security tradeoff).  That is why SSL is so important for anything critical.

Public DNS servers are also used for reflective DoS attacks.  Attackers can send spoofed IP packets with a small query that results in a larger DNS reply packet.  The unwitting DNS server responds with a large packet to the victim.  Network/system administrators should check their public DNS servers and ensure that they do not allow public recursion.

There is a push now to implement DNSSEC, which is basically an extension to DNS providing signatures of the DNS zone files.  This would prevent many of the attacks against the DNS protocol.  However, progress to implement DNSSEC has been purposefully slow and deliberate, so that the DNS operators don't "break the Internet".

Here are some URLs that provide some background information:

D.J. Bernstein's intro to DNS: http://cr.yp.to/djbdns/intro-dns.html
The DNS network protocol: http://www.networksorcery.com/enp/protocol/dns.htm
DNS research papers: http://dns.measurement-factory.com/writings/
DNS cache poisoning attacks in 2005: http://isc.sans.org/presentations/dnspoisoning.html


-Kyle Haugsness