ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

Please note:

You are viewing archival ICANN material. Links and information may be outdated or incorrect. Visit ICANN's main website for current information.

ICANN Meetings in Lisbon Portugal

Transcript - DNSSEC for TLDs: Experience from Sweden and Bulgaria

28 March 2007

Note: Although transcript output is largely accurate, in some cases it is incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.

>>STEVE CROCKER: Let me begin the session. Let me thank everyone for coming. My name is Steve Crocker. We have a -- quite -- and I'm standing in the way of my own slides. We have a quite enjoyable and, I think, historic set of presentations to make regarding the introduction of the DNS security protocol in the -- as an addition to the basic DNS operation.

I have a couple of hats in this process. I chair ICANN's Security and Stability Advisory Committee. Several years ago, when we were first starting up, we recognized that DNSsec was one of the important objectives within the ICANN space for improving security of the domain name system. We put some effort into trying to facilitate it, and one of the -- one of my colleagues that I respect very highly, Bruce Tonkin, took me aside one day and he said, "This isn't going very well." These weren't his words exactly, but he was much more polite. And he said, "You need a bigger effort. Get some money, spin it off."

Fortunately, a number of good things came together at that moment in time at the U.S. Department of Homeland Security with information in putting together its own cyber security support program, and allocated some funds within the U.S. for facilitating DNSsec adoption.

Of course the development of the protocol has been a worldwide effort and there's been significant points of leadership well outside of the United States. Today, you're going to see the fruits of a quite substantial part of that leadership from Sweden, and related activity from Bulgaria.

There's also been activity that has been presented in these kinds of meetings over the past few years from other parts of the world.

So that deployment initiative is something that within the U.S., in any case, I'm also cochair of, and so it's been enjoyable for us to be involved in facilitating this.

A month ago -- about a month and a half now -- Sweden launched formally its commercial deployment of DNSsec, and I was privileged to be present at the launch and say a few words. I was actually expecting an extremely well-organized and well-run operation and it was all of that but it was surprisingly -- surprisingly to me -- a great deal more. In addition to the registry operation being fully up and running and good communications and orchestration with the registrars and good alignment with the government, there was in addition -- and this is the part that caught my attention considerably -- ISPs were involved and the banks. We have here today an all-star team. I mean, I don't think we could do better, from a worldwide perspective. And I will introduce them momentarily, but we have a -- sort of like the traveling roadshow of the best and the brightest in this field. And a more recent activity, I only -- I only recently became aware of, is that Bulgaria has signed its!

own -- we have Daniel Kalchev from the Bulgarian registry here as well. My plan is to get off of the stage relatively quickly and then turn the microphone over to each of these gentlemen to go through their portions and then toward the end, to have a wide-open question-and-answer session. I would imagine that it would be okay to take a question or two, but not many, associated with each of these, but mainly for clarification and I'll be fairly forceful about trying to move things along and watch the clock.

We went to a considerable amount of trouble to force open the schedule to create a big enough block to accommodate this, because we all thought it was very important, and even so, I'm nervous about whether we will fit comfortably within the time.

Next slide. So this is my most important message here. I think this is a -- just a great moment, and I heartily congratulate everybody here and so I'm just going to clap. You get to clap later when you hear how good this is, but this is from me. And the next slide.

So we have five talks from the group from Sweden. Jorgen Samuelsson from the registry of enterprise, energy and communications, from the overall government perspective. And at the end of the sequence, Anders rafting from the Swedish national post and telecommunications system -- I couldn't fit it all on there so I abbreviated it, with the more direct management of the process from the government perspective. I think both outward facing and also inward facing within the government, perhaps, and you can say a word or two about that.

Staffan Hagnell, from the SE registry has certainly been the sparkplug of making it happen inside the registry, but along with a team of other people that I was fortunate to meet some of and I suspect there were just one or two more behind the scenes. Mats Dufberg from the ISP TeliaSonera -- is that close?

>>MATS DUFBERG: TeliaSonera.

>>STEVE CROCKER: I think I just misspelled it, though. TeliaSonera. On the resolver's side of things. We're running a resolver within the ISP on behalf of the customers.

Kjell Rydjer from Swedbank on the bank's perspective and the importance and the role of using DNSsec within the banking system. And as I mentioned, we'll wrap up with Daniel Kalchev from the Bulgarian registry, talking about the experience there, which I was -- understand has moved along remarkably quickly, and to some extent has benefitted from watching the Swedish activity. So that's what I have to say and now I want to move along, as I said, rather quickly here and turn things over to Jorgen.

>>JORGEN SAMUELSSON: Does this work?

So good afternoon, everybody. Oh, sorry. My name is Jorgen Samuelsson. I'm from the ministry which you see there working in the division for IT policy. And if you are impressed also at the end of this session, I just would like to say that it has nothing to do with me. It's the other guys that you see on my left and on my right here.

And I will just take you through the Swedish IT -- the Swedish strategy for a safer Internet that we quite recently established. And why we did this.

This is the background and rationale, at the start of it, and we realized how the Internet is important for a lot of different areas, and just enumerating a couple of them, probably most importantly from the government perspective the 24/7 agency and all the electronic implications that we're serving to our citizens. And the background is also that we got some very good and -- input from the national post and telecoms agency, PTS, and we took that input and proposal and it -- it was a very good report. It consolidated the thinking. We have been working with these kinds of things before, but we wanted also a strategy to promote this work and to visualize it.

And some of the general conclusions from that input was that the Internet is robust, but the problems that exist, they are a moving target, so you need to have a long-term perspective and you have to constantly review and promote, and where appropriate, also influence. And I guess that is what we're doing when we -- when we make, for example, DNSsec, the implementation of that, part of the strategy in Sweden. And we also concluded in that report that the security level must be so high that the use of the Internet uptake is not limited by lack of trust.

So in some more specific conclusions from the strategy is that the physical infrastructure must be protected against a lot of things. Accident, disruptions, wiretapping, and manipulation of information that is being transmitted. We have to have resistance to disruptions in traffic between operators and this resistance should also increase. Everybody procures and uses and everybody in the market, they need more education and information so that we can increase the security consciousness all over. We also think that Internet operators and suppliers of hardware and software should take more responsibility than they do today. A lot of responsibility is put on the end user which is often not very competent in dealing with these kind of issues. And also we have to have more -- develop more knowledge about Internet infrastructure and have it more broadly promoted and also to do this in the context not only of the infrastructure security but also information security, and tha!

t is, of course, important from the government's side.

Some other conclusions from the report, more specifically, is that we also concluded that we need to take part more in international forums like this one, like we're doing now, and that we should do that in cooperation between both the public and the private, as we are doing right here.

And we also realize that we have to be better at handling the crises that do occur, and to enhance that ability, and last, but not least, resistant to disruptions in the domain system should increase, and so implementation of DNSsec is part of an action plan that is attached to the strategy. That is today's subject. Thank you.

>>STAFFAN HAGNELL: Yes. Hello. My name is Staffan Hagnell. I'm at dot SE as we're now calling our registry for dot SE. I've been working there for -- since the year 2000 and now I'm working with research and development at dot SE.

So I've been the project leader for this DNSsec project. I am the project leader, and to go into a short history, we have had some different phases within this project. We started it quite early. We had our first meeting in -- back in the year 2000, but what we run into was that the standard wasn't really finished, so it took a number of years before we got this standard stable, DNSsec standard stable.

And then we took a very distinct step of signing the dot SE zone. Signing the zone means that we have to put up systems for this signing. It should be secure. We should have routines. We should have policies, and that kind of thing. So it's really a major step to make this signing.

And we learned a lot during the year. We started to allow customers -- no, not customers, technical testers into the zone, and we thought that everything was working fine and we were ready to take the next step, and we think it's a major step also to say that, okay, now this is going to be a service. It's a different thing to have a service than just a technical test running.

So earlier this year, we choose to put up this as a commercial service, and we have been working a lot for making this service real.

So not just making this into a service or what we had to do to make this into a service. Well, it would be quite easy if we were alone but as you all know, DNS is a cooperation between a lot of different parties, and often you hear somebody say this is a hen and egg problem, what shall we do first, and the real easy answer to that is that you have to do everything at once for getting DNSsec up and running.

So it's really important to be some sort of coordinator to see that everybody is doing their part of the job, so we have taken that part of being some sort of coordinator for making DNSsec move.

And how do you coordinate? Well, the first thing, I think, is that you have to just look at DNS and DNSsec and ask yourself: What is the value chain? I mean this is sort of normal business behavior. Who is gaining what from this? And the value chain for DNSsec is basically the same as for DNS. This is nothing you -- for all you guys. I mean you're very familiar with this, but if you identify the parties, you get the registrants. We are providing service to the registrants, so Internet users could get information and connect to this registrant's different resources.

So of course we don't deal directly with the registrants. We have registrars which are very important. They provide service to the registrants and they provide service to us, the TLD.

Really, the one who is using this thing, you have a chain of users. You have the DNS resolvers, you have the applications, you have the end users, and what they are using is not simply dot SE. They -- for this being a valuable service, they must have service from root, they must have service from the TLD and very, very important and often forgotten is you also need to have service from your own DNS name service provider. And this one, when you go into DNSsec, has to offer DNSsec administration. And this DNS name service provider are often, as I said, forgotten. The service is often for free. You don't ask the quality of this kind of service. So when we go -- are going into details and start to look at different sites that should go into DNSsec, you have to start to look at how does the DNS name service work today. Maybe you have to start with just making a better quality of your DNS name service before you actually adopt DNSsec.

So it's a very important thing to regard all of this and start to see what shall we do with the different players to get DNSsec up and moving.

So the first obvious thing is the customers. The registrants. Do they want DNSsec? And often you'll hear that somebody -- somebody say that, well, they don't need DNSsec before something -- application, whatever -- so one very obvious thing is to ask the registrants, "Do you want this? Do we have to explain for you what this is or -- well, do you want it?" So we made a survey on our own customers and simply asked them, "We are planning this commercial service," a slight explanation what DNSsec is, "and would this be interesting for you," and very gladly found out that, yes, the majority said yes, we would like to have this DNSsec.

Do you know what DNSsec is? Do you know what it does protect and what it doesn't protect? Well, maybe not. But anyway, they would like to have it. Like everything that makes the Internet more secure, in my opinion is really desired for the end users.

So then the tougher question: Okay, DNSsec means more administration. It will cost. Are you actually prepared to cost -- to pay to use this if you have to pay?

So say something. Let's say 50-Euro. Are you prepared to buy DNSsec for 50-Euro? Who should have this 50-Euro?

Well, as I said, you have the DNS service provider that should actually provide a more advanced service now. You have the registry, you have the registrants -- registry, you have the registrants and so on. So I don't care who gets the $50. The question was just: If it costs $50, would you be interested still? And amazingly, I would say that, yes, still 25 percent are interested. So obviously there is an interest for DNSsec and there's an interest to actually pay for DNSsec. That's a very good knowledge to have, that you don't have to explain what DNSsec is. There are, from the beginning, a very big interest for DNSsec.

And as I said, what is the actual value of DNSsec? Well, that could be discussed, of course, but if you look at the present use, why are you using domain names? Well, you use them mainly for connecting to Web sites and e-mail. That's the main two purposes of domain names. And some other topics. And DNSsec should, of course, make this connection to this Web site and delivery of e-mail more accurate. But as I think, very important, I believe that DNS will be more and more important infrastructure component. So what we are doing now is not just for the present application; it's also for the coming applications. Someone believes that we will actually run telephone on the Internet, SIP and ENUM, and -- if you start to do that. I don't think that people would appreciate their phone calls being redirected to other places than they thought from the very beginning.

We could look at our current applications, like e-mail and see that there are interesting developments for e-mail. I see the domainkey identified mail, DKIM and SPF as such examples. How much they depend on DNSsec and what role exactly the DNSsec are I shouldn't go into detail on, but as I believe DNSsec actually adds value to these kind of things.

When we started the DNSsec project back in 2000, one of the first things we said was that we have to add value to DNSsec, so we started to make development of SSH, where we put the DNS -- where we put the key in DNS. And sort of used DNSsec. But the thing that happened was that DNSsec never took off, so that project were sort of turned down.

But once you got DNSsec, you can actually start to develop the application with the knowledge that you've got DNSsec and you can use that infrastructure, DNS infrastructure, for this.

So it's not just for today's application; it's also for the coming application, and there is obviously a weakness with DNS today that DNSsec is dealing with.

So I will not go into detail about DNSsec more than that.

So the question is: How shall we start this thing? How shall we get things moving? There has to be a value for the customers to buy DNSsec, so let's say, yes, it would be great if the applications actually validated DNS data, but then you will run into the problem with Microsoft and others actually start to offer DNSsec solutions? And as we have -- as we have said, no, we are waiting with that. We're see two phases in this. The first phase, the value for the customer is that the DNS resolver should validate the data. This put the validation closer to the end user. The DNS resolver will start -- well, it could be like Mats from TeliaSonera is a resolver within the customer's ISP. If there's a problem between the resolver and the end user, it's within one ISP, and I guess could be dealt with by that ISP, and sort of responsible for that ISP to sort out. And of course the resolver could be closer to the end user. You could run your own resolver on your own machine, !

if you have a server, for instance.

So by validating DNS data closer to the end user, we actually create value. Yes, the ideal thing is to have this up in application, but we'll take that in the next step.

So if we look at the different participants and see who shall we actually activate now in the first step, we have to start with registrants, of course, who should -- who should buy this, the registrars who should provide the service to the registrant to buy this, the DNS name server provider that has to provide more advanced DNS services, the registry, and the resolver operator.

If we start with them, we could actually say that we are creating value and the end user -- the registrant has a reason to buy this.

Later, we will deal with applications, but first, for the application -- and the user application, there has to be customers out there, so our strategy is to start with those actors in Phase 1 and take the applications a little bit later.

Another thing is how shall we use price when it comes to DNSsec? There's been a lot of discussion with price. Someone said that, "Well, it's quite obvious it should be cheaper to run DNSsec because you're more safer, you're better Internet citizens, so the one who has got DNSsec should actually get this cheaper."

And I think it is really about timing, what steps should we take here and the way we are thinking now is that we are sort of responsible for the stability of dot se, and we should take this very careful now. We don't want to have 100,000 domains signed overnight because that will increase the load on what? Well, on the resolvers, on the SS zone will grow larger, on our customer service or whatever. We would like to start this a little bit slow so we see what actually is happening before we increase the load. So reduce the price as a steering mechanism to not get too much customers now. And "now" is now and let's say coming six months.

Later when we see our stability, we can always argue about the price and let's say let's lower the price if that's a reason for that.

It is also very important to see what's a consequence of price for all these parties involved in DNSsec. I don't know what Mats will say, but maybe he will argue and say I don't want to have this 100,000 DNSsec domains from the very beginning because that will actually increase the load on our resolver, which will make it harder to begin with DNSsec.

It is safer with more volume and actually increase, and this is also an argument for us telling everybody we think you should actually join now when volumes are low. We will increase the volumes slowly, and if you wait too long, you will get into the complete mess sort of. But now you have a chance to begin and learn when the volumes are small.

We also need money for our registrars so they could have a sales commission. As Jorgen would say, first year's price we will give a kickback to the registrar. So actually it is an incentive to sell DNSsec.

Bottom line of all this argument is that we will start with DNSsec as an additional service but it will be quite high priced. We will lower the price and some time in the future, I'm quite sure, we will bundle DNSsec with GDNS and sell it for the same price.

But that's not the case right now. Right now we are selling DNSsec as an additional service. It is twice the price as a domain name price; and the reason, as I said, is we would really like to get things started to move slow. We are not afraid that there is not an interest for DNSsec because we have made survey and we know there is an interest for DNSsec actually.

Whether we will come to that scenario that it will be cheaper for those who run DNSsec than for those that doesn't, I don't know. I'm not responsible of putting the price on their SE domain. It started with an initial price that is quite high, twice the domain name.

So those are some of the fundamentals you have to think about, price and strategy. Then you have to get into, okay, what activities should we actually have for all the different participant for making DNSsec move. We have the registrants. We have the registrars. We have domain name service provider. We have our own problems and we have the resolver operators. We must have activities for all of them to make these work.

And if I just try to sum things up, most activities that we should have for the registrants, as I said, first, we have some sort of market survey. We could put out some more market surveys if we would need more information.

The idea is, of course, that the registrars should handle the registrants. We should not sell directly to them. But I think it is very important that dot se's work would pilot customers like government, like bank and finance, like universities and technical interested parties.

It is not because we are going to steal the market from the registrars, but we will help the registrars to build up an interest. And, actually, if there are resources or whatever needed, we think this is a very important pilot customers in those groups. So we are ready to do what we can to help things speed up.

And it is quite easy for us if we see that things will not work as fast as we expect to have some campaigns. We have e-mail addresses to all our customers. We could e-mail them and say, hey, now you can buy this. But we will not do that for the moment.

We also know it is very easy to get public interest for DNSsec, but we will be a little bit slow on that also.

Then we have the DNS name service provider and those are interesting because I think these can be a bottleneck. I'm not sure if you agree with me on the name for this entity because I haven't really seen a single definition for them.

But I think you understand what I mean. So we will start to ask who are they that are actually name service providers for dot se domain name holders.

So what we did, we counted the domain name service providers for dot se domains. We have 600,000 dot se domains. It is run by 12,766 different name servers. If you start to look at these different name servers, what are the organizations behind them? We find that there is four organizations actually taking care of about 40% of all the dot se domains, just four organizations.

51 launch in the range from 1,000 to 9,999 and so on. If you look at this way, ten organizations dealing with half of the DNS names. Top 100, 80%; Top 1,000, 94%. And the rest, about 12,000 -- well, almost nothing. I think this is interesting. It really shows that from the very beginning of the Internet, everybody put up their own firewall, mail server, DNS server. Now you are seeing a proximalization of this business.

So it's important for us to note how do we find this and how do we actually make them start to provide DNSsec. Well, some of them we knew -- we got 200 registrars. If you look in our registrars, they are actually responsible for 80% of all the DNS name servers and customers. We knew where we could find them, and we will have activities to try to speed up things.

We have discussed and we are working on providing some sort of reference platform for the smaller. The larger say don't bother, we have our own system. We have our own developers. This is too complex. Don't mess things up. We will take care of DNSsec. We think within the range of 100 to 1,000, they could be helped if we are providing some sort of reference platform that could be used for DNSsec. So tools in that instance is kind of important.

We have been running DNSsec courses for them, and that's also important. We are planning to have some workshop with them. This is a group that we think must be better and start to provide registration.

The registrars, yes, from the very beginning we started with five registrars, now we send out e-mail and asking them to join more of them. We will pay a kickback for the first 5,000 registrations, so they will get all the money that it cost. We say that if you have some extra cost for actually running DNSsec, to provide the service, come and tell us and we will discuss whether we could give you some subsidize for things to happen.

So they are a little bit conservative, but I am hopeful.

Resolver operators, I should be very short on this one because Mats is a brilliant example of resolver operator, so you will have this.

But I think if you try to look at who is the resolver operator, while we get four major ISPs covering 80 to 90% of all broadband customers, they are very easy to target. I have spoken to all of them and they are saying, yes, we shall implement DNSsec.

So Mats will come back to that one.

And one reason we don't want to have a huge volume from the very beginning is actually administration. And this is the same reason as the registrars -- the same problem as the registrars. You must sort of know which customers do have DNSsec, which don't, so in your administrative system you have to make adjustments. And we are not really finished with this. We have a lot of manual handling of our DNSsec customer for the moment. We will have a fully integrated system but it takes a couple of months, let's say half a year before it is finished.

And in the meantime, we don't want to have 100,000 DNSsec domains, because then we have to employ a lot of personnel.

As a curious thing, we can say this is almost embarrassing. But have we signed our own domains? Yes, we signed the SS zone, yes. But our own domains we have about 50 dot se, (listing names). Actually ,we haven't signed them yet. It is really embarrassing. Why? We should have different routines for this. This should have been the same routine as dot se but SE is easy, it is just one domain.

If you are going to handle 50 domains, you will have tools for this and it should be other personnel doing this. So we are working with that. It is a bit embarrassing but, yeah, sort it out.

So to sum this up, I would say that key findings, registrants, yeah, it was a very nice surprise to see there was a big interest for DNSsec out there. But also there is a problem because even though if they have DNSsec, we start to ask how does your DNS service look today, they don't really know.

And often it is quite natural to start to think that DNS and -- I mean, one other problem we have with DNS is that you could have DOS attacks. Maybe you should also think about building a more robust DNS service. It is quite natural in several cases, I think, to actually start looking at your DNS service and build a more robust DNS service before you start to implement DNSsec.

That will take half a year or something for them to sort out.

If you go to the registrars, well, one of the main obstacles for having DNSsec as an additional service is not the technical stuff. It is that they are saying, "hey, this puts requirements on our administrative system. It means we have to look over our billing system." Yes.

"Well, we don't have any sort of additional service. We almost don't charge for the DNS service." This is really sort of stupid thing but things that has to be done to adjust the administrative system at the registrars.

Typically, the registrar is also the DNS name server provider, but we would like to make a separation because it doesn't have to be the domain service provider. So this could be you, but typically it is the DNS registrar.

As I said, a key finding was that you have a (inaudible) of the name server providers. There are a few of them that are real large which makes it easier for implements DNSsec. On the other hand, what shall you do with the rest of the top 12,000 that's not really proximalized that has maybe one, two domains. Will this make the sort of proximalization of the DNS will do even faster if you apply the DNSsec.

From our own experience, I would say the most painful thing was our realization that we have to adjust our own internal administrative system for actually running DNSsec. The resolver operators, I am very glad that there has been such a positive response from the resolver operators.

Applications, yes, we do miss securityware applications. As I said, we will take that later. End user, how should they actually see that a domain is DNSsec aware? And the answer was correctly validated.

I leave that to Mats. The simple version is that, well, if you have any problem, the answer will be thrown away and the user will not be able to connect to the domain. That's the simple answer.

Finally, the conclusion is that, well, we started with DNSsec and it is not only we, it is all of us together, registrants, registrars, name service providers, registry, resolver operators that has to work together to make this happen.

And dot se registry is definitely committed. Our board has seen we have a budget and that kind of thing and we are prepared to spend more resources and money on this. So we are really dedicated to get this thing up and work.

But as I said, we will not rush into this right now. Let it take six months. That's totally okay before we actually start to push to get larger number of DNSsec domains.

As I see, the main argument for registrars, DNS name service providers, resolvers, to start with DNSsec now, even if I say we will not have the volume right now is that you should do that because now you have the time to learn this when the volumes are still low. So that's a small thing to start right now.

Okay. That's the registry view on this.

>>STEVE CROCKER: Thank you very much.

>>MATS DUFBERG: Okay. I take over the work and I will talk about the resolver side of DNSsec as coming from an ISP, if I can handle this cable without creating a mess.

I come from TeliaSonera, just a few words about us. We are a major ISP and telephony operator provider in nordic and Baltic region. And especially in Sweden where I come from. So I will speak from a Swedish perspective.

Some words about the two roles in DNS before coming into the resolving to make sure that everyone understands the different roles. Hosting, that is to publish the DNS data and that is what Staffan has talked about. So in the TLD dot se zone you can find www.telia.se. But you have to know how to find those servers that will host that domain or that zone.

Resolving is how to find the data so when you use the Web browser to get in touch with www.telia.se, it sends a queries to the local DNS resolver. And that could be in the office or with your ISP. That resolver will look it up, find it and that will require multiple queries and return the answer back to the browser.

So as an ISP, we provide that service for our hundreds and thousands of broadband customers. They take it for granted. They don't know about it. And if it stops working, they think that the Internet connection has broken down, which is true in some sense.

For DNSsec, we have to have DNSsec in both areas, both in hosting and in resolving. And Staffan has talked about the hosting side.

Today the dot se zone is DNSsec secured and next step domains on dot se will get DNSsec secured. There are a few se domains, I don't know how many, and that number will increase over time.

And that requires extra effort to do that security. And that security is a complete waste of resources if there is no DNSsec secured resolving, too.

The DNSsec secured resolving will check the data and will stop corrupted data or tampered data that has been tampered with. That data will not even reach the customer, broadband user.

So the ISPs will be major players for a broad introduction of DNSsec. Without ISPs, the majority of the users will never take any use of -- have any use of DNSsec.

Before just turning it on with all those customers behind our resolvers, we decided to do a field test with DNSsec resolving. Testing a lab is one thing and that has been done it.

We got a chance in November-December last year to do a field test. With a field test, you test real users.

We had a chance to have 8,000 concurrent active users using DNS, I mean, as they do. We turned DNSsec on for those users.

They were not our normal customers in our normal service. They were actually participating in a long party. And that gave us a chance to see how DNSsec will work today when we don't have that much DNSsec.

So actually it doesn't say anything about the future but as Staffan has pointed out, by starting now, we will gradually increase the load. We know if we turn it on today, it would work or break depending on how the field test runs, of course.

So some words about the setting for the field test. So Dreamhack is a regular LAN party in Sweden. It actually is the certified largest in the world by "Guinness Book of Records." There were 8,000 young people, around 8,000 young people during these days, November 30th through December 3rd, four, five days.

They were sitting there practically around a the clock using their computers. They brought their computer to the setting. They had -- we actually provided ten gigabyte Internet connection for the LAN party. In one direction, it was filled. In the other direction, we got just five gigabytes. That's a small city being online.

Of course, I mean, they were not using DNS because they want to use DNS. That was indirect. They were playing games, browsing the Web, chatting, downloading, uploading and doing whatever they usually do.

And DNSsec -- and DNS, they took that for granted, of course. In that setting, we turned DNSsec on. We used BIND9.3.2 for that and we had the dot se zone key as the trust anchor for resolving, which means that only data under dot se was validated.

We had two servers but actually only one was used in practice. The other one was just there in case the other one would break.

And that was because they -- that's the way the ISP worked.

What was the result? It was actually kind of boring being there because nothing happened. No support issues. No a single support issue and I was there doing other things. No problems with the servers. Nothing strange happened. And actually the users didn't know it. I mean, a few users knew it because we had a small workshop there with some 30, 40 people and they knew it. But that was mostly a little bit older people attending that workshop.

So turning DNSsec on at the LAN party was no rocket science. It was quite boring.

So the next step for us at TeliaSonera is to turn DNSsec on in real production. And we see DNSsec as an upgrade of DNS, so to turn it on in the resolver is the natural upgrade of the resolvers.

The field test and lab test have shown that there is software that can handle DNSsec resolving. So in the second quarter this year, I mean, quite soon, we will turn on DNSsec's resolving for all our hundreds of thousands of broadband customers.

This time it will not be a test but upgrade in production.

There is a limitation and a catch and the problem is that we don't have a signed root zone. So what we will do is we will put dot se public key in the resolvers. And until the root zone is signed, the trust anchor must be one or several TLD public keys. And that is not a good solution.

One is okay or a few keys is okay. But, of course, we could never accept to have 30, 40, 50 keys. That would cost too much.

And I say that the ISPs will never accept to go around fetching multiple keys around different Web sighs and FDP archives, et cetera, to get the keys.

There are two alternatives. The main alternative being the correct alternative, and that's a signed root zone. So when there is a signed root zone, there will be one trust anchor for all DNSsec. And that is, of course, the way we want to go and that's the way all parties running resolvers want to go and that's independent if that is private person in his home, a small company in his office, a larger company or an ISP.

So the lack of a signed root zone may turn out to be the main obstacle or one of the obstacles for DNSsec. Will create problems for the launch of DNSsec.

We have heard rumors today about -- that the root zone will be signed but until we know for sure, we can't count on it.

So we have a second alternative and that is to create a separated DNSsec root.

So we have a second alternative, and that is to create a separated DNSsec root. Okay. This is not a separate DNS root just for the keys. To have some single place, some trusted single place where all the TLDs with signed zone can upload their key, or maybe they the repository will fetch it. Which way, I mean it could be either way. In some way, the key end up into this single repository and then the resolvers which you see down on the right side will be able to use that repository.

In this picture, there are three alternatives. You could maybe fetch it by HTTP and then configure it into the resolvers, or you could use a DLV, which is a solution to create this kind of -- or technique to create this kind of solution. And send queries to DLV zone or have a local DLV secondary. I'd say that a local DLV secondary is probably the -- the best solution, and probably to have it in the resolver. to keep down the load.

Okay. Who should -- who should run this? The operator of such a repository must be accepted, internationally accepted, must be trustworthy, of course, have good insights about this field, must be an open organization, and of course it must be an organization that the TLDs running DNSsec want to cooperate with.

And just to bring something out, my candidate for this is a couple. I suggest -- and I haven't spoken to them, so -- but my suggestion is CENTR, being an organization of ccTLDs as the administrative body being responsible for such a repository, and ripe as the operating body for the repository. I don't say that this is the only alternative, but I just want to bring something out to show something that could work in this context.

And I want to emphasize that this repository should only be there as long as the root zone is not signed. And the repository should only be responsible of TLD keys. And when the root zone is signed, this repository should be migrated away and the root zone will take that role again. As it should.

Well, I don't know, just -- if there are just some questions. Otherwise, we'll take questions in the end. Maybe everyone should stand up and sit down to wake up.

[Laughter]

>>MATS DUFBERG: So if you want to get in touch with me, there's the information, and then the presentation is available on the ICANN Web site, as well as all the other presentations.

>>OLIVIER GUILLARD: Sorry. Sorry. Olivier from France. Is it the intention to have all the presentation and ask the questions at the end or...

>>STEVE CROCKER: The intention was that if you have a -- one or two questions for clarification, we can do them in sequence here, and then we'll have a question-and-answer session at the end, so did you have a specific question?

>>OLIVIER GUILLARD: To the three gentlemen before --

>>STEVE CROCKER: Okay.

>>OLIVIER GUILLARD: To any of them.

>>STEVE CROCKER: Sure.

>>OLIVIER GUILLARD: Yeah? You're just saying that some candidates for the key repository would be ripe or CENTR, for example, and we had a presentation at the beginning of a project of improving security in Sweden and -- from the gentleman from the government. Would it be from a government perspective an acceptable solution to have this kind of organization, and what would be the responsibility of this --

>>MATS DUFBERG: I represent the ISPs or actually one ISP.

>>OLIVIER GUILLARD: So it's more I think a question for the previous --

>>MATS DUFBERG: And it's the ISP requirement that -- to have one single trust anchor, so it's our suggestion -- this is not -- this is my suggestion.

>>STEVE CROCKER: Yeah. Okay. Let me -- let me just -- I think that's the kind of question that perhaps there will be enough discussion about that rather than try to take it in sequence here, we'll have a lively discussion at the end, because I think that is a very important thing, rather than to interrupt the flow here.

But I do like the idea of stretching, so let me recommend exactly what you suggested. Let's everybody stand up and stretch for a minute and then we'll continue. Seriously. Do it!

[Laughter]

>>STEVE CROCKER: All right. That's enough stretching. Let me ask that we get going again. Thank you.

>>KJELL RYDJER: Okay. I will continue then the presentation. So my name is Kjell Rydjer and I'm working for Swedbank, one of the banks in Sweden here, and I am working with the strategy and architecture in Swedbank. Mostly with IT security and communication.

And I will take some experience from DNSsec in Swedbank. So I will tell a little bit about the background, the experience, some apprehensions, and a little bit about our roadmap then.

For background, why did we do this? We can see that as a bank, we need to be at the front edge when it comes to security communication, and certainly when we do Internet banking. And DNSsec is one way, as we can see, to prevent the phenomenon of pharming and phishing and actually today, I'm sad to say that Swedbank are under a phishing attack for the first time in their history, so it's a hard day for me now, so I am very concerned about this now. Even more than I was before.

We can see also that the most critical moment -- one critical moment is when the customer initiates a session to the bank, and if we can secure this session initiation to the Internet bank by using DNSsec, we will support it then.

We can also see that DNSsec prevents manipulation of DNS information and records. As you all know, the threats from the crimes today, moving from directly hitting the bank, moving to the home environment and the home PCs and the home PCs is the weakest part for the moment. And can we strengthen that up. It's -- we like that.

Swedbank has participated in this DNSsec test. We started up a test environment in Swedbank in the beginning of 2006, and this is a little bit how we did it. We start -- we started up with two new logical name servers, one primary and one secondary, separated from the production DNS environment. We registered DNSsec-FSB.se and delegated it to the servers and, yeah, we signed the secure zone transfer and we create some pair of keys and signed our zone and sent it also to dot se.

Some observations we have done after the technical installation. The hardest part when we do this was for these guys handling our DNS environment today was to understand the key handling in DNSsec. It's old-fashioned peak value infrastructure using DNSsec but these guys not familiar with these things so they have to do some study before we get everything right. And after that, the guys told me it's [inaudible] between installed DNSsec for us, so we still are very positive with DNSsec.

We have some apprehensions also. We can see as a bank we are very statical DNS management. I think we have to spend about 50 hours per year managing DNS. It's very low. I was surprised myself, but it's very easy, very routine for us. A rough estimate running DNSsec in Swedbank, it would cost 10 times more, maybe halftime job per year, I think.

Because DNSsec demands more service management and we have to educate administrative personnel also. To run the services in 24/7 services. Some more apprehensions. We can -- as I said before, the costs for running DNS today is very small, and what we need today, we try to find good assistance tools and good management tools to administrate DNSsec, and we haven't found them yet. I hope it will come, but -- yeah, we're looking for it. So if you have some suggestions, please come to me and let me know.

Today, we're only talking about dot se, but we -- it's a little bit worried about what will happen when we have to manage several top domains in DNSsec. How will it affect us in a matter of different rules and relations, different administration tools in several different countries, different identification demands when we sign for PKI management and so on.

And the big question: Will the root domain ever be signed? I hope so. It will be good for us, too. As we can see. And let me also think a little bit about the customers, how we can inform the customer that when you're running Swedbank.se you're running on a safe line running DNSsec but running -- do you use Swedbank.com, as we have, you're running an unsafe session. And it's a little bit complicated to inform and educate customers about that. So what we would like to see is some kind of indication -- maybe in the Web browser, maybe like the locker as you have in Internet Explorer and so on.

I talked to Microsoft about this question. I was in Redmond last week and asked these questions, and the first moment they didn't understand why I should have the need for that, but I think my questions and I also know that dot SE and Staffan have asked Microsoft and now Microsoft told me last week that they will send people from Redmond to Stockholm to start talking about DNSsec with Staffan and his guys.

The last thing we have is about observant customer who understands what's different. And we have a little bit of a dilemma here what we will say to that customer. For the moment, I just don't know, but, yeah, there's some question we have. The difference between dot se and dot com, so in Sweden, from my perspective, I have the need to sign both dot se and dot com in the root.

Other considerations we think about, it's a little bit Swedish issue here, but we would like to see a strong identification when we are using the keyman, the management tool to store certificates in this environment. So some public issue or smartcard or something like that will be nice.

And then I can see increased administration when we have to sign in several international zones also.

Okay. Over to our roadmap. We are running DNSsec in test at the moment, and we have done it for one year now. We're waiting for the ISP and they have to start, and as we heard today, TeliaSonera hopefully will sign there soon, summer 2007, something like that. And my hope is that we have the Big Four ISPs in Sweden and all of them will sign for DNSsec. And as we heard today, dot se is working on it.

And from my own internal perspective, what we do in Swedbank for the moment, next week I will have a meeting with -- startup meeting with three other big banks in Sweden [saying name] and we will start discussion and synchronize our roadmap for DNSsec in Sweden. My goal is, we'd like to be -- a nice goal would be that we are -- have three or four banks signing up for DNSsec in the beginning of 2008.

Also this month, I will start up -- in April, start up an implementation project and we'll start with enabling our two test resolvers into DNSsec and we start looking for a rollout client to convert our DNS environment to DNSsec in the beginning of 2008. And then this year, we have to do some reorganization and education of the staff administrating DNSsec. So hopefully if everything goes well, we're running DNSsec in full production in 2008, I think.

So that was my picture.

>>STEVE CROCKER: Thank you. Anders rafting.

>>ANDERS RAFTING: Can you hear me? Okay. Good afternoon, everyone. I am Anders rafting, from the Swedish registry. I have -- no, not at all. From the national post and telecom agency, national post and telecom agency --

[Speaker is off microphone]

>>ANDERS RAFTING: We supervise the public electronic communication in Sweden and also the Swedish top-level domain, since last summer.

So we are -- just a brief introduction to the agency. We are 250 employees, around. Our financial model, we get charges from the operators around 25 million€ per year, and we have special money for security measures for disabled people, around 42 million€ per year. The objectives for the agency is that consumers' interests shall be in focus, the competition shall be sound and efficient, the resources shall be utilized in a good way and here we think about radio frequencies which are limited natural resource, and we -- above all, we work for secure communications.

The threatening picture we see around us is cable disruptions, loss of electrical power, we make accidents and mistakes, physical attacks, logical attacks by criminals or terrorists or a sabotager just by hackers we see every day. Insiders can do a lot, and profit interest comes first, security next. New technology can cause problems and the public economy can be a problem to make efforts to increase security. Historically, we worked with physical measures. We have built around 20 rock-sheltered underground locations for safe locations for critical infrastructure like telephone exchanges and [inaudible] exchange points. We also had initiated cooperation between suppliers of telecom and electricity which is very important when the society is attacked or under severe strains like we had a big storm a couple of years ago. It was very bad, but these guys could talk to each other and help to get everything up and running again. And regarding broadband deployment in Sweden!

, the market builds security up to a business level, and they leave the rest to us, so the dotted lines there, we are buying and deploy. We have spent a lot of money to do redundant connections in the broadband -- broadband deployment. We also make other things. We have tested is the redundance of a big IXP in Stockholm. We have made a number of training operators in crisis management. We will have a big one in May this year where we'll have a -- where Internet problem will be introduced also for the first time. We also supply with a very good clocks where atomic clocks for universal time coordinated traceable frequency, which is a very critical resource for the networks to work at all. We're dealing with IP telephony problems, especially the conveyance and localization of emergency calls, which is not standardized too far and doesn't work so far, but we have a working group on that who work with that and we'll see if they come to a result soon. We have tested the DN!

S availability together with dot se a couple years ago and recently, we have finished a test of the border gate protocol, a critical protocol that make the Internet happen at all. Connects the operators' networks, the autonomous systems together. This support will be published in a couple of weeks on our Web site.

Yes, the DNS is -- we are more and more dependent on DNS to work, that it works. And as soon as you use IP in -- voice over IP, IP-TV, session initiation protocol in the IP multimedia system that is emerging now, you will need DNS. We have -- in Sweden, we call it the 24-hour authority where you can make your return of income electronically by the Internet or you can notify illness or just retrieve information. Use the Internet and at the same time, the DNS is not safeguarded, so that's why we are interested in this issue at all as an agency. And there are incentives for deployment of DNSsec. Out there in the DNS hierarchy are lots of places where attacks can be -- can happen, and the man in the middle can attack on every connection here or intruders, and give a fraudulent answer before a correct one comes. Just listen to the DNS port, spoof the address and give a false answer, so when you eventually get an answer back, can you trust it.

So to tackle all these problems, these threatening situations, we got an assignment from the government last -- two years ago to make a strategy to improve their security for the Internet. Like Jorgen spoke about in the beginning of this session. It was approved by the government in December and it's an action plan included of 23 actions, and one of the actions is promote deployment of DNSsec.

But we think it's very important and sensible to make some stock-taking about how does DNS look in the area you want to change. I recently made an investigation, a study made by Yakov Sluter who was a member of the DNSsec deployment group found that out of 273 name servers in public sector, 120 was operated by one and the same operator. No TCP support recursion was activated in the authoritative name server, so a number of inaccuracies was found.

They also looked at the software used and found many versions that doesn't -- that don't support DNSsec. Today, I think it is BIND and NSD that has DNSsec. You must have BIND9.3.2, I think.

What we have done so far, we tested deployment of the DNSsec. We gave a task to guys that knew DNS very well but didn't know anything almost of DNSsec. We thought that was a good thing because then they must tackle the same problem that others who want to deploy DNSsec will need.

They made a test and documented every step to make -- to come to a point whether DNSsec was up and running and functioning. We set up a resolver, an authoritative name server, signed server, a mail and a Web server and tested it and it worked and took two or three weeks, I think. Everything on this is documented in the report which you can find on this link. To reach out with our experiences, we make presentation at different places and the dot se registry is conducting a big event -- two-day event every year called Internet Days. It has become very popular. Several hundred people coming there. Increasing number of participants for every year, broader representation from the society. In the beginning it was only technicians but now it is politicians and all types of people.

And there we had a seminar in February in Stockholm where all stakeholders were present and we have 90 persons, wasn't there?

This seminar is very motivational. We have met the four major operators. That's TeliaSonera (listing names) to try to convince them to introduce DNSsec in their resolvers.

And to make that happen faster, we have offered them a hundred hours of expertise support. Telesyrelsen made it themselves. Congratulations to that and we hope that our operator will accept this offer.

So we plan to do a more thorough stop taking of DNSsec in public sector for better base for DNSsec deployment. As a good example, we will -- we want to be the first public organization in Sweden or perhaps in the world to sign our zone.

So now we are just waiting for our name server operator to do that. Thank you.

>>STEVE CROCKER: Thank you.

>>DANIEL KALCHEV: That's a fantastic experience. Okay. I'm Bulgarian registry. My presentation will be shorter because my colleagues were very extensive in describing most of the issues. What I will talk about is the perspective of the (inaudible) registry, let's say you decided to start signing their zone with DNSsec. The first thing we had to do was research the current state of DNSsec. We have been following this technology since many years but it was more or less a moving target. There were several portable divisions. Some cases where it was not so easy to deploy and things like that.

We found out that there were already many tools that exist that are well-tested and easy to deploy. They are developed by several parties, more or less, independent so that you can even compare their performance.

But we also found that despite this long period of experiments, a lot of developments and a lot of published information and documentation, DNSsec is practically not used in the public Internet. There are many test labs are somehow controlled environments that employ DNSsec but it is not sort of widespread.

And we also discovered that there were many top-level domain registries that had once DNSsec initiatives and in many, many cases they have stopped the initiatives for various reasons.

In fact, there was only one TLD administrator that was just signing root zone in hope -- I believe I'm right -- that there will be good example to follow. So what we decided was that we need to evaluate the technology and resources we need and decide whether to implement DNSsec now or in some future.

The technologies available, as it was already said -- the current versions of BIND9 can be used as the name server. There are several resolvers (inaudible) already available. It is not a technology that requires significant resources, especially for small zones. And if you think on how the DNS system is built, it is actually a lot of small zones that have parents and so on.

So for deployment, it is important, let's say, the end users of our services, the people who we will call registrants are able to sign their zones easily. If they cannot do this, the technology cannot be in wide use.

The same technology can also be very scalable so you can split zones in small pieces and sign them on different hardware so this is also something that's a definite show stopper in this case.

When you sign your zones, you have to keep track of expiration times so that they don't disappear from Internet. But here, also, there are tools available that can be used. And there are some security considerations, how to protect your sensitive case. In this competitive industry, there has been a lot of development in this regard. You can use, let's say, physical security measures or you can use (inaudible) and all kinds of different solutions to protect this material.

So we had all this preliminary information on the current state of things and we had to decide whether we want to implement DNSsec now or wait for some better future when everybody will do this.

The good things in implementing DNSsec now is that we can further secure our domain. We considered this our first priority so that we can offer a service that can be trusted and DNSsec is a technology that will do just that. It will provide security for the user of the DNS system, that they get the same data that we have published as a registry or the name servers or the registrants have published for use on the Internet.

It is also a new DNS service, not widespread until now. So it creates new markets for the registry, the registrars, for all the operators that provide services to the end users. Like as it was said, this name server service providers.

We also have just introduced the new automated system last autumn. And this technology fits very well in our system. It was actually designed with implementing DNSsec in mind.

But there is some things that appears during the process and that is the root zone is not yet signed. There are some promises this will be signed in the distant future but maybe not. Let's hope.

There is actually no high demand for this technology from the users, and the main reason is probably that there are not so many applications that can make use of DNSsec, which is not something we should know. Implementing DNSsec in the world would require additional efforts on the part of people who, let's say, own domain names. They will have to find the proper Internet environment procedure to sign their zones to distribute gates, to find the proper DNS operator.

By considering all this, we decided that we should implement DNSsec first because we see as a useful service and, second, we can give an example that this is not something that is terribly difficult to do and that if there are no other reasons, everybody in the TLD community should do that.

We considered to implement DNSsec as standard DNS service of the registry. This is in contrast with the decision that the Swedish registry has made.

But only time will show which is better.

So we have means to fully integrate this delegation of signing authority in our automated system. We use digital certificates for identification of who the zone contacts are. So these are the people that will give us the trusted keys.

We have provisions that the registrants can approve who are the zone contacts and, in most cases, this will be the same people who are in the name servers, so we also, after some consideration, decided that we should not make much bigger difference between DNS records and NS records because if somebody can change your NS records, they can publish whatever information they want in your DNS zone.

In any case, as a customer, you trust this operator. You have some contracts and relationships and so on.

So we expect that this service providers will most often sign the customer zones and serve them.

We did this whole process in a relatively short time frame. We announced our interest in the DNSsec in July last year and we have signed the BG zone on 15 of January this year.

We did some extensive tests with some test zones so that we could verify in the life system all the procedures are simply adequate and that we don't have any significant errors that can stop operation.

And so we are done with this experimental stage. And for today, we have over 30 signed zones with secure delegation and we expect to have a lot more in very short time.

We actually have the promise of major university in Bulgaria that they will sign the entire RSC within DNSsec which will be interesting experience.

We have some short-term plans. The first thing is to move this automated registry to our production system so it will be visible very soon. I would say in the next weeks.

We're planning a big event like they did in Sweden, to invite all the interested stakeholders from industry, government, banks and end users so that we can tell them about all these developments, invite some comments or if we do something wrong so that we can have the chance to correct it in time and also encourage those participants to find value in deploying DNSsec.

We have project to provide sample technology and tools for those who are interested to use that so that they can use our experience and not start from scratch.

This include some kind of appliance that they can use for key management. They can use ones for signed zones and, of course, documentation.

We also have not so short-term plan but we have plans to build performance platform. We decide to offer signing the registrant zones in the registry, but this is not yet completely decided.

So these are the things I wanted to tell you, and the main message I wanted to spread was actually that DNSsec is not such dangerous thing and that we should start doing it in our everyday operation everywhere. Thank you.

>>STEVE CROCKER: Thank you. Let me thank the -- each of the speakers for a very substantive and thoughtful presentation. I think we can see that we have a very significant point along the way toward -- in the deployment process that we have. Things that are up and working, that this is out of the laboratory and involves not just the usual technical people who have been working on the specifications for years, but moved into the business and operations activity. Let me see if there's any -- I appreciate everybody hanging through this extended set of presentations. This is a good time now to begin discussions, either specific questions on specific points or more general questions for which we can get some interaction. Okay.

>>OLIVIER GUILLARD: Steve, thank you very much. Thank you for the interesting presentation. I think I'll try to rephrase the initial question in another way.

It has been said by -- I'm Olivier Guillard from the French registry, actually and I'm quite interested by the experience of my colleagues from registries, so this question will be for them.

I heard from Daniel that he was planning to to record DNS records as NS records. I heard also from the Swedish registry, I think, that you plan to hire new people to deal with the -- with the repository management, the key repository management. I'm not sure I've understood this one.

The question was to know if you planned, as a registry, to act as a key registry operator or not. If yes, why? If not, why?

>>DANIEL KALCHEV: Okay. We haven't considered yet the possibility to act a key repository, and the reason is that we didn't see this as our job, but if we get the keys anyway and considering that we have authenticated the source of these keys, we can actually be some kind of repository.

But, on the other hand, by signing the DS record in the BG zone, we are more or less approving this key. So that I would question where it is necessary for the registry to collect keys and distribute keys. The purpose for this.

We will get the keys anyway so that we can make the delegation in the zone file. But when we have the delegation, you will not -- no longer need the key for the sub-domain. You will need the key for the top-level zone only. So that's my opinion.

>>STAFFAN HAGNELL: Yes, we shall not go into any basis of doing anything other than dealing with the DS records if that's what you meant. We think it's the customer that should have the opportunity to put in keys in their zone. When it comes to certificates, we will use other parties' certificates for identification or our customers', but we will not be going into the certificate business.

>>STEVE CROCKER: Does that answer your question, Olivier?

>>OLIVIER GUILLARD: Yes.

>>STEVE CROCKER: Good. Other questions? Okay. Any comments -- Olivier, how soon are you going to have dot FR signed?

>>OLIVIER GUILLARD: Pardon?

>>STEVE CROCKER: How soon will dot FR be signed?

>>OLIVIER GUILLARD: We work on that, and there is a Web site that shows the outcome of the work if someone speaks French here, it's www.idsa.prd.fr. It was a project we've done two years ago, and it was basically focused on the technology and the deployment -- the technical deployments. There had been discussion on it, but it's still ongoing. So no answer as yet.

>>STEVE CROCKER: I like the very diplomatic answer.