Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

4/24/2008
09:30 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Securing the Internet's DNS

Internet's .arpa, .org, and .uk domains soon to adopt DNSSEC

The Internet is slowly inching closer to ratcheting up the security of its Domain Name System (DNS) server architecture: The Internet Corporation for Assigned Names and Numbers (ICANN ) plans to go operational with the secure DNS technology, DNSSEC, later this year in one of its domains.

ICANN officials said the organization plans to add DNSSEC to its .arpa Internet domain servers, and that the .org domain servers (run by PIR) as well as the .uk servers also will go DNSSEC soon. Country domains .swe (Sweden), .br (Brazil), and .bg (Bulgaria ) already run the secure version of DNS for their domain servers.

DNSSEC, which stands for DNS Security Extensions, digitally signs DNS records so that DNS responses are validated as legitimate and not hacked or tampered with. That ensures users don’t get sent to phishing sites, for example, when requesting a legitimate Website. DNS security increasingly has become a concern, with DNS prone to these so-called cache poisoning attacks, as well as distributed denial-of-service (DDOS) attacks like the one last year that temporarily crippled two of the Internet's 13 DNS root servers. (See DNS Attack: Only a Warning Shot?, DNS Attack: Possible Botnet Sales Pitch , and DNS Servers in Harm's Way.)

But DNSSEC adoption has been slow in coming, mainly due the complexity of managing the keys. Converting .arpa -- a domain mostly relegated to Internet research sites -- to DNSSEC isn’t quite the same as securing .com, but it could signal that DNSSEC is finally ready for prime time, experts say. Still, DNSSEC isn't completely useful unless all domains have deployed it.

ICANN says its latest DNSSEC move doesn’t signal an all-out move to DNSSEC, but it's a start. “Every time another top-level domain signs on, that’s progress,” says Richard Lamb, an engineer with ICANN who helped build its DNSSEC testbed. “Whether it means the DNS root servers [will go DNSSEC] in the near future, I don’t know.”

David Piscitello, a member of ICANN’s Security and Stability Advisory Committee, says he considers the latest wave of DNSSEC adoption plans a “glass half-full.”

“Some might point to the fact that we are still ‘ticking off zones’ as they implement DNSSEC indicates there’s little support. DNSSEC isn’t the kind of extension you willy-nilly toss into a critical infrastructure without considerable effort, and much of that effort is not visible or newsworthy,” Piscitello says. “Arpa and Org may be strong indicators that the community is building confidence in DNSSEC protocols; name server implementations with DNSSEC are proving themselves in production environments; and people are spending time deploying DNSSEC for the security measures it provides instead of complaining about the threats it does not mitigate.”

DNSSEC digitally signs DNS records but doesn’t encrypt DNS traffic. And it’s not all there is to securing DNS. Piscitello points out that securing the Net’s DNS infrastructure also requires building it out to better repel DDOS attacks. That means “increasing the capacity, resiliency, and diversity of location of the root name servers to make the DNS more resistant to denial-of-service attacks,” he says.

Other measures include getting rid of “open resolvers,” which often get abused by phishers and other e-criminals, he says, and hardening DNS server and resolver software, as well as adding more real-time monitoring to these servers to detect attack attempts sooner.

Meanwhile, ICANN is working on its DNSSEC testbed to prepare for future DNSSEC adoption. “We are coming up with a system we can deploy. This testbed puts us in a position to be ready if we’re asked by all the right people to assign [DNSSEC] to the root zone as well,” ICANN’s Lamb says. “We’re looking at this testbed to eventually sign arpa” and other domains.

ICANN recently selected and purchased AEP Networks Inc. 's Keyper hardware security modules for generating and storing the keys for the DNSSEC testbed. “The private key is never visible” because it’s all done in the box, Lamb says. And ICANN has been writing DNSSEC code for the DNS servers that it’s put in the public domain.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
44% of Security Threats Start in the Cloud
Kelly Sheridan, Staff Editor, Dark Reading,  2/19/2020
Zero-Factor Authentication: Owning Our Data
Nick Selby, Chief Security Officer at Paxos Trust Company,  2/19/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9405
PUBLISHED: 2020-02-26
IBL Online Weather before 4.3.5a allows unauthenticated reflected XSS via the redirect page.
CVE-2020-9406
PUBLISHED: 2020-02-26
IBL Online Weather before 4.3.5a allows unauthenticated eval injection via the queryBCP method of the Auxiliary Service.
CVE-2020-9407
PUBLISHED: 2020-02-26
IBL Online Weather before 4.3.5a allows attackers to obtain sensitive information by reading the IWEBSERVICE_JSONRPC_COOKIE cookie.
CVE-2020-9398
PUBLISHED: 2020-02-25
ISPConfig before 3.1.15p3, when the undocumented reverse_proxy_panel_allowed=sites option is manually enabled, allows SQL Injection.
CVE-2015-5201
PUBLISHED: 2020-02-25
VDSM and libvirt in Red Hat Enterprise Virtualization Hypervisor (aka RHEV-H) 7-7.x before 7-7.2-20151119.0 and 6-6.x before 6-6.7-20151117.0 as packaged in Red Hat Enterprise Virtualization before 3.5.6 when VSDM is run with -spice disable-ticketing and a VM is suspended and then restored, allows r...