Cybertelecom Federal Internet Law & Policy An Educational Project

DNS: Security

Derived From: Derived From: Lennard Kruger, Internet Domain Names: Background and Policy Issues, Congressional Research Service p 10 (Oct. 28, 2009)

The security and stability of the Internet has always been a preeminent goal of DNS operation and management. One issue of recent concern is an intrinsic vulnerability in the DNS which allows malicious parties to distribute false DNS information. Under this scenario, Internet users could be unknowingly redirected to fraudulent and deceptive websites established to collect passwords and sensitive account information.

A technology called DNS Security Extensions (DNSSEC) has been developed to mitigate those vulnerabilities. DNSSEC assures the validity of transmitted DNS addresses by digitally "signing" DNS data via electronic signature. "Signing the root" (deploying DNSSEC on the root zone) is a necessary first and critical step towards protecting against malicious attacks on the DNS.19 On October 9, 2009, NTIA issued a Notice of Inquiry (NOI) seeking public comment on the deployment of DNSSEC into the Internet's DNS infrastructure, including the authoritative root zone.20 On June 3, 2009, NTIA and the National Institute of Standards and Technology (NIST) announced they will work with ICANN and VeriSign to develop an interim approach for deploying DNSSEC in the root zone by the end of 2009.21

Meanwhile, section 8 of S. 773, the Cybersecurity Act of 2009, would require that any renewals or modifications made to DOC contracts regarding the operation of IANA be subject to review by a Cybersecurity Advisory Panel. S. 773 would also require NTIA to "develop a strategy to implement a secure domain name addressing system."

Derived From: NIST Special Publication (SP) 800-81, Secure Domain Name System (DNS) Deployment Guide, Exec. Sum. May 2006

Because DNS data is meant to be public, preserving the confidentiality of DNS data pertaining to publicly accessible IT resources is not a security objective. The primary security goals for DNS are data integrity and source authentication, which are needed to ensure the authenticity of domain name information and maintain the integrity of domain name information in transit. Availability of DNS services and data is also very important; DNS components are often subjected to denial of service attacks intended to disrupt access to the resources whose domain names are handled by the attacked DNS components.

DNS is susceptible to the same types of vulnerabilities (platform, software, and network-level) as any other distributed computing system. However, because it is an infrastructure system for the global Internet, it has the following special characteristics not found in many distributed computing systems:

• No well-defined system boundaries?participating entities are not subject to geographic or topologic confinement rules
• No need for data confidentiality?the data should be accessible to any entity regardless of the entity?s location or affiliation.

Because of these characteristics, conventional network-level attacks such as masquerading and message tampering, as well as violations of the integrity of the hosted and disseminated data, have a completely different set of functional impacts, as follows:

• A masquerader that spoofs the identity of a DNS node can deny access to services for the set of Internet resources for which the node provides information (i.e., domains served by the node). This denial is not only for a limited set of clients but also for the entire universe of all clients needing access to those resources.
• Bogus DNS information provided by a masquerader or intruder can poison the information cache of the DNS node providing that subset of DNS information (i.e., the name server providing Internet access service to the enterprise?s users), resulting in a denial of service to the resources serviced by it.
• Violation of the integrity of DNS information resident on its authoritative source or the information cache of an intermediary that has accumulated information from several historical queries may break the chained information retrieval process of DNS. This could result in either a denial of service for DNS name resolution function or misdirection of users to a harmful set of illegitimate resources.
• If the name resolution data hosted by the DNS system violates content requirements as defined in DNS standards, it could have adverse impacts such as increased workload on the DNS system, or serving obsolete data that could result in denial of service to Internet resources. In most software, program data independence (as in conventional database management systems [DBMS]) provides a degree of buffer against adverse impacts due to erroneous data. In the case of DNS, the data content determines the integrity of the entire system.

Based on these functional impacts, the deployment guidelines for secure DNS presented by NIST consist of the following generic and DNS-specific recommendations:

• Implement appropriate system and network security controls for securing the DNS hosting environment, such as operating system and application patching, process isolation, and network fault tolerance.
• Protect DNS transactions such as update of DNS name resolution data and data replication that involve DNS nodes within an enterprises control. The transactions should be protected using hash-based message authentication codes based on shared secrets, as outlined in the Internet Engineering Task Force's (IETF) Transaction Signature (TSIG) specification.
• Protect the ubiquitous DNS query/response transaction that could involve any DNS node in the global Internet using digital signatures based on asymmetric cryptography, as outlined in IETF's Domain Name System Security Extensions (DNSSEC) specification.
• Enforce content control of DNS name resolution data using a set of integrity constraints that are able to provide the right balance between performance and integrity of the DNS system.

(ii) Secure the Domain Name System. DNS serves as the central database that helps route information throughout the Internet. The ability to route information can be disrupted when the databases cannot be accessed or updated or when they have been corrupted. Attackers can disrupt the DNS by flooding the system with information or requests or by gaining access to the system and corrupting or destroying the information that it contains. The October 21, 2002 attacks on the core DNS root servers revealed a vulnerability of the Internet by degrading or disrupting some of the 13 root servers necessary for the DNS to function. The occurrence of this attack punctuates the urgent need for expeditious action to make such attacks more difficult and less effective. - U.S. National Strategy to Secure Cyberspace , February 2003 p. 30

DNS Redirects

DNS redirects occur when a DNS server provides a response other than the accurate IP address assigned to a domain name.

A DNS redirect can be intentional or inadvertent

A DNS redirect can be caused by the DNS domain name owner, by the owner of the DNS resolver (such as a network service provider) changing the DNS records, or by a third party.

The result of a DNS redirect can be a DOS attack where the resource is unreachable, interception and monitoring of traffic destined to an address on the internet, or theft of service redirecting traffic from the intended destination to an alternative destination (ex when a end user asks for Pizza Hut, providing the address for ACME pizza instead)

US-China Economic and Security Review Commission, Annual Report 2010 p. 242 ("Starting on March 24, 2010, when certain Internet users in the United States and Chile attempted to connect to popular social networking websites, their computers requested routine Internet Protocol information, and a Beijing-based Domain Name Server (a clone-like iteration of a Swedish root server) replied with faulty responses. As a result, these users were directed to incorrect servers, as if the users were trying to access restricted content from behind China's Great Firewall. These conditions persisted in some cases for several days before the administrators of the Swedenbased root server temporarily disabled requests to their Beijing server ''clone.'' 112 The administrators eventually brought the server instance back online, but computer researchers identified the same problem again in June.")

DNSSEC

DNS Security (DNSSEC) refers to the addition of data authentication and integrity protection to the DNS protocol. This is accomplished by the inclusion of public keys and the use of digital signatures to DNS information.

• DNSSEC
• Modifies DNS resource records and protocols; introduces public key crypto.
• Hierarchical model of trust
• Validation of responses established by an authentication cahin from a known trust anchors
• Chain can always be constructed from the root to the lower zones, assuming that the intermediary zones are validated
• Root
• Root Names Space - this is what DNSSEC would protect
• Root infrastructure

DNSSEC is designed to

• Provide Data Integrity
• Provide origin authentication
• authenticate denial of existence of record (its really not there)
• Prevent Man in the Middle Attack
• Helps deal with population from alternate roots, cache poisoning, hijacking of domain names.
• Prevent Corrupt DNS Records. (RFC 3833)

DNSSEC does not

• provide for confidentiality of data (DNS is an open public database)
• prevent DDOS

Administrative requirements for DNSSEC include

• Key generation and management
• Zone signing operations

DNSSEC implementation concerns include

• Key security
• What do you do if all keys are compromise
• Creates a single point of failure - which must therefore be guarded carefully
• Key rollover
• Keys have a temporal dependency and therefore need synchronized time
• Key management
• If the keys dont work for any particular reason, domain zones will simply vanish
• Zone walking
• Signed records are 3 to 5 times larger and require greater computational power
• Administrative Concerns
• The key question is who signs the root. DHS is concerned about this
• IGP recommends that root be signed by multiple root key operators. IGP Paper released May 17, 2007. Diffuses responsibility across multiple parties.
• Multiple signatures required in order to generate sufficient trust each time published
• Add process to a procedure that is already demanding - creating more points of failure
• Currently root zone is published twice a day every day
• Signer of the root key decides who can edit the root and who can read the zone
• Issue of liability for holding the key
• Risk to economic infrastructures
• One assumption was that IANA would sign the root. Prob: Signing the root does not appear to be within the contract between IANA/ICANN and USG.

• Economic incentive problem
• No incentive to invest in infrastructure until demand; no demand until there is an infrastructure
• Issue of alternate roots - would appear to kill alternate root initiates
• Alt Root would have to strip out ICANN root signatures and insert all of its own signatures

Currently, DNS Security is still in the experimental stage. There are currently several experimental tests of secure DNS zones. [NIST]

Trust anchor - signed areas within the DNS hierarchy without the whole hierarchy being signed. Where foo.acme is signed but .foo is not yet signed.

DNSSEC Documentation

• IETF RFC 4035, Protocol Modifications for the DNS Security Extensions (March 2005)
• IETF RFC 4034, Resource Records for the DNS Security Extensions (March 2005)
• IETF RFC 4033, DNS Security Introduction and Requirements (March 2005)
• D. Atkins, R. Austein, IETF RFC 3833, Threat Analysis of the Domain Name System (DNS) (Aug 2004) ("This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats.")
• DNS SECURITY SPECS RFC 2535-2539, 2845, 2930, 2931, 3007, 3008, 3090, 4033, 4034, 4035
• D Eastlake , IETF RFC 2535, Domain Name System Security Extensions (March 1999)
• D Eastlake , C. Kaufman, IETF RFC 2065, Domain Name System Security Extensions (Jan 1997)
• NIST DNSSEC Project website
• USG in the process of adoption.
• NIST Special Publication (SP) 800-81, Secure Domain Name System (DNS) Deployment Guide, May 2006
• DNSSEC and its Impact on DNS Performance
• DNSSEC Deployment Initiative ("The U.S. Department of Homeland Security provides support for coordination of the initiative.")
• US DHS,
• Signing the Domain Name System Root Zone: Technical Specification, Oct 31, 2006 Draft (document states "Draft - Not for Further Distribution" - but of course it is publicly available on the Net)
• Cyber Security R&D Center
• Dot ORG Registrar FAQs DNS Security Q 6
• RIPE NCC DNSSEC Policy

DNSSEC Current Drafts

• DNS Security Introduction and Requirements
• Resource Records for the DNS security Extensions
• DNS Security protocol Modifications

DNSSEC Status

• 2005 Proposed Standard
• Specs and Software exist. TLD deployment has begun.
• Sweden (.se) and Bulgarian TLDs are reportedly operational.
• .ARPA signed by IANA pursuant to IAB instruction
• RIPE's portion of in-addr.arpa is signed
• .ORG, .COM, and .NET have test beds
• Others are in progress (.AERO)
• Implementing .gov
• DNSSEC is apparently a fed procurement spec (TCP/IP, Y2K, and OSI were all fed procurement specs)
• Browser and desktop will take a while. About half of root servers are ready; they all have to be ready.

US Goverment Activity

• DHS
• COMMERCE
  • NTIA
  • Press Release : NTIA Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System For Immediate Release: October 9, 2008 WASHINGTON--Commerce's National Telecommunications and Information Administration (NTIA) today issued a Notice of Inquiry seeking public comments regarding the deployment of Domain Name and Addressing System Security Extensions (DNSSEC) into the Internet's DNS infrastructure, including the authoritative root zone.   Comments are due by November 24, 2008.  The Notice of Inquiry is available online at www.ntia.doc.gov .

    "NTIA is committed to preserving the security and stability of the DNS," Acting NTIA Administrator Meredith Attwell Baker said. "In light of existing and emerging threats to the Internet DNS, the time is ripe to consider solutions such as DNSSEC.  As we consider deploying this technology in the root zone, it is critical that we get feedback from all the interested stakeholders."

    Background

    The DNS is a critical component of the Internet infrastructure, which is used by almost every application to associate domain names with the Web addresses required to deliver information on the Internet.  The accuracy, integrity, and availability of the information supplied by the DNS are essential to the operation of any system or service that uses the Internet. 

    Over the years, a number of vulnerabilities have been identified in the DNS protocol that threaten the accuracy and integrity of the DNS data and undermine the trustworthiness of the system.  In particular, due to technical advances, vulnerabilities in the existing DNS have recently become easier to exploit.  Malicious parties may use these vulnerabilities to distribute false DNS information, and to improperly re-direct Internet users.

    DNSSEC was developed to mitigate these vulnerabilities.  Accordingly, the Department is exploring the deployment of DNSSEC at the top level of the DNS hierarchy, known as the root zone.

    NTIA is responsible for the development of the domestic and international telecommunications policy of the Executive Branch.

  • NIST
    • NIST DNSSEC Project
    • NTIA, Estimating USG IPv6 & DNSSEC External Service Deployment Status (2016), http://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov
      
• NSF
  • Deployment Incentives for Secure Internet Routing Award Date August 2010
  • Collaborative Research: CT-ISG: Mitigating Exploits of the Current Interdomain Routing Infrastructure Award Start Sept 2007
  • Rutgers Research
  • Johns Hopkins
  • Tulane
  • Stevens Institute
  • STI: Towards more Secure Inter-Domain Routing Start Date Sept 2007 Tulane University
• FCC
  • FCC CSRIC III Working Groups
  • Working Group 4 – Network Security Best Practices
  • WG4 - DNS Best Practices (pdf)
  • Working Group 5 – DNSSEC Implementation Practices for ISPs
  • WG5 – Measurement of DNSSEC Deployment (pdf)

Links

• DNS Newsletter: www.ndssec-deployment.org
• DNSSEC.net
• DNSSEC Working Group  
• DNSSEC Resource Page

Papers

• Mattaus Wander, Torben Weis, Measuring Occurrence of DNSSEC Validation("After data cleaning, we gathered 131,320 results from 98,179 distinct IP addresses, out of which 4.8% (client-side) had validation enabled")
  
• Let the Market Drive Deployment: A Strategy for Transitioning to BGP Security, Sharon Goldberg, Boston University; Phillipa Gill, University of Toronto; Michael Schapira, Princeton University, Presentation Date: June 14, 2011, 12:30 PM - 1:00 PM NANOG 52 (NSF Sponsored Research S-1017907)
• A Fundamental Look at DNSSEC, Deployment, and DNS Security Extensions by Geoff Huston
• "Using the Domain Name System for System Break-Ins" by Steve Bellovin, 1995
• A short timeline of DNSSEC by Miek Gieben
• CircleID coverage of DNSSEC and related DNS Security
• Webcast: DNSSEC Deployment: Big Steps Forward; Several Steps to Go NANOG 2004

News

• ARIN DNSSEC Changes Completed, ARIN 4/28/2011
• VeriSign Signs .com for DNSSEC, Internet News 4/4/2011
• Most US Federal Websites More than a Year Behind Meeting DNSSEC Mandate, Circleid 1/31/2011
• VeriSign Deploys DNS Security Extensions in .net Zone, Verisign 12/10/2010
• DNS Security Rollout Begins, COMCAST 10/19/2010
• Integrating DNSSEC Into Applications, COMCAST 10/12/2010
• Secure Domain Name System (DNS) Deployment Guide, NIST 9/17/2010
• DNSSEC Updates, COMCAST 9/13/2010
• A Major Internet Milestone: DNSSEC and SSL, Freedom to Tinker 8/2/2010
• White House on the DNSSEC Deployment: "A Major Milestone on Internet Security", Circleid 7/28/2010
• DNSSEC Happy Talk Enters a New Era, Circleid 7/21/2010
• DNSSEC - A Review, Potaroo 7/7/2010
• DNSSEC Deployment Among ISPs: The Why, How, and What, Circleid 7/7/2010
• DNS security reaches 'key' milestone, CW 6/17/2010
• Today Marks a Giant Step Towards DNSSEC Deployment, Circleid 6/17/2010
• Preventing DNS Strain When You Deploy DNSSEC, Circleid 6/9/2010
• ICANN Announces First DNSSEC Key Ceremony for the Root Zone, Circleid 6/9/2010
• NTIA: Notice of Intent to Proceed with the Final Stages of DNSSEC Implementation in the Authoritative Root Zone, NTIA 6/9/2010
• Updated DNSSEC KSK Rollover Information, ARIN 6/1/2010
• More Stepping Stones Before This Summer's Seminal DNSSEC Events, Circleid 5/17/2010
• Again, DNSSEC Updates Shouldn't Impact You - Minor problems could surface, mostly within business networks, dslreports 4/30/2010
• No, DNSSEC Upgrades Won't Break The Internet Next Week - DNSSEC could ''kill your Internet' proclaims Register. Not so much, says expert., dslreports 4/30/2010
• DNSSEC Status Report: Signing Infrastructure Well Underway, User Experience Still Needs Work, Circleid 4/21/2010
• Comcast Tests DNS Security Upgrade - ISP says DNSSEC won't be compatible with DNS redirection..., dslreports 2/25/2010
• DNSSEC, Comcast 2/25/2010
• DNS Resolvers and DNSSEC: Roll Over and Die?, Circleid 2/16/2010
• DNSSEC requirement for new gTLDs raises concern outside US, IGP 1/5/2010
• Update on Last Night's DNS Disruption, TWITTER 12/22/2009
• VeriSign Announces DNSSEC Deployment Support Plans to Enhance Internet Security, Verisign 11/17/2009
• .EDU to Implement DNSSEC by the End of March 2010, CircleID 9/8/2009
• How Many Domains Are Secured by DNSSEC?, Internet News 8/27/2009
• ARIN Deploys DNSSEC Zone Signing, ARIN 7/2/2009
• NTIA and NIST Announce DNSSEC Initiative, NTIA 6/5/2009
• Another Attack, Another Reason for the Urgency of DNSSEC Adoption, CircleID 5/5/2009
• Crypto-politics creeps into DNSSEC, IGP 4/7/2009
• VeriSign: .Com, .Net to Adopt DNSSEC by 2011, CircleID 2/26/2009
• DNSSEC, Incentives and the Color of Bicycle Sheds, IGP 12/5/2008
• Proposal To Sign the Root Zone Made Public, ICANN 10/10/2008
• NTIA Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System`, NTIA 10/10/2008
• VeriSign's plan to sign the root, IGP 9/30/2008
• U.S. Government Begins Largest Deployment of DNSSEC, CircleID 9/25/2008
• Possible First Attacks on DNS Flaw Have Been Reported, CircleID 7/28/2008
• NeuStar Confirms 'Significant' Denial of Service Attack On UltraDNS, CircleID 4/2/2009
• Network Solutions Under Large Scale DDoS Attack, Millions of Websites Potentially Unreachable, CircleID 1/27/2009
• Safer Net Surfing Is Goal of NIST Domain Name Security Experts, NIST 3/12/2009
• U.S. Government Misses DNSSEC Deployment Deadline, CircleID 2/12/2009
• Geoff Huston on Securing the Internet Routing System, CircleID 1/21/2009
• Feds Urged to deploy DNSSEC and Signing of the Root Zone, CircleID 11/25/2008
• U.S. Government Begins Largest Deployment of DNSSEC, CircleID 9/25/2008
• Possible First Attacks on DNS Flaw Have Been Reported, CircleID 7/28/2008
• DNS exploit code is in the wild, CNET 7/24/2008
• DNS Flaw Is A Serious Security Threat, Techdirt 7/24/2008
• NAT/PAT Affects DNS Cache Poisoning Mitigation, US Cert 7/24/2008
• DNS Cache Poisoning Public Exploit Code Available, US Cert 7/24/2008
• Will a Global TAR make DNSSEC stick?, IGP 6/13/2008
• Securing the Root, Renesys 6/3/2008
• DNSSEC Adds Value?, CircleID 5/28/2008
• .ORG pushes forward with DNSSEC, IGP 4/29/2008
• Top-Level Domains .arpa, .org, and .uk Adopting DNSSEC, CircleID 4/29/2008
• Response to Patrik Faltstrom on DNSSEC implications, IGP 9/18/2007
• Businesses Losing Battle Against DNS Attack, Says New Study, CircleID 7/18/2007
• The Case Against DNSSEC, CircleID 8/15/2007
• IANA's DNSSEC testbed signs root zone, IGP 7/27/2007
• IETF DNS Working Group defines DNS as "critical infrastructure", IGP 7/10/2007
• Is the time RIPE for a signed DNS root?, IGP 6/19/2007
• IGP Releases New Paper on DNSSEC and Securing the Root, IGP 5/18/2007
• DHS publicly acknowledges DNSSEC root signing spec, IGP 4/18/2007
• Uncle Sam Wants DNS 'Master Key', Broadband Reports 4/3/2007
• Securing the Root: Introduction, IGP 4/3/2007
• UN agency: Internet name system under threat, ZDNet 3/14/2007
• Report: Government Domains Safe-Unless It's Romania, eweek 3/14/2007
• Commercial DNSSEC?, CircleID 2/23/2007
• Hackers overwhelm some key Internet traffic computers, Silicon 2/9/2007
• VeriSign Tackles Growing Internet Security Threats, Internet News 2/9/2007
• Hackers overwhelm some key Internet traffic computers, Globe and Mail 2/9/2007
• A Fundamental Look at DNSSEC, Deployment, and DNS Security Extensions, CircleID 8/11/2006
• DNS Servers: the Internet's Achilles Heal, ITU 8/5/2005
• UK WHOIS service suspended after rogue attack, Register 1/27/03

• Rumsfeld Orders .mil Web Lockdown, SecurityFocus 1/17/03
• DNS Root Servers: Protecting the Internet, Network Mag 1/7/03

• Nameserver DoS Attack October 2002, CAIDA 2/14/03

• ICANN Warns Firms Of Backdoors, Newsbytes 2/13/02

• ICANN Appoints Security Chief, Newsbytes 2/13/02

• ICANN: To Serve And Protect, Wired 11/13/01

• ICANN Scraps conference agenda, goes big on security, Register 11/7/01

• ICANN Volunteers for Homeland Defence, Register 10/1/01

• ICANN to focus on Web Security, CNEWS 9/28/01

• ICANN To Review Security of the Internet, IWeek 9/28/01

• Internet overseer to focus on routing system's security at next meeting, Nando 9/28/01