by Tim Rooney, Product Management Director, BT Diamond IP
In an email notification to subscribers to the Internet System Consortium (ISC) mailing lists on July 8, 2008, a vulnerability to DNS cache poisoning was announced. When browsing the web or using email, DNS serves the crucial function of converting the entered web site name or email address into Internet Protocol (IP) addresses that computers can use to connect and serve these applications via the Internet. For example, when you enter a website address, www.example.com, your browser performs a DNS lookup, gets an IP address, then connects to that IP address to fetch the web page.
The Poisoning of the Cache
The issue with cache poisoning is that falsified information may be returned with the DNS lookup, causing your browser to connect to a falsified IP address and web page. This “website hijacking” attack could be used as a form of phishing attack to obtain personal information, which you may believe you are entering on a legitimate website. The code on your computer that performs the DNS lookup is called a resolver and the DNS server your resolver queries is typically referred to as a recursive server. The term “recursive server” relates to the fact that for a single lookup requested by the resolver, the recursive server may need to query several other Internet DNS servers to obtain the desired answer. Cache poisoning occurs when a resolver or recursive DNS server queries another server in an effort to answer a query, and an attacker spoofs the query response to the resolver or recursive server. This can occur when the attacker impersonates the queried server by using an appropriate DNS message. In the case of the recursive server receiving such an answer, it not only supplies the resolver with the falsified information, it caches the information such that future queries, at least during the valid time interval of the answer, are answered with the same falsified information.
From a technical standpoint, each DNS query includes a transaction ID. In older releases of DNS (commonly referred to as BIND, which is ISC’s implementation), the transaction ID was simply incremented by one for each query. This made it quite trivial for impersonators to guess the next transaction ID in order to spoof an answer. Fortunately modern BIND versions randomize the 16-bit transaction ID field. The other “match criterion” besides transaction ID commonly used by a resolver or recursive server to match an answer to a prior query is the User Datagram Protocol (UDP) port number. DNS queries are typically transmitted over UDP, a protocol layer that sits above IP in the TCP/IP protocol stack. When a resolver or recursive server issues a query, it selects a source UDP port, say 20053, and typically uses the well-known DNS service UDP port, 53, as the destination port. Port numbers enable the server receiving the IP packet to identify for which application running on the server this packet is intended. The source port is selected by the sender to enable correlation of return packets to this communications session.
When an answer comes back from the queried DNS server, the resolver or recursive server verifies the answer packet’s source IP address and UDP port number as well as the addressed IP address and port to which the answer is directed. If the IP addresses and ports match based on what was originally sent in the message, and the transaction ID matches, the answer is accepted. The server or resolver will typically cache this answer temporarily to reuse it for similar future queries for the same information.
The Antidotes
The ISC email announced the availability of a software patch for various BIND versions to address the issue. The resolution implemented in the patch entails the use of a larger pool of potential UDP ports for use on outgoing DNS queries (such as 20053 in the example above). By randomly selecting a source port over a larger pool of ports, the probability of an attacker correctly guessing this port and the already randomized transaction ID are diminished….diminished, not eliminated. ISC pointed this out in its email by stating that “DNSSEC is the only definitive solution for this issue.” After leading us to the solution, ISC went on to say, “understanding that immediate DNSSEC deployment is not a realistic expectation, ISC is releasing patched versions of BIND that improve its resilience against this attack.”
Hence the question, is DNSSEC the answer? Before you rush to figure out how to sign your zones to support DNSSEC, let’s step back and see how DNSSEC works and why signing your zones may do little to solve this issue. DNS Security Extensions, DNSSEC, attempts to secure the DNS lookup process. It enables a resolver or recursive server to authenticate an answer as having originated from the intended recipient of the query, and it validates that the answer provided is the answer configured on the server queried; i.e., the answer was not altered en route. Thus DNSSEC provides origin authentication and end-to-end data integrity verification of the DNS answer. So any impersonator providing a falsified answer can be identified and ignored. Clearly, DNSSEC provides a definitive solution to cache poisoning!
Who Do You Trust?
The problem arises with configuring resolvers and recursive servers with information needed to validate DNSSEC-signed responses. To understand why, let’s look at how DNSSEC works at a basic level. The DNS administrator for a zone, example.com, would like to apply DNSSEC by signing the zone. Signing the zone requires complex arithmetic operations of the hashing the zone data and signing it with a private key, which yields a set of digital signatures. The private key, which must be securely stored by the administrator, has a corresponding public key which can be used to verify the signature on the signed data. So if you have the data, the signature and the public key, you can verify the signature as valid and hence confirm that the holder of the private key published the data and that it was not modified in transmission.
Fortunately, the BIND distribution from ISC ships with a couple of utilities to automate the generation of keys and signing of zones. But simply signing a zone does not enable a resolver or recursive server to validate it. Any attacker can attach a signature with DNS lookup information when answering a query! The resolver or recursive server must still verify the signature. This verification process entails comparing the public key used to sign the zone with a set of trusted keys configured on the resolver or recursive server. The trusted key for a zone is obtained outside of the DNS protocol, e.g., via email from the zone administrator, and must be configured on each resolver or recursive server. Configuring trusted keys on recursive servers yields fewer entities requiring such configuration, and these servers can validate signatures on behalf of resolvers assuming the resolver-to-recursive server connection is secure. Once we’ve configured the trusted key for a given zone, the resolver or recursive server can compare signatures returned in DNS lookups for data in that zone and validate that the data was signed by a key that is trusted.
The Key Issue
If you think of the many different domains that you browse or link to on a daily basis, you would need a trusted key from each respective zone administrator! But DNSSEC was designed to enable validation of signatures for a given zone from its parent zone automatically to reduce this overhead. In fact, if the root (.) zone was signed, all you’d need to configure as trusted keys would be the root zone’s keys. Every signed resolution can be traced back up the domain tree as every signed parent can vouch for the signed delegation of its children, and this “chain of trust” can be validated up to the “trust anchor” which hopefully matches a trusted key. The figure below illustrates this chain of trust when resolving a host named im.without.a.net and verifying various signature records up to a trust anchor corresponding to step 5, key 19919.
For various reasons, the root zone is not signed, nor is any top level domain except .se (Sweden country zone) and .bg (Bulgaria), though the .org zone will be signed by 2010. This leaves us back at square one requiring configuration of trusted keys for every signed zone. The ISC offers a service employing what’s called DNSSEC Lookaside Validation (DLV), which enables a zone administrator to use the DLV registry as its chain of trust parent. In other words, instead of validating signatures back to the root trust anchor, e.g., verifying example.com by querying .com then the root trust anchor for signature information, I can query the DLV registry as the parent for example.com instead of .com. In this manner, resolvers and recursive servers require trusted key configuration for only the DLV keys. All domain subscribers to the DLV service can have their zone signatures validated by allowing the DLV to vouch for them.
Nevertheless, barring every signed zone administrator choosing to subscribe to the DLV service, many trusted keys would still require configuration…and maintenance. Keys, like passwords, need to be changed periodically to reduce the risk of attacker guessing. Once you’ve configured your trusted keys, they need to be updated when a zone administrator changes the key, introducing a new signature key. And given no standard way to distribute keys, different zone administrators may provide different key update notification methods such as via email or secure web portal publication.
So is DNSSEC the answer?
Technically, DNSSEC provides the best standard solution to eliminating DNS cache poisoning. Administratively, it adds a substantial burden not only to those who sign zones, in communicating key updates to those seeking signed resolution for these zones, but to those who manage resolver or recursive server configurations in maintaining up-to-date trusted keys. The ISC DLV is a clever and enterprising solution to reducing trusted key administration but it, like the intended solution of signing top level and root zones, requires participation of all Internet DNS administrators.
In the short term, the ISC patch should be applied to your BIND implementations, and remember to run Windows update for native Microsoft DNS servers which are likewise vulnerable. When implementing the patch, be aware that the number of UDP source ports used for DNS will grow, so this could impact firewall configurations. For business-critical or highly sensitive communications with clients or partners, implementing DNSSEC on some or all relevant DNS zones should be considered. You’ll have to distribute keys to these clients or partners and manage the key change or rollover process, but DNSSEC offers the benefit of secure resolution. For most standard Internet-facing DNS implementations, however, reaping the benefits of implementing DNSSEC will require wider adoption of DNSSEC-aware resolvers and recursive servers, as well as emergence of a relatively small number of authoritative trust anchors to facilitate signature validation for your zones, whether it be root zone or DLV registries.