Olaf Kolkman, a Dutch DNS expert, is the new chair of the Internet Architecture Board, a panel of 13 leading network engineers who provide technical oversight to the IETF, the Internet’s premier standards-setting body. He’s also CEO of NLnet Labs, an Amsterdam research group focused on DNS security. After taking over as IAB chair at an IETF meeting in Prague last week, Kolkman corresponded with Network World senior editor Carolyn Duffy Marsan and shared some thoughts about his new role, why it’s taking DNSSEC (an approach to authenticating DNS traffic) so long to catch on, and topics the IAB may be tackling over the next year or two.
Olaf Kolkman, a Dutch DNS expert, is the new chair of the Internet Architecture Board, a panel of 13 leading network engineers who provide technical oversight to the IETF, the Internet’s premier standards-setting body. He’s also CEO of NLnet Labs, an Amsterdam research group focused on DNS security. After taking over as IAB chair at an IETF meeting in Prague last week, Kolkman corresponded with Network World Senior Editor Carolyn Duffy Marsan and shared some thoughts about his new role, why it’s taking DNSSEC (an approach to authenticating DNS traffic) so long to catch on, and topics the IAB may be tackling over the next year or two.
What do you see as the biggest challenges facing DNS and what needs to be done about them?
The DNS protocol is over 25 years old. When talking about the protocol itself, it has proven difficult to extend because any extension to the DNS needs to be fully backwards compatible to be able to integrate the extension into the deployed installed base and the way that the Internet currently functions. On the other hand, the DNS protocol has turned out to be a success and is at the core the most popular and scalable lookup service on the Internet. People are therefore looking at the DNS to provide lookup services for many applications.
Different applications have particular requirements of the DNS. The challenge is to make the tradeoff: Is the DNS the appropriate tool to do the job?
Can the requirements that are put on the DNS be provided without straining the system? And can potential extensions that are required be designed backwards compatible and be realistically deployed?
Two examples of new applications that explore the boundaries of what the DNS protocol can provide are the ENUM protocol that provides a discovery service for services that are tied to telephone numbers, and the DKIM protocol that uses the DNS to store policies that can be used, for instance, to cope with spam.
Your technical expertise is in DNSSEC, an approach to authenticating DNS traffic that has not been widely adopted across the Internet. Do you consider DNSSEC a failure?
No. DNSSEC has been talked about for over 10 years. The so-called DNSSEC-bis specification was only published a year ago. It is taking a while to percolate into software, and for that software to percolate into the market, and for people to adapt their environments to deploy and operate DNSSEC. The deployment is hindered by a chicken-and-egg problem. For most application developers, DNSSEC is not on the radar because of the lack of infrastructure, while for the providers of infrastructure there are not sufficient users to justify their expense.
Fortunately there are a number of top-level domains (TLD) that recognize the importance of DNSSEC and have stepped up to the table. As a result, some of the larger TLDs have been pushing for a modification to the DNSSEC protocol that slowed down deployment. This modification is a tweak to the protocol that has just been finished. Other TLDs, like .SE [Sweden] and .PR [Puerto Rico] already have DNSSEC deployed. More DNS infrastructure will need to be signed -- more TLDs, the root zone and zones at the corporate level. Besides, applications will need to start using that information. It is not realistic to expect DNSSEC to be deployed overnight.
To understand the relevance of DNSSEC, one should keep in mind that the DNS is used in almost every situation where users want to access a service somewhere on the Internet, and DNSSEC provides protection of that utility. I think it is important to go through the exercise of determining how important integrity and authority of the DNS is to the services that you offer. As an example, with the ENUM protocol, what would happen if the mapping from a telephone number into a service was modified? Or, what would happen if the name to address mapping for your stock ticker service was modified? Would you notice the padlock in your browser?
Over the years, the IAB has provided a big-picture perspective on issues facing the Internet engineering community including scaling, routing and security. What are the top three issues you would like to see the IAB tackle over the next year or two?
My personal motivation to work in this space is that I want to allow my now 3- and 6-year old children to make use of the Internet based on the same core principles as I now know them. When they are young adults, they should still be able to use, or even develop, new applications that will provide them with tools to socialize, do business, communicate or enjoy themselves. But by that time they will need to be able to hook up their device to a network that will connect them to billions of other devices all over the world. All of this should operate in a manner that is affordable, reliable, oblivious to the content of the packets that are transported, and which allows them to have their kids connect safely.
What the IAB will be tackling over the next year or two is up to the IAB as a whole. But I have an idea of what might end up on the agenda.
The IAB recently held a workshop on unwanted traffic, the report of which will shortly be published as an RFC. This is the first topic on which I think there will be more deliberations.
In order to connect to those billion of devices mentioned above, we will need to have a network that will be able to deal with the dynamics of the interconnections, as well as the shear number of possible interconnections. Within the IETF there is, partly as of a result of an IAB sponsored workshop on the topic, a fair amount of energy to define an approach to deal with the strain put on the network. The IETF is currently working on a better understanding of the problem and developing a future solution space. It is clear that during the process a number of architectural issues will emerge that will require better understanding.
In this context, tough and important engineering and architectural tradeoffs will need to be made by the IETF. It is my goal that the IAB will continue to provide a thoughtful perspective and independent guidance on this and other matters.
How does your job as CEO of NLnet Labs, an Amsterdam R&D foundation, prepare you for your new role as IAB chair?
NLnet Labs is chartered to develop open source and open standards.
Our expertise is in IETF protocols with the DNS protocol in particular. In this context, the IAB chair post fits within the goals of NLnet Labs and is therefore part of my day job, a notion fully supported by the board of the foundation.
How many years do you expect to be IAB chair?
The IAB chair is elected each year from the IAB members. In addition, the IETF nomination committee selects half the IAB members for a two-year term. My term will be up next year, so it is up to the nomination committee and then the IAB to extend my term past one year. I am prepared to do the job for two more IAB terms if I am selected.
What other positions have you held during your 10 years of participation in the Internet Engineering Task Force community?
I have been a participant since the 1997 IETF. I became co-chair of the working group that defines DNS extensions at the IETF-57, July 2003, in Vienna. I joined the IAB last year in March.
Learn more about this topicDutch DNS expert to lead Internet advisory group
03/19/07IETF pushes for interoperable NAC
03/16/07Lessons learned from Internet root server attack