Web Development

DNS resource record integrity is still a big, big problem

The need to secure DNS has never been greater. Attacks against DNS cache integrity, including entire zone references, are an easy way for criminals to redirect your unsuspecting users to malicious sites. Current controls are still lacking.

The need to secure DNS has never been greater. Attacks against DNS cache integrity, including entire zone references, are an easy way for criminals to redirect your unsuspecting users to malicious sites. The IETF and others are working on a set of security extensions to protect the integrity of DNS information as it is shared across the Web. However, these extensions, known as DNSSec, are far from globally accepted, and it will probably be years before they are implemented for all DNS transactions.

So what can you do today to protect your users? Quite a bit, actually. But before we get to the DNS security checklist developed by the U.S. National Institute of Standards and Technology (NIST), it’s important to understand the role DNSSec will play in the future and why its implementation is an important part of global Internet security.

In this article I review how DNS works and I define DNS cache poisoning. In the next article, I describe DNSSec, how it will eventually provide protection from malicious redirection, and what you can do until DNSSec becomes a reality.

DNS review

The DNS (Domain Name System) is a critical component of not only the Internet, but also internal network operation. It uses distributed repositories to convert human-friendly addresses to IP addresses. For example, converting the domain name google.com to 64.233.187.99 or mail.google.com to 64.233.183.17. Routers need the numeric version to make sure packets make it to the right network segment, no matter where it might exist.

Figure 1 depicts the IP address resolution process when the target system and DNS server are both internal. In this example, a workstation must establish a session with a server in Farpoint.company.com. In order for a workstation to implement DNS, it must be running a DNS Client or Client Resolver. The resolver initiates the following process, resulting in the conversion of the domain name to an IP address (Microsoft TechNet, 2008).

Figure 1: Internal Resolution Figure 1

Step 1: The resolver checks the resolver cache in the workstation’s memory to see if it contains an entry for Farpoint.company.com. The entry would be present if the workstation had resolved the name to an IP address since the last time it was powered on, and the Time to Live of the entry had not been exceeded. In this example, no entry is found.

Step 2: Having found no entry in the resolver cache, the resolver sends a resolution query to the internal DNS server.

Step 3: When the DNS server receives the query, it first checks to see if it can authoritatively answer a query about resources in company.com. If it can, the server performs a lookup in its internal zone table. In this case, it finds a host Resource Record (RR) that includes the IP address for Farpoint.company.com.

Step 4: The IP address of Farpoint.company.com is returned to the resolver.

Step 5: The resolved domain name and IP address are placed into the resolver cache. Figure 2 is an actual listing of the contents of a workstation resolver DNS cache.

Figure 2: Resolver Cache Figure 2

In the previous example, the target server was located within the requestor’s network. But what if the target device is located somewhere on the Internet? In that case, the process is somewhat different. Please refer to Figure 3 as we step through this second DNS resolution process.

Figure 3: Recursive Query Figure 3

Step 1: The resolver checks the resolver cache in the workstation’s memory to see if it contains an entry for Farpoint.companyA.com.

Step 2: Having found no entry in the resolver cache, the resolver sends a resolution request to the internal DNS server.

Step 3: When the DNS server receives the request, it first checks to see if it’s authoritative. In this case, it isn’t authoritative for companyA.com. The next action it takes is to check its local cache to see if an entry for Farpoint.companyA.com exists. It doesn’t. So in Step 4 the internal DNS server begins the process of iteratively querying external DNS servers until it either resolves the domain name or it reaches a point at which it’s clear that the domain name entry doesn’t exist.

Step 4: A request is sent to one of the Internet root name servers. The root server returns the address of a server authoritative for the .COM TLD (Top Level Domain).

Step 5: A request is sent to the authoritative server for .COM. The address of a DNS server authoritative for the companyA.com domain is returned.

Step 6: A request is sent to the authoritative server for companyA.com. The IP address of Farpoint.companyA.com is returned.

Step 7: The IP address for Farpoint is returned to the client resolver.

Step 8: An entry is made in the resolver cache, and a session is initiated with Farpoint.companyA.com.

This process, from the client resolver perspective, is known as a recursive query.

A summary of DNS cache poisoning issues

When attackers want a DNS server to hand out IP addresses to their servers, they must use some method of replacing valid addresses on the caching server with their own. There are few controls to ensure the integrity of a query response, that it came from a server authorized to provide resolution information. Once the attacker’s information is written to a caching server or to a resolver’s cache, DNS cache is said to be poisoned. A more detailed description of one way this might happen is found in DNS Cache Poisoning: Definition and Prevention. Another method, recently disclosed by Dan Kaminsky, is described in An Illustrated Guide to the Kaminsky DNS Vulnerability.

One method developed to help prevent cache poisoning is randomization of the transaction ID. Each DNS query is assigned an ID. Randomizing this value makes an attacker’s job a little harder. Current DNS solutions support this feature, but Kaminsky demonstrated that it isn’t enough to provide reasonable and appropriate protection.

Adding query source port randomization to transaction ID randomization is a good way to increase an attack’s work factor. Instead of an attacker knowing only the transaction ID, he or she also has to know the port from which the transaction was sent. A securely configured DNS server using the most current iteration of BIND, for example, could randomize the port used instead of settling on port 53.

Although this is a big step forward, there are still many DNS servers not using this feature, putting systems querying them at risk. And even if all DNS servers on the Internet used a combination of transaction ID randomization and source port randomization, this should be considered an interim solution at best. The entropy provided is not sufficient to dissuade a tenacious attacker.

The final word

In the next post, we’ll look at what international organizations are doing to strengthen DNS integrity via DNSSec. Since DNSSec is still far from globally deployed, we’ll step through the NIST checklist for securely deploying DNS services without it.

Worried about security issues? Who isn't? Delivered each Tuesday, TechRepublic's IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

About

Tom is a security researcher for the InfoSec Institute and an IT professional with over 30 years of experience. He has written three books, Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide (to be publish...

5 comments
dmk45044
dmk45044

"never been greater" Cite the last DNS attack please. Not Checkfree, that was a domain registration attack. Cite the last attack on a DNS server that resulted in a loss. This may be a big vulnerability but in the absence of it being attacked, it not a big, big problem; it's not a risk.

Slamlander
Slamlander

The first instance that I know of, of cache poisoning was Kashpuref's play against the root-servers.net network. It's definitely still an issue, albeit not as vulnerable as during Kashpuref's day. That said, mostly it is an issue of lax configuration of the DNS servers, many of which are with ISPs. I have my own root server for an internal TLD. That root server is behind a NAT wall and simply not visible from the Internet. In addition, it does not refer to my ISP's DNS system at all, going instead directly to the gtld-servers that actually source the DNS data from their respective registries. Mostly, they are immune from cache-poisoning because, as source servers, they are not allowed to be recursive. The randomized port solution has problems in the presence of firewalls and NATwalls. You simply cannot pinhole route a randomized port. This is why it is not more widely used. The best way is to only use trusted DNS servers and the top of the list of those that you don't dare trust are those that belong to your ISP.

Michael Kassner
Michael Kassner

Thanks, Tom It is still an issue and experts are starting to wonder if DNSSec is the answer. The performance hit and bandwidth requirements may be too much for the backbone networks.

JCitizen
JCitizen

I suppose if you or your organization don't have anything to lose, you are right. But the threats out there are growing exponentially, and we see no choice but to adopt a proactive attitude. To me the process of attack doesn't look that difficult, especially where a large target could net a big reward.

JCitizen
JCitizen

it looks like they farm DNS out to a third party for internet resolving. I'm fairly confident their internal servers are well hidden from the cloud.