Article to appear in APNIC journal

[Olaf Kolkman]

Introducing DNSSEC

<i>With the help of a ÒpotentialÓ news story, Olaf Kolkman explains why the Internet needs DNSSEC, how it works, and what is needed for its full scale implementation.</i>

<typeset this block as a phone newspaper article>

The Junee Business Times
BE-rt and erNie merger stung in DNS scam
Junee, 33 Noctember 2004

The Junee branch of Interpol's cyber crime department has arrested five individuals that are supposedly linked to the US$50 million stock fraud that occurred last month in relation to the merger of BE-rt Inc and erNie Ltd. The gang operated by exploiting weaknesses in the Domain Name System (DNS). The DNS is the system that is used to translate names like www.apnic.net into the addresses of the computers. The DNS is used whenever a user uses a name to access a service on the Internet.

An Interpol spokesman explained. "The gang used exploits in the DNS to reroute and intercept e-mails that related to the merger between the two companies. After obtaining prior knowledge on the stock rate and the date of the merger the gang used the same DNS exploits to reroute a stock-ticker service. By inserting false stock rate information for BE-rt Inc, they managed to influence the stock market on the day prior to the merger in a way that maximised the gang's prior knowledge. Through clever trading of stock options these guys earned US$50 million".

Insider knowledge was suspected when complaints about the false stock ticker information surfaced. Only after a full audit of the erNie Ltd computer environment was it shown that the information was not consciously leaked by the senior management of the two companies.

</typeset>


The scenario as described in above made-up article is not as far-fetched as it may seem. In virtually all interactions between computers on the Internet, services are located using the DNS. Email recipients are identified using the DNS; web services are found using the DNS; and applications like messengers, stock tickers, and Internet telephony all use the DNS to find the machines that one needs to connect to for interaction.

The DNS is vulnerable to attacks where the name-to-address mapping is being modified by an attacker. This problem was identified years ago. Since then, engineers have joined forces in the Internet Engineering Task Force (IETF) to develop extensions to the DNS that allow these name-to-address mappings to be secured. The security extensions are known as DNSSEC and are to be published as RFCs (Request for Comments, the IETFÕs standard documents) late in 2004.

After many years of development, DNSSEC has reached production quality in both specification and implementation. The BIND9.3.0 and NSD2 name server implementation both use DNSSEC. DNSSEC is now ready for the public Internet.

DNSSEC is based on public key cryptography mechanisms and allows DNS data to be verified for integrity and authenticity. In other words, by using DNSSEC one can tell wether or not somebody inserted a fake IP address for the mail server for "BE-rt Inc" and that the IP address for the stock-ticker service was replaced. DNSSEC would have prevented the mail and the stock-ticker service redirect in the above virtual example.

One could argue that this attack would not have been possible if the mails between the two companies had been encrypted and if the stock ticker server had used secured http. But in reality, encrypted email and secure stock tickers hardly happen. Deployment of DNSSEC raises the bar for a large set of attacks on all kinds of applications for which maintaining security on application level may be too expensive to do correctly. Many end-users do not use mail encryption because it is too difficult or too expensive.

It is expected that DNSSEC deployment will slowly pick up in 2005. As with all early deployment there will be a few hurdles that need to be taken: tools for DNSSEC administration are in their infancy and the benefits of early deployment are small as there are very few signed zones and very few validating name servers On the other hand, early deployment may provide competitive benefits in case DNSSEC deployment becomes urgent. Numerous parties, including top-level domain (TLD) registries are planning pilot projects for the deployment of DNSSEC and the Regional Internet Registries are actively tracking developments while planning for deployment.

Although the protocol and implementation details of DNSSEC are somewhat esoteric the principles are fairly simple. As noted above, the protocol is based on public key cryptography. Public key cryptography schemes are base on "key-pairs" consisting of a private and a public key. Users generate such pairs, publish the public key to other users and keep the private key securely secret. If Alice signs a piece of data with her private key then Bob can verify that the data originated from Alice with the public key. If Bob did not obtain the public key from Alice directly then he will still be able to validate the data provided a chain of trust exists between a key that Bob has securely obtained and Alice's key.

This is also the way that secure http works. You have securely obtained the root certificate, these sign a web servers key, hence you trust the web server. In DNSSEC the Alices of the world are the people who put together the zone data. They have a private key with which they sign the DNS data. The Bobs of the world are the DNS clients that will use the DNS to build chains of trust to validate the DNS data. For successful deployment, we will need Alices to sign DNS data and Bobs to validate this data.

This "chicken and egg" problem is one of the major deployment hurdles. Very few people will configure their recursive name servers to validate DNSSEC data in the absence of DNSSEC zone data. Few zone administrators will sign their data in the absence of validating clients. Few application developers will build new (presumably very interesting) applications based on top of DNSSEC, without an infrastructure being present. We can only hope that that deadlock is broken by deployment initiatives before the first major DNS attack takes place.


<separate block>

Further reading.

The scope of this article is to short to go into the details of the DNSSEC protocol, its implementation and its operation. Below are some relevant resources.

The IETF has finalised the work on the protocol definition, the following document are about to be published as "standard-track" RFC:

- ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-13.txt
- ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-11.txt
- ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-proto-09.txt


A good portal to DNSSEC related information is available at:
- http://www.dnssec.net/ 

The RIPE NCC provides a course on DNSSEC, with the material is available at:
- http://www.ripe.net/training/dnssec/material/

APNIC includes DNSSEC in its Advanced DNS Workshop, documented at:
- [need to confirm link]
 
A "how to" guide, on installing and operating DNSSEC, is available at:
- http://www.ripe.net/projects/disi/dnssec_howto/

Miek Gieben wrote an instructive article in the Internet Protocol Journal, available:
- http://www.cisco.com/en/US/about/ac123/ac147/archived_issues/ipj_7-2/dnssec.html

Some assorted DNSSEC pilots are:
- Dutch TLD ".nl" : http://www.nlnetlabs.nl/dnssec/
- Verisign cc-TLD ".net": http://www.dnssec-net.verisignlabs.com/
- Swedish TLD ".se": http://dnssec.nic-se.se/

Some DNSSEC operational issues are addressed in:
- ftp://ftp.ietf.org//internet-drafts/draft-ietf-dnsop-dnssec-operational-practices-02.txt 


</separate block>


Olaf Kolkman is a System Architect in the New Projects Department of the RIPE NCC. Among other things he is co-chair of the IETF DNSEXT working group that developed the DNSSEC standard and is author of the Net::DNS::SEC Perl library.