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
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-4095
PUBLISHED: 2019-12-10
IBM Cloud Pak System 2.3 is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts. IBM X-Force ID: 158015.
CVE-2019-4244
PUBLISHED: 2019-12-10
IBM SmartCloud Analytics 1.3.1 through 1.3.5 could allow a remote attacker to gain unauthorized information and unrestricted control over Zookeeper installations due to missing authentication. IBM X-Force ID: 159518.
CVE-2019-4521
PUBLISHED: 2019-12-10
Platform System Manager in IBM Cloud Pak System 2.3 is potentially vulnerable to CVS Injection. A remote attacker could execute arbitrary commands on the system, caused by improper validation of csv file contents. IBM X-Force ID: 165179.
CVE-2019-4663
PUBLISHED: 2019-12-10
IBM WebSphere Application Server - Liberty is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 171245...
CVE-2019-19251
PUBLISHED: 2019-12-10
The Last.fm desktop app (Last.fm Scrobbler) through 2.1.39 on macOS makes HTTP requests that include an API key without the use of SSL/TLS. Although there is an Enable SSL option, it is disabled by default, and cleartext requests are made as soon as the app starts.