Protect Your DNS Cache Without Signing a Zone....But be a Good "Netizen"
While DNSSEC technology has been specified for over a decade (though the standard was revamped about six years ago), it gained little true interest until mid-2008. With the announcement of the so-called Kaminsky vulnerability in July, 2008, momentum for DNSSEC began building and is accelerating into this year. Here's a great article describing this vulnerability in detail. The vulnerability can lead to cache poisoning of a name server performing lookups on behalf of DNS clients or stub resolvers.
This name server, commonly referred to as a recursive name server, accepts recursive queries from resolver clients, and issues successive queries down the domain tree to locate the source of the queried information. Once received, the answer is cached so should another resolver request the same information, the recursive name server simply returns the cached resolution data, saving time and reducing needless resolution traffic. Thus recursive servers are also referred to as caching names servers.
By forcing the recursive name server to perform a lookup such that malicious data is stored in its cache, an attacker may direct clients requesting legitimate and popular websites to a fraudulent site. Consider some popular websites and how many of your users access them during the day and it's easy to see how quickly this defrauded cached data can spread. And given the Kaminsky vulnerability, which is a DNS protocol vulnerability, not that of a particular DNS vendor, makes this cache poisoning attack easier, how should you protect your cache? While the patches that many vendors supplied coincident with and soon after the vulnerability announcement helped mitigate the vulnerability, the only surefire solution is the use of DNSSEC.
If zone administrators managing name resolution for these popular websites sign their zone data with DNSSEC, and your recursive servers can be configured to "trust" them, then any fraudulent response will be identifiable and therefore prevented from entering the name server cache. To protect your recursive server caches, you must configure this trust information (trust anchors) such that signed resolutions can be deemed trustworthy or not. Both of the most popular enterprise DNS server reference implementations, namely from the Internet Systems Consortium (ISC) and Microsoft Corporation support the declaration of one or more trust anchors within recursive server configurations.
And with the root zone being signed and most major top level domains (TLDs) being signed or soon to be signed, the root zone trust anchor is all that needs to be configured. Just as name resolution works from the root zone down to the authoritative zone, trust anchor validation works up to the root zone in a chain of trust.
So while the first part of the headline of this post states that you can protect your own caches in this manner by configuring trust anchor(s) and querying other servers' signed information, the second part encourages you to consider signing your own publicly reachable zone data as well. This assures that would-be attackers will be unable to impersonate your zone information for secure resolutions, maintaining your DNS information integrity. It also supports Internet "civility" which has become a hot term in public circles but has been a true hallmark of Internet designers and implementers ("netizens") from the beginnings of the Internet. Let's keep it that way!
This name server, commonly referred to as a recursive name server, accepts recursive queries from resolver clients, and issues successive queries down the domain tree to locate the source of the queried information. Once received, the answer is cached so should another resolver request the same information, the recursive name server simply returns the cached resolution data, saving time and reducing needless resolution traffic. Thus recursive servers are also referred to as caching names servers.
By forcing the recursive name server to perform a lookup such that malicious data is stored in its cache, an attacker may direct clients requesting legitimate and popular websites to a fraudulent site. Consider some popular websites and how many of your users access them during the day and it's easy to see how quickly this defrauded cached data can spread. And given the Kaminsky vulnerability, which is a DNS protocol vulnerability, not that of a particular DNS vendor, makes this cache poisoning attack easier, how should you protect your cache? While the patches that many vendors supplied coincident with and soon after the vulnerability announcement helped mitigate the vulnerability, the only surefire solution is the use of DNSSEC.
If zone administrators managing name resolution for these popular websites sign their zone data with DNSSEC, and your recursive servers can be configured to "trust" them, then any fraudulent response will be identifiable and therefore prevented from entering the name server cache. To protect your recursive server caches, you must configure this trust information (trust anchors) such that signed resolutions can be deemed trustworthy or not. Both of the most popular enterprise DNS server reference implementations, namely from the Internet Systems Consortium (ISC) and Microsoft Corporation support the declaration of one or more trust anchors within recursive server configurations.
And with the root zone being signed and most major top level domains (TLDs) being signed or soon to be signed, the root zone trust anchor is all that needs to be configured. Just as name resolution works from the root zone down to the authoritative zone, trust anchor validation works up to the root zone in a chain of trust.
So while the first part of the headline of this post states that you can protect your own caches in this manner by configuring trust anchor(s) and querying other servers' signed information, the second part encourages you to consider signing your own publicly reachable zone data as well. This assures that would-be attackers will be unable to impersonate your zone information for secure resolutions, maintaining your DNS information integrity. It also supports Internet "civility" which has become a hot term in public circles but has been a true hallmark of Internet designers and implementers ("netizens") from the beginnings of the Internet. Let's keep it that way!
Comments
Post a Comment