Federal Internet Law & Policy
An Educational Project
DNS: Security Dont be a FOOL; The Law is Not DIY
- Security
- Encryption

Internet Addresses
- History
- NTIA & Fed Activity
- Root Servers
- ccTLDs
- - .us
- -
- gTLDs
- - .gov
- - .edu
- - .mil
- - .xxx
- IP Numbers
- - IPv6
- NATs
- Ports
- Security
- Trademark
- AntiCybersquatter Consumer Protection Act
- Gripe Sites
- Truth in Domain Names
Telephone Addresses

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 GuidePDF, 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:

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:

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

(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.")


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 is designed to

DNSSEC does not

Administrative requirements for DNSSEC include

DNSSEC implementation concerns include

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

DNSSEC Deployment Status
RIPE NCC Zone by Zone as requested
dot ORG Testbed
Verisign dot net  

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

DNSSEC Current Drafts


US Goverment Activity




© Cybertelecom ::