The Web    Google
DNSSEC: For When a Spoof Isn't a Comedy

DNSSEC: For When a Spoof Isn't a Comedy
July 29, 2004

Imagine finding your company web site defaced with obscenities and mad political rantings, or filled with links to pornographic web sites.

Quite apart from the embarrassment and loss to your corporate reputation, if your organization carries out online transactions it's likely it would lose a great deal of money from missed trading opportunities.

But if you're thinking of beefing up your Web server's security, here's the thing: malicious hackers can carry out an attack such as this on your web site without ever getting anywhere near your server.

That's because all they need to do is send would-be visitors to a different site without their knowledge, and they can do this using DNS spoofing. A potential customer enters your domain name into his browser, but the IP address that is meant to correspond to this web address -- which his browser retrieves from a DNS server -- is false. This, in a nutshell, is the problem with the DNS.

It's a system which binds domain names to IP addresses, and if the binding process between names and addresses cannot be trusted completely, no-one can or should rely on it.

''The problem is a fundamental one, because the DNS simply wasn't designed to be secure,'' says Russ Mundy, principal networking scientist at Lake Forest, CA. based technology company Sparta, and one of the leading names in DNS security research. ''When you get information from a DNS server, it's vital that you can verify the data's integrity and authenticity, and as things stand at the moment, that's just not possible.''

It's a Spoof, But It's Not a Comedy

This opens up the possibility of many different types of DNS spoofing attacks. The most simple of these is cache poisoning. An attacker provides an answer to a DNS query from the victim's local DNS server, and this information is correct. But in the ''additional data'' section of the reply, which was originally included so that helpful extra information could be added, a false record is surreptitiously placed. This could be a false DNS record for a completely different domain. Since this false record will be cached by the local DNS server, anyone using that server to access that domain will receive the cached false information (for the duration of the record's 'Time To Live' -- after when the record will be refreshed) and could be redirected to a spoofed web site instead of the genuine one.

A more complex DNS spoofing attack is the Man in the Middle attack.

Using tools such as DNS Hijack, readily available on the Internet, a hacker places himself topologically close to a company's name server (on a router that is ''owned'' by the hacker, for example.) From there the hacker can see the DNS query packets going by, and can alter them as they pass. If the victim was, for example, a bank, then anyone querying the bank's name server to find the bank's web site could be given the IP address of the hacker's replica site -- where he could harvest all kinds of confidential and valuable information.

So if the insecurity of the DNS is so well known, how come nothing has been done about it?

Well the truth is that it has -- or at least it is in the process of being done. Mundy and his colleagues have been involved in research -- funded by the US Government -- for the last five or so years, to help develop a secure DNS which offers the assurance of data integrity and authenticity to Internet users. Their solution, DNSSEC, is an extension to the DNS which uses key encryption.

''DNSSEC removes the DNS threat by adding additional information to the zone data. Essentially, information you get using DNSSEC is digitally signed. When you get data from DNSSEC you can, as a client, validate that the data is the same correct data that was originally put in to the DNS - so the Man in the Middle attack is stopped.''

Third Time's a Charm?

You may well be reading this and thinking: ''Hang on! I've heard all this before. DNSSEC has been around for ages.'' And you'd be right.

But the first two designs for DNSSEC, embodied in RFC 2065 and RFC 2535 never took off. The latest one is due for submission to the Internet Engineering Steering Group (IESG) at the end of July 2004, and Mundy believes that finally this will lead to widespread adoption.

''The first two designs were not really viable from a field support perspective. But now we have had user involvement from day one, and we believe we have got this right,'' he says. The system is undergoing live trials right now, and a six month experiment with the new DNS SEC was carried out by the .NL TLD registry in 2002.

This article was first published on To read the full article, click here.

  • 1/26: Patco-A Worm Replaces Doc Files
  • 10/21: Bloodhound.Exploit-17 Detects Files
  • Secure Your Network Against Viruses, Spam
  • A Jump on Security Advisories (For a Fee)
  • Sigaba Adds Federated Authentication to E-Mail Security Software
  • 3/11: Ruzes-A Trojan Grabs Email Addresses
  • 3/30: Anicmoo-C Trojan Arrives in Package
  • 1/5: Rbot-SQ Worm Has Backdoor Abilities
  • RIM Refutes BlackBerry Buffer Overflow Claim
  • 10/20: Spybot-DF an IRC Backdoor Worm
  • CERT, ArcSight Partner With 3 Universities On Security Sharing
  • Computer security background information