DOCSLIB.ORG

DNS Consistency Model

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
DNS Consistency Model DNS Consistency Model Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science (by Research) in Computer Science by Manish Kumar Sharma 200502011 [email protected] Center for Security, Theory & Algorithmic Research (CSTAR) International Institute of Information Technology Hyderabad - 500 032, INDIA April 2012 Copyright c Manish Kumar Sharma, April 2012 All Rights Reserved International Institute of Information Technology Hyderabad, India CERTIFICATE It is certified that the work contained in this thesis, titled “DNS Consistency Model” by Manish Kumar Sharma, has been carried out under my supervision and is not submitted elsewhere for a degree. Date Adviser: Dr. Bruhadeshwar Bezawada The only place where success comes before work is in the dictionary. - Donald Kendall To my loving parents and grandparents. Acknowledgments First of all, I would like to thank Dr. Bruhadeshwar Bezawada for his constant support and able guidance for the past three years. I gratefully acknowledge Dr. Bruhadeshwar for introducing me to the field of DNS security. I would like to thank my parents for constantly supporting me throughout my highs and lows. As a child, I was like a lump of clay. My parents and teachers moulded and shaped me into a beautiful pot and Dr. Bruhadeshwar crafted designs on the pot to enhance its beauty. In other words, my parents with their initial guidance helped me to reach a stage from where I could easily comprehend the teachings of my teachers and finally Dr. Bruhadeshwar guided me through the path to success. I would also like to thank my siblings and friends without whose motivation I could not have traveled such a long distance. I would like to thank Basant Sharma who helped me in solving my doubts. I would like to thank my sister late Vedika Saraswat who through her success inspired me and helped me in my studies. At the end, I would like to thank my college-mates and the dearest friends - ”Mohit Goyal, Hemant Dhingra, Nitin Jain, Subroto Sen, Yogesh Nautiyal, Abhishek Sainani and many others” who were there with me throughout my college life and are like a family to me. vi Abstract Domain Name System(DNS) is an inevitable component of the critical infrastructure of the Internet. It is a hierarchical distributed database system which provides a crucial service for the internet i.e. the mapping of human-friendly domain names to their respective machine-friendly IP addresses and vice versa. Almost all internet-based applications including http, ftp and email, need to resolve a given domain name to its respective IP address prior to establishing connections. DNS provides the mapping service which is fundamental not only to the health of the Internet but also to the protection and integrity of the data. In case, mapping of a domain name to an IP address in the system gets corrupted, the system would no longer be acceptable. Being probably the most valuable infrastructure in the Internet, its security is of utmost priority. The domain names in a DNS database are stored in the form a hierarchical tree structure which is known as domain name space. Each node in the tree contains zero or more resource records which hold information associated with a domain name. DNS cache these resource records for a specific time period, i.e., TTL (Time-To-Live). TTL too plays an important role in maintaining the consistency of the cached resource records. Short TTL reduces the likelihood of getting old information but increases the DNS utilization whereas long TTL decreases the DNS utilization but at the same time increases the chance of retrieving outdated information. DNS was not earlier designed to save itself against different kinds of attacks such as cache poisoning, rebinding attacks etc. This is the reason that DNS servers have been manipulated by attackers to launch phishing attacks, to commit click-frauds and to drive traffic to malicious websites. Among all the different kinds of attacks on DNS, DNS cache poisoning is the prominent one. DNS cache poisoning refers to the cases where the cache of a DNS server gets corrupted due to the injection of false mapping in the server which affects the accuracy of DNS lookups. Consequently, when queries arrive at the DNS server, inaccurate and probably malicious replies are sent as the response. False mapping can be injected into a DNS in many ways i.e. by dns spoofing, dns forgery etc. After one poisoned record is injected into the cache, it can spread to other parts of the cache or other servers through query/response between servers. DNS cache poisoning could be used by an attacker to redirect the querier to a non-existent IP address, thus causing Denial-of Service or the querier can be redirected to a malicious website which drops Malware/Spyware or s/he could even be redirected to attacker’s website, causing phishing attack. Till date, many different solutions have been proposed to overcome the problem of cache poisoning but none has been deployed successfully. Certain proposed solutions like DNSSEC, DNSCurve etc, found vii viii to be efficient against cache poisoning but they have not been successfully deployed primarily because of the complexity involved in key management. Certain other solutions were neglected because either they required changes in the DNS protocol or they introduced considerable latency in the system making them an undesirable solution. Hence, in spite of all the solutions proposed till date to mitigate cache poisoning attacks, the problem still persists. To mitigate cache poisoning attacks, we have proposed an approach - Domain Consistency Management system (DCMS) which makes the use of response delays for a specific resource-record type between a DNS client and a DNS server. Our approach is similar to stimulus-response model in which a response is expected for a specific stimulus within a specific period of time. If the response is received out of the period then it could be the result of some flaw in the system. Similarly in our approach we expect the response of a DNS query for a specific resource-record type to be received within a certain period of time. In case the DNS response is received out of period we suspect an attack on the system and perform a check to ensure the consistency of the response received. The significant feature of our approach lies in its self-learning that in parallel it updates its database of response delays for a specific resource- record type between specific DNS client and DNS server, thereby helping the system not only in proper functioning, even it enhances its performance. DCMS makes cache poisoning attacks, almost infeasible, even for motivated and powerful attackers. The biggest advantage of our approach is that it does not require any change in the DNS protocol, hence it could be deployed on a large scale within a short period of time. It does not even require any changes at the server side as in WSEC-DNS to ensure the consistency of the responses. Since it does not involve any cryptography technique, hence any sort of key management is not required. Even our approach does not introduce any significant amount of latency to the system. After the introduction of IPv6, other approaches may require certain changes but DCMS needs not to be reconfigured. Hence, our approach, Domain Consistency Management System (DCMS), proves to be effective and efficient against cache poisoning attacks. Contents Chapter Page 1 Introduction .......................................... 1 1.1 DomainNameSystem .................................. 1 1.2 Background....................................... 1 1.3 Overview ......................................... 2 1.4 Domain Name Resolution . 3 1.5 DNSMessagePacket ................................. 4 1.5.1 Identification . 4 1.5.2 Flags ....................................... 5 1.5.3 NumberofQuestions............................... 7 1.5.4 NumberofAnswerRRs ............................. 8 1.5.5 Number of Authority RRs . 8 1.5.6 Number of Additional RRs . 8 1.5.7 Questions..................................... 8 1.5.8 AnswerResourceRecords . 8 1.5.9 Authority Resource Records . 9 1.5.10 Additional Resource Records . 9 1.6 ResourceRecordTypes.............................. 10 1.7 NegativeCaching.................................... 10 1.8 ReverseDNSlookup .................................. 10 2 Problem Statement ....................................... 12 2.1 DNSCachePoisoning .................................. 12 2.1.1 DNSSpoofingAttack .............................. 13 2.1.2 DNSForgeryAttack ............................... 14 2.1.3 Kaminsky-class attack . 15 2.2 DNS Redirection Attack . 16 2.3 DNS Rebinding Attack . 17 3 Related Work ......................................... 19 4 Our Approach & Results .................................... 23 4.1 OurApproach...................................... 23 4.1.1 Query Type and Response Type . 24 4.1.2 Query....................................... 27 4.1.3 TransactionID .................................. 27 ix x CONTENTS 4.1.4 ResponseDelay.................................. 27 4.2 Probabilistic proof of our approach . ..... 34 4.3 Optimum Value of Median Response Deviation . 35 4.4 Algorithmic Complexity . 35 4.5 Results........................................... 36 5 Analysis of TTL-based Caching in DNS ............................ 38 5.1 Analysis of DNS response packets & associated TTL values. ........ 38 6 Conclusion & Future Work ................................... 44 Bibliography ............................................ 47 List
Load more

Recommended publications
  • A Letter to the FCC [PDF]
    Before the FEDERAL COMMUNICATIONS COMMISSION Washington, DC 20554 In the Matter of ) ) Amendment of Part 0, 1, 2, 15 and 18 of the ) ET Docket No. 15­170 Commission’s Rules regarding Authorization ) Of Radio frequency Equipment ) ) Request for the Allowance of Optional ) RM­11673 Electronic Labeling for Wireless Devices ) Summary The rules laid out in ET Docket No. 15­170 should not go into effect as written. They would cause more harm than good and risk a significant overreach of the Commission’s authority. Specifically, the rules would limit the ability to upgrade or replace firmware in commercial, off­the­shelf home or small­business routers. This would damage the compliance, security, reliability and functionality of home and business networks. It would also restrict innovation and research into new networking technologies. We present an alternate proposal that better meets the goals of the FCC, not only ensuring the desired operation of the RF portion of a Wi­Fi router within the mandated parameters, but also assisting in the FCC’s broader goals of increasing consumer choice, fostering competition, protecting infrastructure, and increasing resiliency to communication disruptions. If the Commission does not intend to prohibit the upgrade or replacement of firmware in Wi­Fi ​ ​ devices, the undersigned would welcome a clear statement of that intent. Introduction We recommend the FCC pursue an alternative path to ensuring Radio Frequency (RF) compliance from Wi­Fi equipment. We understand there are significant concerns regarding existing users of the Wi­Fi ​ spectrum, and a desire to avoid uncontrolled change. However, we most strenuously advise against prohibiting changes to firmware of devices containing radio components, and furthermore advise against allowing non­updatable devices into the field.
    [Show full text]
  • Site Finder and Internet Governance
    345 Site Finder and Internet Governance Jonathan Weinberg* 347 INTRODUCTION 348 PART 1. 354 PART 2. 361 PART 3. 366 PART 4. 375 CONCLUSION Copyright © 2004 by Jonathan Weinberg. * Professor of Law, Wayne State University. I am grateful to Michael Froomkin, Mark Lemley, David Maher, Milton Mueller, and Jessica Litman for their comments, and to Susan Crawford and Bret Fausett for answer- ing questions along the way. None of them, of course, is responsible for anything I say here. This essay reflects developments taking place through 30 November 2003. 347 Site Finder and Internet Governance Jonathan Weinberg INTRODUCTION ON SEPTEMBER 15, 2003, VeriSign, Inc.—the company that operates the data- bases that allow internet users to reach any internet resource ending in “.com” or “.net”—introduced a new service it called Site Finder. Less than three weeks later, after widespread protest from the technical community, at least three law- suits, and a stern demand from ICANN (the Internet Corporation for Assigned Names and Numbers, which has undertaken responsibility for managing the internet domain name space), VeriSign agreed to shut Site Finder down.1 In between those dates the internet community saw a passionate debate over the roles of ICANN, VeriSign, and the internet’s technical aristocracy in managing the domain name space. VeriSign has charged that its opponents’ reactions were the product of “obsolete thinking” that would disable it from “build[ing] a commercial busi- ness.”2 ICANN, for its part, is seeking to enact a procedure under which top-level domain name registry operators such as VeriSign must seek ICANN’s approval before offering new services or taking any “significant actions that...could affect the operational stability, reliability, security or global interoperability of...the Internet.”3 Some see fault on all sides: “It’s hard to say,” writes one commenta- tor, “in this case who is being more anti-competitive, ICANN or VeriSign.”4 In this essay, I will try to unpack the Site Finder story.
    [Show full text]
  • To the Members of the Senate Judiciary Committee: We, The
    To the members of the Senate Judiciary Committee: We, the undersigned, have played various parts in building a network called the Internet. We wrote and debugged the software; we defined the standards and protocols that talk over that network. Many of us invented parts of it. We're just a little proud of the social and economic benefits that our project, the Internet, has brought with it. We are writing to oppose the Committee's proposed new Internet censorship and copyright bill. If enacted, this legislation will risk fragmenting the Internet's global domain name system (DNS ), create an environment of tremendous fear and uncertainty for technological innovation, and seriously harm the credibility of the United States in its role as a steward of key Internet infrastructure. In exchange for this, the bill will introduce censorship that will simultaneously be circumvented by deliberate infringers while hampering innocent parties' ability to communicate. All censorship schemes impact speech beyond the category they were intended to restrict, but this bill will be particularly egregious in that regard because it causes entire domains to vanish from the Web, not just infringing pages or files. Worse, an incredible range of useful, law-abiding sites can be blacklisted under this bill. These problems will be enough to ensure that alternative name-lookup infrastructures will come into widespread use, outside the control of US service providers but easily used by American citizens. Errors and divergences will appear between these new services and the current global DNS, and contradictory addresses will confuse browsers and frustrate the people using them.
    [Show full text]
  • IDN-OSS Project
    IDN-OSS Project ICANN 2004 Cape Town – IDN Workshop 1st December 2004 William Tan NeuLevel Consultant IDN and NeuLevel • NeuLevel has recognized the need for application plug-ins to realize the benefit of IDN work by any registry – Web browsers, email clients, IM, etc. • Need for a project to implement plug-ins that is – Open source, external to NeuLevel – Community controlled and developed – Standards compliant, not registry-specific 2 Chartering IDN-OSS • NeuLevel collaboration with James Seng to begin IDN-OSS – Conceived at ICANN Montreal – Discussion between Richard Tindal and James Seng • James Seng wrote business plan, kick-started the project. • Advisory Council: Vint Cerf, Mark Davis, Martin Dürst, John Klensin, and Paul Hoffman • Project is hosted by Internet Systems Consortium 3 IDN Open Source Software Project • Goals – Develop open source, standards-compliant software to enable IDN functionality in applications – Target web browser initially – Internet Explorer – Provides a bridge until IDN functionality is native to applications • Timeline – Summer 2003: Project begins – Fall 2003: ISC begins hosting project – Spring 2004: First IE plug-in released – Summer 2004: Internal code improvements 4 IDN-OSS Products • IDNTool • Performs IDNA ToASCII and ToUnicode operations. • Useful for developers, domain administrators, etc. • Uses JPNIC idnkit library internally • Plug-in for Internet Explorer • Allows users to navigate using IDN URLs – by typing into address bar or clicking on links. • New name: echIDNA • Uses JPNIC idnkit library
    [Show full text]
  • List of NMAP Scripts Use with the Nmap –Script Option
    List of NMAP Scripts Use with the nmap –script option Retrieves information from a listening acarsd daemon. Acarsd decodes ACARS (Aircraft Communication Addressing and Reporting System) data in real time. The information retrieved acarsd-info by this script includes the daemon version, API version, administrator e-mail address and listening frequency. Shows extra information about IPv6 addresses, such as address-info embedded MAC or IPv4 addresses when available. Performs password guessing against Apple Filing Protocol afp-brute (AFP). Attempts to get useful information about files from AFP afp-ls volumes. The output is intended to resemble the output of ls. Detects the Mac OS X AFP directory traversal vulnerability, afp-path-vuln CVE-2010-0533. Shows AFP server information. This information includes the server's hostname, IPv4 and IPv6 addresses, and hardware type afp-serverinfo (for example Macmini or MacBookPro). Shows AFP shares and ACLs. afp-showmount Retrieves the authentication scheme and realm of an AJP service ajp-auth (Apache JServ Protocol) that requires authentication. Performs brute force passwords auditing against the Apache JServ protocol. The Apache JServ Protocol is commonly used by ajp-brute web servers to communicate with back-end Java application server containers. Performs a HEAD or GET request against either the root directory or any optional directory of an Apache JServ Protocol ajp-headers server and returns the server response headers. Discovers which options are supported by the AJP (Apache JServ Protocol) server by sending an OPTIONS request and lists ajp-methods potentially risky methods. ajp-request Requests a URI over the Apache JServ Protocol and displays the result (or stores it in a file).
    [Show full text]
  • July 18, 2012 Chairman Julius Genachowski Federal Communications Commission 445 12Th Street SW Washington, DC 20554 Re
    July 18, 2012 Chairman Julius Genachowski Federal Communications Commission 445 12th Street SW Washington, DC 20554 Re: Letter, CG Docket No. 09-158, CC Docket No. 98-170, WC Docket No. 04-36 Dear Chairman Genachowski, Open data and an independent, transparent measurement framework must be the cornerstones of any scientifically credible broadband Internet access measurement program. The undersigned members of the academic and research communities therefore respectfully ask the Commission to remain committed to the principles of openness and transparency and to allow the scientific process to serve as the foundation of the broadband measurement program. Measuring network performance is complex. Even among those of us who focus on this topic as our life’s work, there are disagreements. The scientific process happens best in the sunlight and that can only happen when as many eyes as possible are able to look at a shared set of data, work to replicate results, and assess its meaning and impact. This ensures the conclusions from the broadband measurement allow for meaningful, data-driven policy making. Since the inception of the broadband measurement program, those of us who work on Internet research have lauded its precedent-setting commitment to open-data and transparency. Many of us have engaged with this program, advising on network transparency and measurement methodology and using the openly-released raw data as a part of our research. However, we understand that some participants in the program have proposed significant changes that would transform an open measurement process into a closed one. Specifically, that the Federal Communications Commission (FCC) is considering a proposal to replace the Measurement Lab server infrastructure with closed infrastructure, run by the participating Internet service providers (ISPs) whose own speeds are being measured.
    [Show full text]
  • Domain Name System 1 Domain Name System
    Domain Name System 1 Domain Name System The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. A Domain Name Service translates queries for domain names (which are easier to understand and utilize when accessing the internet) into IP addresses for the purpose of locating computer services and devices worldwide. An often-used analogy to explain the Domain Name System is that it serves as the phone book for the Internet by translating human-friendly computer hostnames into IP addresses. For example, the domain name www.example.com translates to the addresses 192.0.43.10 (IPv4) and 2620:0:2d0:200::10 (IPv6). The Domain Name System makes it possible to assign domain names to groups of Internet resources and users in a meaningful way, independent of each entity's physical location. Because of this, World Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). Users take advantage of this when they recite meaningful Uniform Resource Locators (URLs) and e-mail addresses without having to know how the computer actually locates them. The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain.
    [Show full text]
  • IP Geolocation Through Reverse DNS
    IP Geolocation through Reverse DNS Ovidiu Dan∗ Vaibhav Parikh Brian D. Davison Lehigh University Microsoft Bing Lehigh University Bethlehem, PA, USA Redmond, WA, USA Bethlehem, PA, USA [email protected] [email protected] [email protected] ABSTRACT Table 1: Example of entries from an IP Geolocation database IP Geolocation databases are widely used in online services to map end user IP addresses to their geographical locations. However, they StartIP EndIP Country Region City use proprietary geolocation methods and in some cases they have 1.0.16.0 1.0.16.255 JP Tokyo Tokyo 124.228.150.0 124.228.150.255 CN Hunan Hengyang poor accuracy. We propose a systematic approach to use publicly 131.107.147.0 131.107.147.255 US Washington Redmond accessible reverse DNS hostnames for geolocating IP addresses. Our method is designed to be combined with other geolocation data sources. We cast the task as a machine learning problem where increased user satisfaction and conversely that missing location for a given hostname, we generate and rank a list of potential information leads to user dissatisfaction [2, 7, 25]. IP geolocation location candidates. We evaluate our approach against three state databases are also used in many other applications, including: con- of the art academic baselines and two state of the art commercial tent personalization and online advertising to serve content IP geolocation databases. We show that our work significantly local to the user [2, 18, 26], content delivery networks to direct outperforms the academic baselines, and is complementary and users to the closest datacenter [19], law enforcement to fight cy- competitive with commercial databases.
    [Show full text]
  • Topic 5. Network Naming Translation Service: ISC DNS
    Computer System Design and Administration Topic 5. Network naming translation service: ISC DNS José Ángel Herrero Velasco Department of Computer and Electrical Engineering This work is published under a License: Creative Commons BY-NC-SA 4.0 Computer System Design and Administration Topic 5. Network naming translation service: ISC DNS Secure information service: Puzzle Information server LDAP clients Active Directory client Open Open LDAP LDAP LDAP DB SSL SSL service SSL Main SSH server ISC ISC ISC Third-party service DHCP DNS NTP services client Secondary Open LDAP DB service SSH client LDAP SSL SSL Replicated José Ángel Herrero Velasco Computer System Design and Administration Topic 5. Network naming translation service: ISC DNS Target: …server convergence • Installaon, configuraon and deployment of third-party network services for local networking management on the INTRANET: – Dynamic configuraon service (DHCP): ISC dhcpd. – Domain name service (DNS): ISC bind9: • Network naming transla2on: – IP domain name. – …and more. – Network 'me service (NTP): ISC ntpd. José Ángel Herrero Velasco Computer System Design and Administration Topic 5. Network naming translation service: ISC DNS DNS: Internet domain name service • There are 2 key systems (pieces) on the Internet: – Domain naming system (DNS). – Internet roung system (Rou'ng). • Usually both systems are NOT greatly considered in network environments: – We assume that others “above” are in charge ISPs. • However, they are two crical aspects for our subnet (network): – The subnet might become inoperave because of link cuts: • Hosts won’t be able to use DNS. – We won't even be able to use a simple network service such as ssh or “browse” on web if router failures happen.
    [Show full text]
  • (12) United States Patent (10) Patent No.: US 8.443,106 B2 Shuster (45) Date of Patent: May 14, 2013
    USOO8443106B2 (12) United States Patent (10) Patent No.: US 8.443,106 B2 Shuster (45) Date of Patent: May 14, 2013 (54) CONTENT RESTRICTION COMPLIANCE 2002/0087726 A1* 7/2002 Macpherson et al. ........ 709/245 USING REVERSE DNS LOOKUP 3.99. A 333 Bugal.OS 3. 2005/0038702 A1 2/2005 Merriman et al. .............. TO5/14 (76) Inventor: Gary Stephen Shuster, Fresno, CA 2005/0050222 A1 3, 2005 Packer (US) 2005/0102407 A1 5/2005 Clapper 2005.0114794 A1 5/2005 Grimes et al. (*) Notice: Subject to any disclaimer, the term of this 2005/0177844 A1* 8, 2005 Levi et al. ....................... 725/30 2006/0173793 A1 8/2006 Glass .............................. 705/75 patent is extended or adjusted under 35 38885 A. $39. S.al f U.S.C. 154(b) by 564 days. 2006/0224689 A1 * 10/2006 Leip et al. ..................... 709/217 2006/0248.190 A1* 11/2006 Gardos et al. .. 709,225 (21) Appl. No.: 12/339,763 2006/0259.778 A1* 11/2006 Gudorf et al. ................. T13, 186 2007/0204040 A1 8, 2007 COX (22) Filed: Dec. 19, 2008 2007/0260603 A1* 11/2007 Tuscano et al. ................... 707/9 2008/0059310 A1 3/2008 Lettow et al. ................... TO5/14 (65) Prior PublicationO O Data 2008.011486256888. AA1* 1568.5/2008 MoghaddamNE et al. ........ 713,155709.220 US 2009/O164597 A1 Jun. 25, 2009 OTHER PUBLICATIONS Related U.S. Application Data The American Heritage Dictionary of the English Language, defini tion of demographics, 2000.* (60) Provisional application No. 61/016,440, filed on Dec. 21, 2007. (Continued) (51) Int.
    [Show full text]
  • DNS and the DNS Cache Poisoning Attack
    Lecture 17: DNS and the DNS Cache Poisoning Attack Lecture Notes on “Computer and Network Security” by Avi Kak ([email protected]) June 25, 2021 3:21pm ©2021 Avinash Kak, Purdue University Goals: The Domain Name System BIND Configuring BIND Running BIND on your Ubuntu laptop Light-Weight Nameservers (and how to install them) DNS Cache Poisoning Attack Writing Perl and Python code for cache poisoning attacks Dan Kaminsky’s More Virulent DNS Cache Poisoning Attack CONTENTS Section Title Page 17.1 Internet, Harry Potter, and the Magic of DNS 3 17.2 DNS 5 17.3 An Example That Illustrates Extensive DNS 13 Lookups in Even the Simplest Client-Server Interactions 17.4 The Domain Name System and The dig Utility 28 17.5 host, nslookup, and whois Utilities for Name 42 Lookup 17.6 Creating a New Zone and Zone Transfers 45 17.7 DNS Cache 48 17.7.1 The TTL Time Interval 51 17.8 BIND 56 17.8.1 Configuring BIND 58 17.8.2 An Example of the named.conf Configuration File 64 17.8.3 Running BIND on Your Ubuntu Laptop 68 17.9 What Does it Mean to Run a Process in a 70 chroot Jail? 17.10 Phishing versus Pharming 73 17.11 DNS Cache Poisoning 74 17.12 Writing Perl and Python Code for Mounting a 81 DNS Cache Poisoning Attack 17.13 Dan Kaminsky’s More Virulent Exploit for 92 DNS Cache Poisoning 17.14 Homework Problems 99 Computer and Network Security by Avi Kak Lecture 17 Back to TOC 17.1 INTERNET, HARRY POTTER, AND THE MAGIC OF DNS If you have read Harry Potter, you are certainly familiar with the use of owl mail by the wizards and the witches.
    [Show full text]
  • Jonathan Zittrain's “The Future of the Internet: and How to Stop
    The Future of the Internet and How to Stop It The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters Citation Jonathan L. Zittrain, The Future of the Internet -- And How to Stop It (Yale University Press & Penguin UK 2008). Published Version http://futureoftheinternet.org/ Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:4455262 Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA YD8852.i-x 1/20/09 1:59 PM Page i The Future of the Internet— And How to Stop It YD8852.i-x 1/20/09 1:59 PM Page ii YD8852.i-x 1/20/09 1:59 PM Page iii The Future of the Internet And How to Stop It Jonathan Zittrain With a New Foreword by Lawrence Lessig and a New Preface by the Author Yale University Press New Haven & London YD8852.i-x 1/20/09 1:59 PM Page iv A Caravan book. For more information, visit www.caravanbooks.org. The cover was designed by Ivo van der Ent, based on his winning entry of an open competition at www.worth1000.com. Copyright © 2008 by Jonathan Zittrain. All rights reserved. Preface to the Paperback Edition copyright © Jonathan Zittrain 2008. Subject to the exception immediately following, this book may not be reproduced, in whole or in part, including illustrations, in any form (beyond that copying permitted by Sections 107 and 108 of the U.S.
    [Show full text]