11:12 PM
Quick Hits
Quick Hits
Quick Hits
Connect Directly
Repost This

Keeping DNS Services Safe And Operational

Domain Name System technology is critical to your Internet communications. Here are some tips for keeping your DNS services -- and your data -- secure

[Excerpted from "Keeping DNS Services Safe and Operational," a new report published this week on Dark Reading's Security Services Tech Center.]

It's really easy to take a critical network service like Domain Name System, better known as DNS, for granted. After all, in most organizations, DNS usually works without a hitch and requires little day-to-day maintenance. Unfortunately, when DNS problems do surface, an entire business can be brought to a screeching halt.

Before Microsoft Active Directory forced DNS into a more prominent role in our data centers, the fallout from DNS issues often was confined to an inability to browse the Internet or use externally hosted Web applications. Back then, losing Internet access for a few hours wouldn't have been a huge deal for most enterprises. Today, when DNS goes down or is compromised, a whole host of other services and internal applications can be brought down with it--and that is a huge deal for any enterprise.

DNS isn't one of those network services that you can simply lock down and call it a day--for the Internet to function, DNS needs to be broadly available and it needs to be fast. While the inventors of DNS did not specifically cite packet overhead and speed as a concern in their original design, the selection of UDP as a transport to send and receive DNS queries was a great one because it helps ensure that the millions of queries per second being sent to certain DNS resolvers can be handled efficiently. However, the connectionless nature of DNS makes it easier for attackers to affect the reliability and availability of DNS itself.

What makes DNS defense complicated is that every organization must rely on upstream DNS resolvers and authoritative name servers to provide name services. The distributed, hierarchical nature of DNS means that we all need to rely on resolvers and name servers that are not under our control. In addition, while it seems simple on the surface or when only a fraction of its services are used, DNS is very complex. Indeed, there's a reason very large organizations have very smart people dedicated to managing DNS.

With all that said, the DNS attacks you're likely to see can be broadly categorized in two buckets: attacks on the integrity of your DNS database in the form of various DNS record hacks, and attacks on the availability of your DNS server in the form of a denial-of-service (DoS) attack.

To get a list of the types of DNS attacks your organization may encounter -- and some recommendations on what you can do about them -- download the free report on managing DNS services.

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

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Current Issue
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web