ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    This discussion has been archived. No new comments can be posted.
    ICANN Misses Critical MoU Deadline - But Offers Vaporware as a Substitute | Log in/Create an Account | Top | 22 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Vinton Cerf, ICANN and the ISOC Facing Their Fate
    by Anonymous on Saturday October 02 2004, @04:45AM (#14260)
    What happens if 10 million software developers,
    armed with Linux workstations and broadband
    wireless access point routers (running Linux),
    which they can program down to the last bit
    in any protocol...collectively decide to ignore
    ICANN and the .NET "rebid" ?

    What happens if Verisign encourages those
    developers, by giving them FREE .NET names, and
    by continuing to operate the .NET registry and
    servers ?

    What happens if those 10 million developers also
    get large FREE blocks of IP address space without
    paying an RIR or ICANN ? Why would people pay
    someone to be their regulator when they created
    the resource ?

    Do you think Vinton Cerf, ICANN and the ISOC will
    be able to convince the U.S. Government and the
    Secret Service to have all 10 million of those
    people "publicly flogged" (as Cerf suggests) ?

    Do you think the U.S. Department of Homeland
    Security has a clue what 10 million developers
    can produce, without their permission ?

    Given at a Communications Hearing:
    ICANN Oversight and Security of Internet Root Servers and the Domain Name System (DNS)
    Thursday, September 30 2004 - 2:30 PM - SR - 253
    The Testimony of
    Mr Pat Morrissey
    Security Director, Law Enforcement Intelligence / U.S. Secret Service / U.S. Department of Homeland Security

    Good afternoon, Chairman Burns, Ranking Member Hollings, and distinguished Members of the Subcommittee. My name is Patrick Morrissey, I am the Deputy Director of Law Enforcement and Intelligence with the United States Secret Service. I am pleased to have an opportunity to appear before the committee to discuss the security of the Internet’s Domain Name System (DNS), associated DNS root servers, Top Level Domains, and related DNS support infrastructure.

    At the most basic level all Internet communication begins with addressing and naming - identifying who should communicate and what objects are relevant. The DNS infrastructure is very closely tied to the fundamental health and stability of the Internet. As many of you are aware, without DNS services, vast portions of the Internet itself become inaccessible for almost all applications. This is a particularly heightened concern as the United States and other nations around the world are increasingly dependent on a functioning Internet for fundamental business activities, and homeland and national security activities.

    Domain Name System

    DNS security is a highly complex topic fraught with many technical nuances. At their very essence, domain name services translate commonly used domain names such as www.dhs.gov to a machine addressable Internet Protocol (IP) Address. So, for example, when a computer user types a web page into a browser, DNS services translate that name to a numeric IP address and direct the web browser application to the corresponding server, which, if there are no problems, responds to the browser’s request. This process of mapping of a domain name to a numerical IP address is called “name resolution.”

    While the concept are fundamental and fairly easy to conceptualize, the distributed architecture of the Internet results in a complex series of practices and protocols that work together to provide great autonomy and control to network and domain name operators. These practices and protocols are necessary to preserve a highly functional and interoperable Internet. Because of this distributed architecture domain name queries often traverse multiple branches of a DNS “tree” to resolve the address for a requested system name. Using our previous example, when a user types www.dhs.gov, the computer first contacts the server to determine the IP address of dhs.gov. The system is hierarchical so that the root servers themselves do not have to handle the entirety of all global DNS resolutions. There are other ways that the resolution can occur as well. But, this is the most fundamental method.

    As you can appreciate, the modern Internet supports millions of registered domains (according to Verisign as of Q2 2004) and allows each domain name owner to define how their domain responds to Internet queries for email delivery, web services, file transfers, telnet and other Internet applications. For complex enterprise networks, various branches of an organization’s DNS are often managed by different systems administrators and service providers, and many times are located in separate geographic areas. . This allows for greater flexibility and autonomy for the infrastructure, but results in increased complexity and possibility for compromise.

    While there is no doubt that the number of registered domain names has increased dramatically over the past 10 years, there has also been a dramatic increase in the number of Internet users and associated domain name queries performed and responded to by the DNS infrastructure.

    The Internet’s DNS infrastructure handles billions of translations transactions each day, as well as keeping millions of IP addresses up to date. In practice, DNS forms one of the largest and most active distributed databases in the world, and without it, the Internet very quickly becomes generally unusable for many purposes and applications.

    Some challenges to the successful delivery of DNS services include denial of service and distributed denial of service attacks, DNS poisoning, misconfiguration, and spoofing. DNS servers, and the software controlling those servers, are attractive targets to attackers. Imagine a scenario where a user types an e-commerce website into a browser and a different web site appears instead. Or worse yet, this different web site which looks very similar to the authentic site, appears where a user could be fooled into entering personal information, credit card information and more. Other ways that attackers target the DNS include denial of service attacks to overload DNS servers, or exploiting vulnerabilities to compromise corporate networks. In addition, viruses can also shut down DNS services by using thousands of infected machines to search the network for new victims often overloading those name servers.

    The State of DNS and Root Server Security

    Over the years, DNS has been the subject of many high profile attacks. For example, in 2001 it was widely reported that attackers disabled nine of 13 root servers. Contrary to popular belief, only one root name server failed during those attacks, and it only failed for a short time over a 45 minute period. The "“nine of 13 failed" statement was specious, and based on” widely reported at that time simply was an inaccurate monitoring. statement.

    Since that time, as with other key components of the Internet, meaningful investments have been made by root server operators and others, and significant progress is occurring to improve the resiliency of the network on which the Internet relies. Denial of service attacks are generally considered to be among the most likely and potentially dangerous threats to the DNS infrastructure. The highly distributed and robust global DNS architecture mitigates the risk of denial of service attacks but increased capacity is believed to be the most practical protection against denial of service attacks.

    Better system design, investments in high performance systems, configuration management, and the implementation of anycast protocols have also increased our national and global capacity to handle many attack scenarios. The development and deployment of anycast has allowed for the replication of the 13 root servers; there are dozens. Having a larger number of high performance systems function as the so that there are multiple instances of those servers. The ability to replicate those root servers allows for faster response times, greater load distribution and diversity, and greater overall infrastructure survivability.

    The discovery of bugs or vulnerabilities in implementations of DNS, such as Internet Systems Consortium-Berkley Internet Name Domain (ISC-BIND), is an infrequent but potentially serious occurrence. Investments within the root and top-level domain servers have resulted in reasonable diversity in DNS software. This reduces the likelihood that a single software vulnerability that is discovered will affect the entire infrastructure. There has been a series of proprietary and commercially available implementations of DNS. While these implementations have not benefited from the extensive peer review that ISC-BIND has, many of them show significant advantages in ease of management and performance characteristics for both discarding invalid inquires as well as processing valid requests. Again, since an effective defense for denial of service attacks is to design significant excess capacity, DNS performance is important.

    Generally speaking, the owners and operators of the root servers, global top level domains and country code top level domains are doing a good job of managing and protecting the DNS critical infrastructure. These owner/operators have taken, and continue to take, the security of DNS very seriously, covering, not only the cyber aspects, but also, physical security, operational network challenges and corresponding policies and procedures. There exists a good diversity of deployment and software in DNS today. The operators monitor DNS and coordinate the community’s response in the event of anomalous activity.

    Many of the case scenarios where large scale outages might occur in the DNS root infrastructure typically require a combination of factors which are very unlikely to occur, given the level of professionalism in the management of today’s infrastructure and investment in capacity and diversity. However, to coordinate response to a cyber emergency of national significance the National Cyber Security Division established the National Cyber Response Coordination Group (NCRCG) formerly the Interagency Incident Management Group (C-IIMG). NCRCG is a forum of 13 principle agencies to coordinate intra-governmental and public-private preparedness and operations to respond to, and recover from national level cyber incidents and physical attacks that have significant cyber consequences. The group brings together officials from national security, law enforcement, defense, intelligence, and other government agencies that maintain significant cyber security responsibilities and capabilities. In the event of an incident, NCRCG can provide a strategic picture of the impact to the information infrastructure and a coordinated response, due to its close association with others in private industry, academia, and international and local governments. The senior level membership of NCRCG helps ensure that during a significant national incident, the full range and weight of federal capabilities will be deployed in a coordinated and effective fashion. The interagency group meets monthly, has established communication protocols and coordination activities, and has conducted a tabletop exercise to identify gaps in performance.

    DNS is one of the largest and most active distributed databases in the world, and the distributed nature of DNS is essential to its performance. By distributing the physical location of the server, as well as the kinds of organizations responsible for managing and protecting those servers, DNS in its entirety is not susceptible to simple failure scenarios.

    Non-systemic, but problematic DNS issues

    While the professional management and resiliency of the DNS infrastructures have made great progress, serious issues still exist. Technical surveys of corporate DNS implementations show that 62 percent of DNS implementations are flawed or vulnerable. These practices unnecessarily expose corporations, business partners and clients a wide variety of bad scenarios ranging from information disclosure to full network compromise. There are a number of best practices that have developed to secure the DNS. Common practice includes limiting Zone transfers, avoiding recursive queries, patching, and using obfuscated naming conventions. In fact, several best practices and guides have emerged from a variety of industry and academic sources on topics such as:

    · Securing an Internet name server · A secure BIND configuration and topology to help defend against BIND attacks · Running an authoritative-only BINF name server · Installing and configuring a DNS server in Windows 2000 · How to install and configure a DNS server in Windows 2003 · Primary and secondary DNS server configuration for ISPs · The importance of separating DNS caches from DNS servers

    For your reference, a list of websites to these guides is included in the appendix to my written statement.

    The Future

    The demands on DNS are only going to continue to grow. Mandates for e-government, and incentives for online payment and commerce only constitute the very beginnings of our reliance on some form of DNS; RFID, anti-spam, and other applications will soon call greater attention to the importance of DNS.

    In the future users must be able to have a degree of confidence in the naming on the Internet. DNS was originally developed when the Internet was a trusted environment that didn’t anticipate on the need for authentication as the Internet evolved. New security extensions and other DNS enhancements have been proposed that would allow DNS infrastructure to have a method of verifying the integrity of record being served, in addition to verifying the actual identity of servers claiming to be authoritative DNS servers. A second feature of these enhancements would allow DNS to be used as a central distribution method for public-keys, establishing the DNS system as the global architecture for security information distribution as well as addresses and names. All of these additional enhancements to the DNS system are currently being evaluated by various standards bodies and task forces for implementation. Most notably, the directorate of Science and Technology within DHS is actively developing programs aimed at accelerating development and deployment of DNS security into the Internet infrastructure.

    Conclusion

    The DNS system is an essential subsystem of the global Internet. The highly redundant and distributed architecture of DNS makes it extremely robust and generally resilient. However, as threats and exploits become increasingly complex, the DNS system will continue to be attacked in new and different ways. It is everyone’s responsibility to ensure that the DNS system is as modern and robust as possible. The Department of Homeland Security, through the National Cyber Security Division is committed to working with private sector, government, and international organizations, providers, and individual companies to continue to support increased resiliency of the DNS system. Thank you for the opportunity to testify before you today. I would be pleased to answer any questions you have at this time. Appendix

    Securing an Internet name server http://www.cert.org/archive/pdf/dns.pdf A secure BIND configuration and topology to help defend against BIND attacks: http://www.cymru.com/Documents/secure-bind-templat e.html Running an authoritative-Only BIND name server http://www.isc.org/pubs/tn/?tn=isc-tn-2002-2.html Installing and configuring a DNS server in Windows 2000 http://techrepublic.com.com/5100-6268-1033115.html How to install and configure a DNS Server in Windows Server 2003 http://support.microsoft.com/default.aspx?scid=kb; EN-US;814591 Primary and secondary DNS server configuration for ISPs http://www.microsoft.com/serviceproviders/whitepap ers/isp_dns_config.asp

    The importance of separating DNS caches from DNS servers http://cr.yp.to/djbdns/separation.html
    [ Reply to This | Parent ]


    Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com