Another reason you should implement DNSSEC now

Researchers from the University of California and Tsinghua University in China have published discovery of a new form of DNS cache poisoning attack. This form of attack leverages "side channels" through use of the Internet Control Message Protocol (ICMP) to improve the likelihood of attack success by identifying the subset of source UDP ports actually used by a recursive server when issuing queries. Confining this pool of randomized ports helps reduce the universe of port numbers the attacker can try when attempting to emulate a proper query response. 

Source port and DNS transaction identifier randomization has been the recommended mitigation approaches against cache poisoning attacks, even for more nefarious Kaminsky-discovered attacks. However, this use of side channels reduces the robustness of source port randomization mitigation. Of course, DNS security extensions (DNSSEC) remains the only definitive means to mitigate cache poisoning attacks, including this new variant. 

But let's start at the beginning: DNS resolvers, forwarders and recursive servers (generally "resolvers") maintain a cache of resolved resource records to improve name resolution performance by obviating repeated lookups for information recently queried. If an attacker succeeds in corrupting a resolver's cache, the corrupted information may be provided to several users requesting the same or similar domain name information. Corrupting the cache requires an attacker to provide a seemingly legitimate query answer albeit with falsified resolution information in part or in total.

These types of attacks are generally conducted as shown in the figure below where an attacker appears to the recursive server as the legitimate authoritative server to which it issued the query. In the various forms of this attack, ultimately the attacker attempts to corrupt the cache of the recursive DNS server, e.g., by pointing the resolution of a legitimate and even popular web or server address to a server operated by the attacker. The falsified resolution data is returned to the originator of the query and is also returned to other resolvers querying for this information while the corrupted information resides in cache, i.e., for the duration of the TTL. This has the effect of hijacking potentially several resolvers and hence applications to incorrect destinations, e.g., web sites.

To corrupt the cache, the DNS query response from the attacker must reach the server before the legitimate response and map to an outstanding query for which the recursive server is awaiting a response. The server will map a received answer to a previously issued query by matching the following fields in the response:

• The source IP address of the response maps to the destination IP address of the query and the destination IP address matches the address of this server.
• The destination port of the response with the source port of the query and the answer’s source port is 53.
• The DNS transaction ID within the DNS header matches on both the query and the response
• The DNS Qname, Qclass and Qtype in the question section matches on both the query and the response.
• The domain names in the Authority and Additional sections of the response must fall within the same domain branch as the Qname. This is known as the bailiwick check.

The DNS server will accept the first matching answer it receives, cache it and respond to the querying user. If the attacker can match the parameters with an answer that arrives before the legitimate answer from the authoritative name server, he or she will have succeeded in poisoning the cache with an answer that will be provided to other clients querying similar information. As mentioned in the opening, this side channel attack helps reduce the span of candidate UDP ports used by the resolver, and therefore reduces the number of unique parameter combinations an attacker must use to guess correctly.

You can turn off ICMP, reduce query timeouts, even use qname case checking, but the only definitive solution to this attack is DNSSEC. When responses are signed and the resolver validates the signature using the DNSSEC chain of trust, the resolver is assured that the response was published by the authoritative zone operator and that the response was not modified en route. And these days, implementing DNSSEC validation is really easy. In fact, most commercial distributions of DNS recursive servers support DNSSEC validation out of the box. This includes provision of the root zone public key and support for automated detection and updating of changed root keys. Such automation provides virtually hands-free implementation and ongoing maintenance of DNSSEC validation. 

Of course, your recursive servers can only validate DNSSEC-signed resolution data, and herein lies the rub. Unfortunately, while 85% of US government zones are signed, only 7% of university zones and about 4% of industry zones are signed according to NIST estimates. Thus, the majority of non-US government zones remains unsigned as of today. In terms of DNSSEC validating resolvers, APNIC measurements indicate about 25% of DNS resolvers support DNSSEC validation. 

While signing zones is more complicated than validating signatures, at least in terms of implementation and management, the process has gotten a lot easier for most leading implementations. Many implementations support automated key generation and rollover but often some manual intervention is required, especially when rolling key signing keys (KSKs). Even fully automated authoritative signing servers including BT's require some effort to link the chain of trust, though support of CDS and CDNSKEY records by both parent and child can help automate this process as well. 

To learn more about this attack, what defenses you can deploy, how DNSSEC can help and even how BT's solutions can help ease implementation, please contact me via email or comment.