[dns-operations] ignorant hit-piece about dns in an online security rag this week

Paul Vixie paul at vix.com
Wed Feb 14 18:05:54 UTC 2007

(this reminds me, in its tone, of a headline i saw inside a comic book
back in 1975 or so: "SPIDER MAN: THREAT OR MENACE?" ... but i'm not
laughing. --paul)


>From CSOonline.com

DNS: Definitely Not Safe?

New attacks on the Internet’s domain name system keep CISOs guessing. Here’s
what you can do about it.

By Erik Sherman 
Internet Security

When it comes to the Web's domain name system (DNS), many otherwise vigilant
CSOs heed the adage of leaving well enough alone. It's understandable, as DNS
has for years reliably allowed people to use domain names (such as
www.csoonline.com) with their Web browsers rather than having to remember
remarkably non-mnemonic IP addresses (such as 

Unfortunately, for all its success, DNS is one area in which what you don't
know can hurt you%Gβ€”%@badly. Despite well-publicized attacks on
domain name servers in 2000 and 2001, evidence suggests that many companies
simply have not taken the steps necessary to protect this vital part of their
networks. Experts differ on just how much danger companies generally
face. However, they seem to agree that, depending on the circumstances and the
company, the results could include electronic attacks and unknowingly
providing confidential information to competitors. Some companies aren't just
leaving the back door unlocked%Gβ€”%@they're taking out the hinge
pins and removing the door entirely.

"There is a lack of appreciation of just how damned vulnerable DNS is," says
Lloyd Hession, CSO for BT Radianz. Indeed, the U.S. Department of Homeland
Security's Computer Emergency Readiness Team (CERT) has recently reported a
rise in distributed denial-of-service (DDoS) attacks using DNS. No matter how
safe DNS may seem, companies need to stay alert. Here's a quick roundup of DNS
vulnerabilities and attack methods CISOs should understand.

Open to Misuse

What makes DNS such a vulnerable part of the Internet is the range of exploits
it makes possible. DDoS attacks are the best known because they were the basis
of some prominent attacks a few years ago. DNS servers can be the targets of
these attacks, but%Gβ€”%@and this is less widely
known%Gβ€”%@hackers can use DNS servers to perpetrate a DDoS attack
on a third party, essentially amplifying the volume of data hitting the target
system by upwards of 4,000 percent. 

On one hand, says Marty Lindner, senior member of the technical staff at the
Carnegie-Mellon University CERT/CC, DDoS can be executed by bombarding a DNS
server to block real traffic from getting in and effectively keeping those
users off the Internet. Perpetrators can also flip the tactic, creating
spoofed requests to a DNS server that supports recursion. Recursion is the
method by which a name server hunts down the IP address of an unfamiliar
domain name by working down trees of name servers that provide authoritative
information on given parts of the Internet. The original name server receives
one packet of information after another that each provide the equivalent of
directions to reach the destination, and passes them all on to the
requester. When the initial request is spoofed with the address of the
hacker's target, all that data goes whistling back to the target. "It doesn't
take more than 10 or 20 name servers to mount a denial-of-service attack
against another target," says Cricket Liu, vice president of architecture at
network appliance vendor Infoblox and coauthor of the book DNS and BIND. 

Recursion is just one way to have a name server send bucketfuls of data to a
target. Another is zone transfer, part of the DNS protocol that enables any
name server to replicate its zone data to other name servers. One request can
create a response with all the information for that name server's zone:
computer names, IP addresses and possibly other information that describes the
type of hardware and the version of operating system. According to Liu, with a
big enough zone, the transfer can take 15 minutes or longer to complete. In
addition to creating bandwidth-choking amounts of data, these zone transfers
use the Transmission Control Protocol (TCP) rather than the lower-overhead but
more easily spoofed User Datagram Protocol (UDP) commonly favored by other
Net-based services. That makes zone transfer more resource intensive, putting
a greater strain on both the generating name servers and the receiving

Zone transfer also represents a disturbing amount of detail that a hacker can
legally glean from a target without probing. Furthermore, this information can
provide significant clues to the activity of a company and where it devotes
its strategic IT resources%Gβ€”%@a boon for rivals seeking
competitive intelligence.

Because most IT departments see DNS as reliable, they often barely monitor
their name servers. The DNS servers sometimes don't run through the firewall,
according to CERT/CC's Lindner, making them a perfect way for someone who has
broken into a network to tunnel sensitive data out by piggybacking it on DNS
packets that no one will notice. "[What hacker] cares if it takes a week to
get the data out?" asks Lindner.

Some data takes significantly less time to obtain. Dan Kaminsky, director of
penetration testing for security consultancy IOActive and longtime DNS critic,
notes that because of the way DNS caches data, there is much that someone can
pick up using a technique called cache snooping. "If your internal name server
is also shared and accessible on the outside world, then I can see if company
A is e-mailing company B, how often are people going to Google or Yahoo," he
says. Again, it's not necessarily anything that will physically compromise a
network, but it's still information you don't want a hacker or competitor to

And if DNS runs on a server that also runs other network services, something
that Kaminsky has seen at some companies, a compromise of the other services
could render the name server vulnerable as well. 

Taking Control

Aside from becoming a data sieve, DNS is subject to more subtle attacks via
tampering and cache poisoning. By changing the actual lookup data in the DNS
cache, an attacker can replace a server's real IP address with one that will
lead a user to the attacker's own machine. Until the cache eventually
refreshes, users will be misdirected with potentially no clue to what actually
happened. Hackers can use this attack to direct traffic away from the website
and potentially capture private information from users. This is the tactic
known as "pharming" (see "After Phishing? Pharming!").

"It's a hard attack to detect," says Lindner, "because if you're running a big
website and all of a sudden no one is coming to your website, you know
something's wrong. But if a half dozen name servers have cache poisoning, it's
too small [a diversion] and you won't notice it." 

There has been talk for years of making DNS bulletproof by adding a public-key
cryptography layer through an approach called DNSsec. "DNSsec tries to solve
the spoofing problem that SSL has already solved, and the extra round-trip for
DNS queries to get the public-key record only adds latency [to data traffic],"
says Nate Lawson, a senior researcher at Cryptography Research. Public-key
cryptography also requires companies to authenticate themselves to a
certificate authority and pay for the use of a certificate, reducing the
chance that many will buy in to the system. Finally, according to Kaminsky, a
fundamental problem is getting all the root domains to sign up. "Everyone
above you in the DNS tree must be signed," he says. "Everyone has to get on
board or it doesn't work." 

Despite these concerns, DNS isn't the biggest security worry a company can
have. ("E-mail's in way more dire straits," Kaminsky says.) Yet it can still
cause significant problems, and chances are good that any company has
potential problems with at least some of its DNS name servers.

Erik Sherman is a freelance writer based in Massachusetts. Send feedback to
csoletters at cxo.com. 

2002-2007 CXO Media Inc. All rights reserved.
Reproduction in whole or in part without permission is prohibited.
Dated: February 01, 2007

More information about the dns-operations mailing list