Attacks on the Dynamic Name Service (DNS) have been less widespread than attacks on other components of the Internet....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
For this reason only recently has there been a real drive toward implementing protocol extensions to protect DNS. This initiative, known as DNS Security Extensions (DNSSEC), protects against falsification of domain name to address mappings.
A quick overview of DNS: DNS resolves domain names to Internet addresses by accessing a series of name servers. The DNS resolver on your PC is configured at startup to direct queries to your corporate name server or your ISP's name server. If you request a name unknown to the local name server, it in turn queries other name servers in order to satisfy your request.
For example, if you request a name such as "www.xyz.com" and your local name server has no information about xyz.com, it will query the name server that maintains all .com information. Then, it will query the name server in the xyz.com domain for the address of www.xyz.com. If an attacker can intercept your query anywhere along this path, it can respond with false information. A DNS client that receives a false address in response to a query can be directed to a Website that masquerades as a legitimate site. A false bank site could collect confidential information such as usernames and passwords.
Since all of these queries are done using UDP, it isn't even necessary for the attacker to block the request from going to its legitimate destination. The attacker simply responds more quickly than the legitimate server. The requester will accept its reply and ignore the legitimate reply that follows. For more detail on the types of threats against DNS, see RFC 3833 Threat Analysis of the Domain Name System (DNS).
An attacker does not need to intercept a query to the site under attack, but instead can use a "cache poisoning" attack. Here, the attacker responds with legitimate information to a request, but appends to the response an additional name to address mapping. The additional information is not acted upon immediately, but remains in the cache of the requester. For example, an attacker responds to a request from an ISP's name server for information on xyz.com, provides an accurate address for xyz.com but also appends a false name to address mapping for yourbank.com. All of the ISP's customers who request the address of yourbank.com will receive fallacious information.
DNSSEC guarantees the validity of DNS information using digital signatures and public key encryption. Name servers that support DNSSEC digitally sign each name to address mapping that they maintain. Resolvers and name servers that query for information use the supplying name server's public key to verify the signature and the data.
To address the challenge of distributing public keys in a secure manner, a "chain of trust" is used. This technique prevents attackers from intercepting keys and supplying their own bogus keys. This is more practical than maintaining a single registry for all of the millions of domains on the Internet.
The root name servers maintained by the Internet community supply name to address mapping for the top level domains such as .com and .org. Currently, resolvers are configured with the well known addresses for these root name servers. With DNSSEC, resolvers are also configured with the public keys of the root name servers which digitally sign the name to address mappings for the top level domains. A resolver can then safely access the public key of the top level domain. This key, in turn, will be used to sign the name to address mapping of domains directly below the top level. The chain can continue as far as necessary.
Performance is always an issue with encryption. Name servers sign mappings just once, at the time they are stored, so there is no delay each time a mapping is requested. Further, it isn't necessary to decrypt the entire contents of the mapping. The supplying name server supplies a hash of the information and encrypts the hash; the resolver recomputes the hash, decrypts the hash supplied and compares the two. If they are identical, the data came from the valid source was not altered along the way. For more details on DNSSEC, see http://www.dnssec.net/.
While test deployments of DNSSEC have encountered operational problems, updated RFCs submitted last fall are due to be released soon. The Department of Homeland Security is encouraging deployment, and an informal group is working on deployment issues. See www.dnssec-deployment.org.
DNSSEC deployment will begin with a few isolated domains. As additional experience is gained, it will spread across the web. To add DNSSEC to your corporate name server, you will need to update your DNS software to support it. The public domain BIND software has supported DNSSEC through much of its evolution. You will need to create a private key and maintain it in a secure place.
Adding DNSSEC to your network will mean additional work, but will be well worthwhile if your site is one that may attract attackers.
David B. Jacobs has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software start-ups.