Here is a paper I wrote for the University of Dallas.
DNS Overview
DNS is the familiar term used for Domain Name Service. In teaching DNS to students, this following analogy is often used in my training. DNS is like a phone book. Every name in the phone book has a phone number associated with it. In DNS, every host and associated domain name called a fully qualified domain name (FQDN) has an unique IP address associated with it. Prior to DNS, system on the network that used TCP/IP used host files, which is basically a text file list of every computer on the network and the associated IP address. After some time, managing host files and maintaining systems on the network became too cumbersome, the DNS daemon was developed for the UNIX based systems that dominated computing networks. The concept was very simple; a client would make an iterative query to the DNS server using UDP port 53. Keep in mind that UDP stands for User Datagram Protocol, which is a connectionless protocol. If the DNS server had the domain and host (A) record configured on its system, it would reply to the DNS query with the DNS response containing the IP address for the FQDN. If the DNS server did not have the domain on its server, it would then make a recursive query to the Root DNS servers, and then to the domain designator (e.g. .com, .net, .eu) and then finally to the domain being requested. The DNS server, having done all of that for the client, will then return the DNS response to the client to complete the iterative query and it stores a copy of it in its cache for a time-to-live (TTL) period. Using the UDP protocol made this a very fast transaction when the record was found. This is a distinct advantage over the TCP protocol because of the overhead.
DNS Security
An old saying is that the Internet was safe until someone mentioned security. The DNS Service and protocol were never designed to be secure. The philosophy behind the design was ease of use and open sharing. “The problem is with the DNS protocol; it's insecure.” (Schneier, 2008) Most DNS threats were to man in the middle attacks, spoofing the IP address of the DNS server, doing full zone transfers to unauthorized servers and DNS cache poisoning. It wasn’t until 2008 that a significant warning was issued as Dan Kaminsky published a vulnerability method which led to US-CERT Vulnerability Note VU#800113 (Department of Homelaand Security, 2008). This vulnerability showed how the DNS cache could be targeted and poisoned with a predictable attack method. What happens is that an attacker can corrupt the cache on the DNS server so it will direct users to illegitimate sites used in a new type of phishing scam. For example, if the cache gets polluted for www.woodlawnbank.com, any client making a DNS query for this site will be redirected to the illegitimate site where information could be stolen.
The solution is to follow the DNSSEC RFC recommendations for securing DNS through the use of Public Key Interchange (PKI) usage to verify the origin of the record. The concept is that there is a hierarchy of trusted systems (Wijngaards, 2009). RFC 4033 (http://www.ietf.org/rfc/rfc4033.txt), RFC 4034 (http://www.ietf.org/rfc/rfc4034.txt) and RFC 4035 (http://www.ietf.org/rfc/rfc4035.txt) are now available to be implemented in BIND 9 and Microsoft Windows Server 2008 R2 DNS 64-bit versions. The only current client operating system that takes advantage of DNSSEC natively is Microsoft Windows 7 but others need slight modifications to enable this feature.
Implications to E-Commerce
E-commerce systems must perform a cost/benefit analysis on whether the expenses for implementing the upgrade to Windows 2008 R2 DNS or BIND 9 along with the additional operational costs. Whether using Windows or an open source solution, both iterations have the requirement to run on a 64-bit operating system and current DNS deployments are more commonly run on older 32-bit operating systems requiring newer hardware systems with more memory and faster processors to handle the required overhead. The hardware cost is probably the biggest upfront and in today’s economic situation, companies are reluctant to make this move.
Another consideration is that increased amount of traffic generated by additional packets used in the queries. There is also the need for the more CPU processing power on both the client and server systems and on networking devices due to the increased traffic considerations. Translating this to layman terminology, people will feel that the sites that are utilizing secure DNS will come up slower compared to those that use legacy DNS systems. This consideration would be the public perception of the secure DNS system and whether they are willing to wait the additional time vs. moving on to another site perceived to be faster.
The most probable consideration would be the cost of not implementing a secure DNS solution and facing the consequences of traffic destined to their site getting hijacked and redirected to a phishing site. DNSSEC "sounds like a good idea, but it's hard for me to assess the likelihood of this threat," says Michael Saltzman, vice president of network operations at gig.com, an online music distribution service. "In the pantheon of threats, viruses and more direct packet attacks rate a higher frequency. Those are the ones we worry about more." (Marsan, 2000)
Bibliography
Department of Homelaand Security. (2008, 7 8). US-CERT. Retrieved October 23, 2009, from United States Computer Emergency Readiness Team: http://www.kb.cert.org/vuls/id/800113
Marsan, C. D. (2000, October 16). DNS security upgrade promises a safer 'Net. Retrieved October 23, 2009, from NetworkWorld.com: http://www.networkworld.com/news/2000/1016dnsec.html
Schneier, B. (2008, July 29). The problem is with the DNS protocol; it's insecure. Retrieved October 23, 2009, from Schneier on Security: The problem is with the DNS protocol; it's insecure.
Wijngaards, W. C. (2009). Securing DNS: Extending DNS Servers with a DNSSEC Validator. IEEE Security & Privacy (Sept.-Oct), 36 - 43 .
No comments:
Post a Comment