Deploying DNSSEC in a territory

INTERNET GOVERNANCE FORUM 2010
SESSION 141
17 SEPTEMBER 2010
ROOM 2
DEPLOYING DNSSEC IN A TERRITORY
1130



********
Note: The following is the output of the real-time captioning taken during Fifth Meeting of the IGF, in Vilnius. Although it is largely accurate, in some cases it may be 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.
********



>> JAMES GALVIN:  Is it okay if we get started while you continue to set up?

>> Yes, please.

>> JAMES GALVIN:  Welcome, this the deploying DNSSEC in a territory.  I'm James Galvin.  But as moderator today, I'm representing the ICANN's Security and Stability Advisory Committee.  SSAC is a committee, started back in 2001.  It advises, produces documents, advises the ICANN board and community and the Internet at large.  We produce documents on a broad range of topics related to the Internet security and stability issues, as well as focusing on Domain Name System, and of course number allocation, which is a part of ICANN's role.  
In that spirit, ICANN wanted to take on a role of facilitating the deployment of DNSSEC.  And we started several years ago, at least three years ago, and one of the actions that we took at that time was to have workshops at ICANN meetings.  We have been having those typically on a Wednesday.  They are an all morning thing.  Up to that point, the workshops were about what plans people had.  Or had they deployed DNSSEC, they came and talked about their experiences and what they have done.  The documents that SSAC produce -- it's just an advisory committee.  Part of its role in producing its advice and recommendation, it produces documents that stand on their own merit.  SSAC has no enforcement mechanism.  It has no way to tell people that this is what they should do, except that it creates a document and advice.  And that advice is supported by our own technical judgment and it just stands on its own merits.  So in this role, this is about getting people in a room, providing that advice to a broad community of people.  
Last year, we started looking for outreach opportunities, and one of those opportunities is at the IGF, and so we had a forum last year on protecting domain names.  And this year with the signing of the root, having it completed in July, and the number of TLDs expected to be signed by the end of the year should tip over 40, we are beginning to reach a critical mass in the opportunity for DNSSEC.  So it seemed like a good time to have a forum here on deploying DNSSEC.  
This is a workshop.  We are looking for participation from the audience.  And we hope that you have questions or anything related to DNSSEC or anything that you want answered.  We have a stellar group of people here to speak to your questions and give you their perspective on their experience and what happened.  Everyone here has been directly involved in the deployment of DNSSEC in one form or another.  And we have a broad range of experiences.  
So, by way of introduction to the session, DNSSEC was originally started back in 1993.  And it was created with the principle purpose of providing protection for a man in the middle attacks in the DNS.  I know this because at the time I was the Chair of that technical working group for the eight years of its existence.  And the first three iterations of the DNSSEC protocol specification.  At the time I was at a different employer, and we also produced the first public domain implementation of DNSSEC.  So I've been around DNSSEC for a very longtime.  I'm one of the few people -- perhaps the only person right now in this room -- who has been around it that long; almost 20 years.  
The DNS has evolved a lot in that time.  If you think back, the Internet as we know it today didn't exist back then.  It wasn't the Web as we know it today.  Beginning really in the mid '90s, '95, '96, HTML came around in '3, '94.  And that's when we had the dot com bubble.  And the Internet as we know it today began to come into existence.  So we had an evolutionary step in the Internet.  
So though DNSSEC had a basis in wanting to solve a technical problem, I think we have come a long way since that time, and it's time to reposition DNSSEC as a critical infrastructure protocol.  So one of the reasons why when proposing this session I put it in the critical infrastructure track, DNS is an integral part of the Internet as we know it today.  It's evidenced by two things.
One, we generally don't think about it.  And I think that for anything which is the foundation of all things, that happens.  The fact that you don't have to worry about it and don't think about it, and it just works, is evidence of its critical role in the operation.  
I suspect that very few people would use an IP address when they try to do anything on the Internet.  Whether they are browsing or doing anything on the Internet, you'll use a domain name, which means you're always interacting with the DNS, whether you realise it or not.  And that's the point.  DNSSEC is an opportunity for the next evolution, the next evolutionary step in the Internet.  It's an opportunity to provide the foundation for a new secure, a new safe Internet for everyone, beginning with DNSSEC so you can get certain guarantees about the site that you're going to, the service that you're trying to communicate with, and in fact the innovation that is going to come from it.  
A lot of discussion at this meeting about security, about the need for security not to get in the way of the Internet as it has progressed to date.
And net neutrality is another favorite topic, and an important topic at this meeting, as well as general access to the Internet.  We need DNSSEC for the future.  We need it for the next step of what the Internet will become moving forward.  
So one extra point to make in all of that is that if you're not making plans for DNSSEC, it's important to realise and accept that you're behind the curve.  We are approaching critical mass, given that we will have over 40 TLDs signed.  We will have .Com next year and that brings the lion's share of domains under management, almost 50 percent.  So the opportunity will be there for most people to be able to sign.  And we should begin to see a new generation of security activities based on a secure DNS.  
It's true that DNSSEC requires preparation.  And I think that is a fair thing to say about any new technology.  It's still relatively new, in spite of the fact that it's been around for a while.  We have a lot of experience now.  The early adopters have a lot that they offer about the things that happened.  There is a fair amount of free software out there, for those who want to engage in the deployment of DNSSEC on their own.  There are a number of service providers who have services to offer to facilitate your deployment of DNSSEC.  Like any new technology, it requires preparation, ongoing management, which means it requires new skills.  It's simply another step in any kind of new deployment.  So, if you're not prepared for advancing your own staff, your own service providers, then you need to look for those service providers who have it, to help you and to facilitate your deployment of DNSSEC.  
We have a group group of panelists for our session today.  I'll start at the top of the DNS tree and work down through there, starting at the root.  
I have Dmitry Burkov here on my left, the first person on your left, next to me.  We will talk to a root server operators, we will hear experience about signing the root.  
We have a number of TLDs with us, one remote participant, Peter Janssen will join us and he will say a few words about their experience.  They were a recent deployment of DNSSEC.  
And then finally, we have the Internet society here, and Sebastian Bellagamba will talk to us about the user experience.  They had the distinct honour of being the first -- well, I won't spoil his opportunity to say that for himself.  
I will also, as a representative stepping away from moderator for a moment as we go down through this, I'll step back in the middle and give experiences from our side, Afilias, as a registry services operator.  So we have a lot of experience in deploying DNSSEC 2.  We are in the process of deploying it in all of the TLDs that we host, and I'll have a few words to say about our experience and an opportunity for you to gain from that.  
The next speaker -- one last thing.  This is a workshop.  It's intended to be participatory.  I really am hopeful that folks will have questions, that you want to step up and ask questions of the panelists here.  I have a few seed questions to get us started, but I do expect that the lion's share of this workshop will come from you, and our panelists are here and ready and able to answer your questions.  
With that, I'll move on and pass off to Dmitry Burkov.  And he will speak to you about being a trusted community representative.  

>> DMITRY BURKOV:  Thank you, James.  Please.  
My name is Dmitry Burkov.  My experience is as a community representative.  
You can learn from the slide, if you worry about global warming, ask me.  
What is important?  My understanding, a new process was added to the management.  This new technology process, we still need to keep the trust that we have had for more than 20 years to the root.  And it's the first time, the first time to be a community representative and we began to participate in the DNS management.  
I want to show you the final geographical distribution of the representatives by regions.  Initially, you can see the numbers who applied.  These numbers were represented at a meeting in Prague.  And final distribution, I think it's a good representations of distribution among regions.  
Who we are.  I don't want to read all of these names.  You can easily find them on the Web.  It's not a secret.  It's open information.  
I want to mention the guys from ICANN, Dennis, who did a great job in a short time for preparing all processes, and put these process ceremonies in action.  The first ceremony was a KSK signing ceremony in June in Culpeper.  The second one was in Los Angeles and the third one will be in Culpeper again.  
The process is still a draft.  It's still under investigation.  It's not a dogma.  And we tried to improve and make some revisions after the ceremony.  They are still minor.  The most important point, because we are not some specific area as key holders, we are supervisors of this process.  What is important?  It's a good point.  And from this point of view, the key advantage and the key goal is to keep trust.  
For me, I want to express that for me it's a great advantage.  The first time we -- it's a joint work from people around the world.  And the hope is that -- it's the first step, that we can improve trust with management and escape all of these discussions regarding this as an untrusted critical resource.  I hope that the processes can give us a chance to discuss during the next year, where we can change the current root management process and to add more supervisors, to improve the trust from different governments, from the community.  I think it's possible.  That may be one of the key points from my experience in participation of this process.  
What I really worry, it's -- what is the potential issue which can -- maybe will not allow us to do this?  If you try to scale it up to 10,000 TLDs, it will be impossible.  And I still worry that full automation of root management can be a danger, potentially full of danger.  Because, really, for me, it's an issue.  Can I believe in such a thing as sky net?  Anyway, you can find more information on the sites.  And you can see that all of us are real persons.  
This is the team who participated on the case ceremony in Los Angeles, also, Ondrej Filip also participated.  The process is open.  And in principle, witnesses can be invited, independent from their role in this process.  
Thank you.  

>> JAMES GALVIN:  Thank you, Dmitry.  One of the things that I want to observe about the root signing and that whole process is it's important to keep in mind that ICANN, along with Verisign and NTIA, as the keepers of the top of the chain of trust, probably the single most important point in the DNS hierarchy, they chose a very high end process and procedures in order to manage the root signing.  And they tried to be as open and transparent as possible.  As Dmitry said, you see from the picture, they had a whole community to manage the process.  It's an excellent example of what is possible if this level of security is really important to you.  I suspect that for most people, they need something, you know, maybe a step down or two, maybe more in some cases for what the root did for its signing.
But I think it's useful, if you're looking for a good example of what kinds of things you can do, it's useful for you to look at that as you think about your own risk situation and the vulnerability that you have, and the protections that you need, look at what the root did and check out that Web site, as he has the link here, root-dnssec.org.  It's all documented.  It's all there.  It's all open.  So it's a good example of one way to do things when you are looking for a high security operation.  
With that, let me move now on to the root server operators.  Now we have the root.  We have the chain of trust.  We have the root zone file being distributed.  Obviously the next step in the chain is for that root zone as a signed element and a signed component to be available to the community in order to begin validating sign delegations.  And Nurani Nimpunpo will talk to us about the root servers.  And you can start and I'll bring your slides up.  

>> NURANI NIMPUNO:  Good morning.  Everyone.  Can you hear me?  No.  Yes.  
Okay.  Good morning.  I'm Nurani Nimpunpo.  I work for Net Node Autonomic.  We are based in Sweden.  One of the roles we have is an operator of one of the root servers.  There are 12 organisations operating 13 of the logical root servers in the world.  And I represent irootservice.net.  So to start, I should clarify that Matt Larson from Verisign from ICANN gave me the presentation slides that they gave at the IETF in July this year, showing some of the statistics that they collected from the root server, before, during and after the signing of the root.  I don't speak on behalf of Verisign or ICANN.  I can only speak on behalf of iRoot and I don't speak on behalf of all of the root server operators.  We all operate in different ways.      I've been asked to show the statistics with the traffic on the root server during this period of time.  This is data collected by -- we have just collected and sent in the data. He has done the hard work and I get to sit here and present.  
All the data is in IROC.  And all that data is available for members of IROC.  And the data will be saved for ten years.  There is a lot of interesting analysis and observations in there.  
So just before I start to show you the statistics, I thought I would do a little recap.  I'm not sure of how many of you are familiar with how this happened.  But so the way the process was designed was that they designed an incremental roll out of the signed root.  Not all root servers went live at the same date.  So we had groups of root servers going live at different dates.  It was all planned in advance.  
And a way of doing this was through the what we called the DURZ, deliberately unvalidated root zone.  It was a way of pretend signing them all, but having the keys obscured.  And you could see the effects of the signing of the root.  And then on July 15, all the keys became unobscured.  
So, the slides that I'll show is from this presentation that was up there.  IETF, it was given there a couple months ago.  And there were nine separate data collection events.  Usually there were 48 hours for each root server, 28 hours before and 24 hours after.  And there was about 20 terabyte of data collected.  So this is all archived for ten years.  All the root servers were asked to participate and to send in data.  
So there is a colorful graph.  It shows the root servers.  You can see all the letters there on the right-hand side.  So that is all the letters of all the root servers that participated.  
And it also gives you a bit of a sense of how the query root varies, both over time but also between the root server, and you can also see that, you see the bottom there, you can see, it says preDURZ, et cetera, so this is when each root server or group came onboard in the DURZ phase.  Some of the letters go together.  So it also shows that there is actually no change in the UDP query pattern during the signing.  
I should clarify that there were some anomalies.  The data set is not complete.  If you see I, which is the light blue there, the dot net that I represent, there was data missing there.  At the time that data had not been sent in.  So the data set that they have now would be more complete.  There was a slight increase for the F root and we don't actually know Why.  So there is some data missing and some data that we have not fully analyzed.  
So the next slide.  So this is the data that J root shared with us.  The J root is the operation by Verisign.  They collected data before and after.  And if you see the great part in the middle, that was actually during the signing phase.  
So, as you know, the message size increases with DNSSEC so that was a predicted increase that we all knew would happen.  But it was interesting to see it like this clearly on the slide.  You can see the deployment window there.  I don't know if it says it there.  That is what it happened.  That is the signed root with obscured keys.  All this shows is that DNSSEC makes things larger.  
Okay.  So this very colorful chart is complicated for you to interpret, if you're not a statistics geeks.  But it shows -- the idea is to show the TCP query rate as a percentage of the UDP queries.  Basically, as you maybe know, is that with the DNSSEC deployment, you expect to see an increased query rate.  Since the responses are larger, you might not fit into the lightweight UDP packet and it does a full back on TCP and resends the query using TCP.  So it's interesting, you can see, for example, if you look at the second chart there, if you start with a preDURZ there, all the little roots and lines are down there at the bottom.  The first one you see L, which is the purple line jump up, and I think A is the red one that leaps up on the third section there.  And then I and M comes onboard, they all increase in TCP.
In terms of TCP query rate, if you look at this, it might look dramatic, but as you can see it maxes out at 0.6 percent of UDP query. It's less than 1 percent of UDP query rate.  On the larger scale of things, it's still very, very small.  
Again, there are anomalies in there.  There was a funny dip there.  If you can see, it says JDURZ and post DURZ.  And when Duane looked at that closer, he saw that that was caused by cox.net in the U.S. And when he contacted them and asked them to stop, you saw that dramatic dip.  
We see similar things, for example, there is a network in Japan that sends a lot of queries to a site in Bangkok.  It shows that one server can mess up the data for everyone.  
There are other things in there, Y, for example, A, the red line there, why the TCP query rate went up during the validating phase.  We don't know exactly why.  And H, it doesn't receive a lot of queries.  We don't know exactly why, either.  
I think we skipped a slide, did we?  Can you go back  up?  Yes.  Well, this just shows the total TCP query rate.  
It shows the same thing as the previous slide, but in total data for TCP queries.  
The next slide.  Again, this just shows the DNSSEC query types for A root.  This is not representative of all of the root servers, but you see similar graphs for all of the root servers.  
You see the DNSSEC key increase.  That's the red line.  That seems to be due to two things:  The recent signing of dot op at the time.  This was on the 24th of March.  And then there was a root signing key role causing some TCP fallback, what I expected before, with repeated querying in TCP.  
I don't know -- yes.  I don't know if this might be a bit too detailed for some of you.  So I'll move on.  
This one, on the other hand, is quite interesting.  It shows the DNS queries by TLD.  I think -- this is in a very limited period of time.  So it's there in July.  So, I think if you look at this data today, it probably has changed.  What is interesting, for example, is -- well, you see dot CZ that my colleague here to the left operates.  And what is interesting to see is that dot SC.  Since that was the first TLD to sign, maybe it's simply that there are more resolvers asking DNS queries.  It's just a guess.  But all of the data will be interesting to analyze over time and to see the changes in it as we progress and as more TLDs come onboard.  
And that was it.  I should say I'm happy to take any questions.  If you go to the very last one, there is an e-mail address there.  [email protected].  They are the ones who do all the interesting data collection and analysis.  

>> JAMES GALVIN:  Thank you.  I want to ask that we just hold questions and things to the end.  I should say that I had asked for this presentation.  I think that there are two things that I would like you to take away from all of these statistics.  One is at some level, the signing of the root was a nonevent.  I mean, it happened, and everything kept working.  They had a detailed plan over the course of six months in rolling it out.  It worked.  It did not seem to in any way take away from the normal operation of things.  I think that is evidenced by -- people would notice.  If the root wasn't working, that generally stands out pretty quickly.  Nothing happened.  And what is important here is looking at the statistics.  I wanted these things part of the record here of this meeting, so you would have a place to get back and get them.
They are various in various technical forms, too.  If you don't feel that you're the person who needs to see these things, you can point your other staff people to look at them.  
There was a change and that's important to understand about DNSSEC.  Your operation will change.  It's not just a new skill set.  You need preparations and other things to plan for.  And they did not only an excellent job in rolling out DNSSEC B in an uneventful way, but they kept track of it and they took notice and they had a lot to say about what things looked like before and after.  And it's useful to take note, because the general principles of what they saw will apply to your operations, even if the specifics don't.  And it's useful to compare you to that.  
We have three TLDs that will give us their thoughts.  I'd like to move to our remote participant.  I want to start with him, Peter Janssen, who represents dot EU.  The advantage, this was kind of a last minute addition to the panel.  And I'm very pleased to be able to have him here to present their experiences.  Dot EU is a recent addition to the DNSSEC signed family, having just signed just a couple weeks ago.  So if we're ready in the back.  Peter, if you can hear me.  
We're not hearing Peter.

>> Hold on one second.  

>> PETER JANSSEN:  Good morning.  I hope everybody can hear me.  We have a slight lag on the audio.  I hope that you can all hear me.  

>> JAMES GALVIN:  Yes, we can.  Go ahead, please.  

>> PETER JANSSEN:  The transcript came in, so I have good faith that the audio is getting to you.  
My apologies for not being there in person.  So I'll try to use this spiffy technology.  
Now I'm getting my own audio back, so I killed just my audio.  
I would like to give you a quick overview of what dot EU did to roll out of DNSSEC.  And there are actually two aspects.  The operational aspect, which is just the DNSSEC infrastructure.  And the other aspect was the registration system.  If you look at the operational part, what we did in preparation for the DNSSEC was just to have more memory, more CPU, more of everything just to anticipate.  And we made sure that our (Off microphone.) And then we opted for the -- as the way that we do DNSSEC.  
The registration system, we upgraded our registration system.  Added functionality to add DNSSEC with their registrations.  We had opted for (Off microphone.) Or via the secure Web site as well.  
Once that is done, that is the link between the registration system and the operational aspects of DNS.  And then we opted to go out and test the servers that were put in place to see that everything was fine.  We would go out and look at the main servers of the registrar to see that the material was there.  And then we would do what we call the updates.  And the domain name would be added in realtime (Off microphone.)
If you look at the roll out, we upgraded our registration system and we put it in live June 9.  At that moment we were setting DNS key material from the registrars.  Since the 2nd of September, so not too long ago, actually, our DNS key material (Off microphone.) We had a few months where we had a rollover.  We (Off microphone.) every four weeks, so we had exercises to make sure that everything went fine.  All in all, in a few months since we started accepting the key material from the registrar, we went live (Off microphone.) We had issues, especially during the rollover that we noticed it was doing strange things.  
Other things, we looked at the signing modules.  For a moment we had our key material just sitting on servers.  To be a bit more secure what we are looking to go do is with the (Off microphone.) Just like (Off microphone.) And then there is a big, rather a big issue with domain name transfers.  What happens with the key material and how does this work?  So there are some things there.  
Almost everybody in the TLD world has not had an issue.  We are looking at it and we are trying to find a way to make it (Off microphone.) That is a five-minute overview of what we have done for DNSSEC.  Thank you.  

>> JAMES GALVIN:  Thank you, Peter, and thank you for making time to participate with us.  
Let me move on next to Alexa Raad from PIR, representing the dot org TLD.  Alexa over to you.  

>> ALEXA RAAD:  Thank you Jim.  I'm Alexa Raad, of dot org, the public interest registry.  Our experience was a little bit different, because we were the first global top level, generic Top Level Domain to implement DNSSEC.  We owed a huge debt of gratitude to folks like NICSE who implemented DNSSEC.  We had planned DNSSEC implementation for a long time, back in 2008, when we first submitted the RSTEP process.  We had to deal with a number of different questions from SSAC regarding DNSSEC implementation.  At that time, this was before  the Kaminski attack.  A lot of issues were resolved in terms of the need for DNSSEC in June of that year, when the Kaminski bug was made public.  It showed the real need for DNSSEC to prevent  -- was the only way to prevent man in the middle attacks.
As I said, our experience was different because, A, we had to establish the need for implementing DNSSEC on a gTLD.  Second, the root wasn't signed.  So it was a question of a number of parties having to make preparations for DNSSEC implementation.  
One of the things that we did, which I think is applicable to practically everyone, is do a risk assessment study.  Afilias is our back end provider, and they did all the operational work for DNSSEC implementation.  
We also engaged some consultants to look at the implementation and the implementation roadmap that we had.  And that was extremely helpful.  
That said, the next iteration really was getting the channel, the registrars, to participate.  Part of that, obviously, was how are we going to create, if you will, a manual, a roadmap for the implementation of DNSSEC.  One of the things we quickly realised was -- assuming that more and more TLDs would implement DNSSEC, we essentially in many cases share the same registrars.  So to the extent that we don't make the implementation very different from one TLD to another, it would help the entire community.
So that started a group, if you will, called the DNSSEC coalition, which eventually not only included some initial registrars, like names beyond and DINEDNS, but also organisations such as ICANN, application providers, you know, as well as Shinkura, Sparta and others.  We got together to look at how do we create a set of rules for the implementation, but also encourage adoption across the chain.  Because without -- remember, again at that time, the root wasn't signed.  There were some ccTLDs who announced a DNSSEC, but without a systematic way of adoption across, DNSSEC would remain essentially an interesting engineering idea.  
So, because of the work of a lot of volunteers on the DNSSEC coalition, we have now been able to establish some rules and processes which are instrumental, such as a transfer between a registrar that does support DNSSEC, to a registrar that does not support DNSSEC.  So what should happen?
We have also been able to create a registrar manual, if you will, that is really shared with the community.  So, that enables any ccTLD who wants to make it very easy for their registrars to be able to take that and not have to really start from scratch.  And that also included a lot of the rules that have been worked out with the community.  
To give you some update on the progress, we have GODADDY, which is the largest registrar in the world, has announced in June of this year in Brussels that they were implementing DNSSEC.  They have about 43 million registrations.  We have about 29 registrars that have already -- that are already in the pipeline in terms of implementation.  That represents, you know, again, almost all of the top registrars in the world.  
So, how do we measure, you know, the DNSSEC take up?  It's important not just to look at how many Top Level Domains have implemented DNSSEC, but rather how many names are registered?  And that is still small.  So within dot org.  It is still less than 1 percent of the names are fully deployed with DNSSEC.  
So, this again underlines the need that it's not just the Top Level Domains, but rather cooperation with application providers -- many of the folks that are here -- to be able to ensure that the message gets out that it is implemented across the chain.  And furthermore that the actual customer has a reason why they ought to ask for DNSSEC or the security that it provides.  
I also believe that we haven't seen yet the killer application for DNSSEC.  
What we know right now is that it prevents a very, very unique type of flaw or security attack, that is essentially a flaw for the DNS.  Because of the compromises made between scalability and security.  
I believe that if adoption continues, we are going to see some applications, for example, Kaminski talked for a while about secure e-mail.  But I believe that there is a lot more that will give rise.  And that should push adoption the other way.  In other words, from the consumers asking their registrars to support it.  
Thank you.  

>> JAMES GALVIN:  Thank you, Alexa.  I wanted to add one thing.  You did comment about dot org being the first TLD to see.  But you're still to date the largest TLD.  And still currently the largest with over 8 and a half million registrations.  So I think that is a significant point too.  

>> ALEXA RAAD:  Thank you, Jim.  

>> JAMES GALVIN:  Moving to to the last TLD, we have Ondrej Filip from the Czech Republic.  Let me turn it over to you.  

>> ONDREJ FILIP:  My name is Ondrej Filip.  I'm from the Czech Republic.  And I was probably invited to this panel to explain what has happened in the Czech Republic, how it is possible that we have more than 100,000 signed domain names, which is not just the highest participation rate, but it's more prominent than all the other countries together and TLDs together.  So that is unique and I want to talk a bit about how we spread the knowledge about DNSSEC among the end-users, and what we did to educate all the targeted groups in the whole game.  
So first of all, we started DNSSEC early.  We started in September 2008.  It was just a few weeks after Kaminski attack was published.  So it was quite a good answer to the problem that appeared at that time.  
At that time we had a lot of complaints, a lot of -- there was a lot of discussion about DNSSEC, and we heard that there was no business case, that registrars don't want it, that registrants don't want it, it's too expensive, too complicated.  And in a lot of discussions, we faced some chicken and egg problems.  And we are not very satisfied with that situation and we decided that somebody has to start it.  And it must be done by a registrar, because there is no one else with the knowledge and power to start the whole process.  We also thought that the security was not a special service.  We thought it's a feature.  So it must be included naturally in the domain name registration process.  And we understood that we cannot just be allowed, that we had to find allies in that game, and we identified like four, maybe five different groups, which were ISPs, registrars, content providers and users, and sometimes government or state agencies play a special role in this process.  
First of all, we started communication with the registrars.  It's a well identified group and we know all of them.  That's a great advantage of a smaller country TLD.  
And we started a series of seminars and trainings to educate them on what they can do to implement DNSSEC.  How complicated it is.  
Another thing we did for them, we set very nice conditions.  First, we didn't ask for any fee for DNSSEC.  So we started it with a different way than some other registries.  More than that, we started to make some incentives for them to make DNSSEC.  One of them is that if the registrar is signing domains and has a large number of signed domains, it gets more money for co-marketing programmes, that is the money that we usually -- well, it's a programme that we play some part of the campaign that the registrars do in Domain name selling.  So the registrars that do sign domains, they get more money from the programme.  So they they were motivated to sign domains.  
And also, we made some technical changes in the EPP protocol to help them to make a bulk signing of domains.  It means that in all registries, if they sign 20,000 domains, and they are set up the same way in terms of the DNSSEC, they just put one item into a database so they don't have to heavily communicate with the registry system.  In the case of other problems, it just always changes just one item in the database, so it's very easy and they can quickly react to anything that happens.  
And another thing was we started the end-user education.  We tried to increase the technology.  We had something called good domain and it was funny videos of a guy look like an IT crowd, explaining what is good and how great is a registered domain and what is DNSSEC technologies.  We got support from the government because the official domain, which was U 2009 was signed, and we made a lot of publicity that it was signed.  The first one that was signed.  
But we also tried to deal with the fact that DNSSEC is invisible for the end users.  So we tried to find a way of how to visualize DNSSEC for them.  They sign the domains, and nothing happens.  It's invisible for them.  So, in our laboratories, we made two products for them.  First one was a DNSSEC validator, which was a plug in for a browser which you can see if the domain is signed and if your servers do support validation.  So there is like, similar to the HTTPS and HTTH distinction, there is a key which is green or yellow, for example, that if you do not validate or if you see that there is something very bad in the DNSSEC.  And the plug in has been very popular and we have a lot of downloads every day.  And it's used now by many users around the world.
And the second thing was a DNSSEC hardware testing.  It's a little bit more farther looking thing, because currently in most DNSSEC deployments, the validation is the part that is just on the ISP side.  There is no validation or verification on the end users' side.  And we wanted to prepare our end-users of such a situation.  So we made a test.  See if their equipment at home is compatible with DNSSEC.  So if they want to verify it at home if that is going to work, it's over there and you can see if it's ready.  
And suddenly, it happened, some of the registrars started to sign domains for the end-users.  They took it as a marketing advantage.  So they started -- DNSSEC appeared in marketing and on billboards in the country, and so on, which is I guess very unique.  And now a lot of end users ask their registrars for DNSSEC, because they understand it's a part of the domain.  And that's the stage we are.  We have 201 domains out of 70.  And out of that, there are a lot of important Web sites, like newspapers, banks, that do support DNSSEC.  And that's the main goal.  
But those are a lot of important institutions started to use DNSSEC.  And that's -- that's the goal we had in the beginning.  Of course, it's a continuing process.  And we hope we will grow that number farther.  
So that's all from my side.  Thank you.  

>> JAMES GALVIN:  Thank you Ondrej.  I should go back and offer apologies from Dmitry.  It is the last day of the conference, and like many people, he had to make early arrangements to get out.  And so he was here for the beginning, but he is not here for the end.  And Ondrej will apologize in advance.  You are going to duck out early.  So he is here for most of the session, but he needs to leave before the end.  But I appreciate, I'll say for Dmitry but also for Ondrej, to take the time to be part of this as much as they can be.  
I want to jump in here and speak from the point of view of a registry services provider and offer comments about experiences that we have had.  One of the common threads in all three of the presentations that we have had here is the need to educate registrars in particular.  For those TLDs that have registrars, they are an important middle man in the process.  They got between the ones who want to sign and the industries who have to support DNSSEC information.  Without that and without every one of those parts doing what they need to do, deploying DNSSEC, signing the zone, getting the information into the DNS, validation cannot occur.  So that is a critical piece of what we need.  We have, in doing all of the signing of the DNSSEC work that we have done, boiled this down to three what I call actionable principles which apply at all parts of the tree, things for you to care about, as part of your education process.  These are three things that you should know about.  Either they are things that you have to do if you are the registry or registrar or they are things that you need to know about as a registrant.  Things you have to ask.  
So the first one is that you need to be able to unsign your domain.  This is just based on the fact that we are still not quite at critical mass in the deployment of DNSSEC.  A registrant may, for any number of reasons, want to change registrars, and in order to be able to do that, if you want to move from a registrar that doesn't support DNS -- if you want to move from a registrar who does support DNSSEC to one that does not, you have to be able to unsign your zone.  We would like to think that no one will want to do this, but as Alexa pointed out, we have 29 registrars today.  We are getting more weekly coming onboard to support DNSSEC.  But there are, you know, several hundred going up actually to almost a thousand that are out there and available.  So, there is quite a few more that we have to get to before we had significant critical mass and we need to sign to support the system as it works today.
So that is an important question to ask.  
As a registry, as a TLD, you know, do you care about this feature?  You probably should, and so you need to do what you can to get your registrars, insofar as you have them, to ensure that they offer that feature.  Registrants, as you choose a registrar or before you sign the first time, you need to give due consideration to the fact that you might need to move.  
The second thing that you need to be able to do is import and export your public key information.  Alexa mentioned that godaddy offers DNS services.  They are doing a phased approach to deploying DNSSEC.  Their Phase I is to support only the import and export of your public key information.  So they are doing their part to interact with the registry.  They are doing this part to let registrants who want to sign be able to do that.  And they are setting themselves up to get out of the way.  You can use a third-party service for your DNS operations.  If you want to sign DNS, since godaddy doesn't support that directly themselves, you can find a separate service provider.      More importantly, if you are someone with a domain and you have your own DNS service provider, you may have your own services, or you may use a managed DNS service somewhere, you're going to want a registrar. And you'll need a mechanism by which you can get your public key information into the system.  So this is a feature that you would want to have with your registrar.  This is a feature you would want your registry, your TLD, to ensure and make available to you as a registrant.  That way you have the best set of choices you can make.  You're not restricted in who can do your DNS operations.  So this is a very important -- important feature to have.  It's a low cost feature for registrars.      People like to focus -- there is a lot of development, again as a new technology, new skill set, new things that you have to do, as a registrar, this is a fairly low cost opportunity to get into the DNSSEC space, at least support those people who have DNS service from a third-party, and that way you have them as participants in what you're doing, you maintain that customer and you keep them.
The first actionable principle that applies to this DNSSEC system, and this goes back to something which a number of people, several of the folks mentioned, is transfers.  Now, when they say transfers, they are talking about the transfer of registration.  The actionable principle here to keep in mind is to separate registration services from DNS services.  One of the things that DNSSEC highlighted in the overall DNS system is it called out a new player, which has never been a visible or integral part of the domain registration system, and that is your DNS operator, the person who does the actual signing of your zone.  That person, that participant, is now an integral part of the process.  And they have a role to play in registration transfers.  They are now a visible part of it.
What is interesting about that, ICANN is the coordinator of the Domain Name System and number allocation systems for the Internet.  DNS operators are not an integral part of that community.  They do -- they are now, and they need to be, because they are the folks that would do your signing.  So your public key information comes from those people and you have to take it from your DNS signer and get it into the system through your registrar.  So that third principle is probably the most important of those three, recognizing the fact that you have to separate those things.  What happened here -- what happens here is transfers -- registration transfers are not directly affected.  There has been no change to the system there and no changes that are needed.  But there is coordination needed between your DNS and registration services.
That is the critical step that is new.  If you want to move your DNS service, it's that transfer operation that matters.  That transfer operation needs to be very carefully coordinated.  There is a well-defined set of steps that one needs to follow in order to make that work.  
And one of the key features that you need for those steps is the ability to import and export your own public key information from both your DNS operator and your registrar.  
So quickly, three actionable steps.  Importing and exporting your public key, being able to unsign your zone, and being able to separate your DNS operations from your registration operations.  And those apply to all parts of the system.  Those questions apply to you.  You need to consider what they mean to you, either they are questions that you want to ask because you want that feature or there are implementation features that you need to deal with.  
Moving on to the last speaker and moving down the chain, we have a representative from the user community who will tell us about what it's like for a user to sign their domain and what it means.  Sorry, Sebastian Bellagamba.  

>> SEBASTIAN BELLAGAMBA:  I'm Sebastian Bellagamba.  I'm the regional manager for Latin America.  And when Jim asked me to provide the user perspective, I kept thinking what is the user in this chain?  And I realise that there are several users.  And I'll try to address quickly, because my colleagues here addressed many things on the subject.  I realised that I can briefly make some comments out of three different perspectives.  One is the Internet society as a domain holder user and our experience on how we implemented the DNSSEC.  I'll tell you that as the dot org was the first in gTLD to implement the DNSSEC, we were the first domain under the dot org to implement it.  
And two other big groups that I came along with, which would be the domain holders in general and the other one is the general audience that uses the Internet every day.      Is the implementation of DNSSEC going to change the experience of the Internet?  Is it going to change the users life in a certain way?
I would say, in certain -- for certain aspects of what we know out of the Internet today, yes.  
I don't know how many of you are, well, knowledgeable on what DNSSEC actually does.  Because I don't know if it's been introduced in other presentations.  
Is there -- there is knowledge in the audience of what DNSSEC does?  Yes?  No?  Okay.  
You can secure -- you can secure -- DNS, basically, and I'm not a technical person, but basically what we're talking about is that the DNS, what it does, basically, is translates the domain name into its corresponding IP address.  Is that correct?  What we are talking about DNSSEC is a way of, through cryptographic signature, ensuring that the DNS is -- that what the DNS is translating is the right one.  It's more complex, but for general knowledge I think that will suffice.  
And so a way of using it as a domain holder or as an end-user, and that -- I think that would be the question -- thank you very much.  
If we discover the killer application, Alexa mentioned about this, or -- I think there is a need to understand why we need this feature to be on the Internet in general and the DNS in general, just to realise how the application of the feature will be.  
We should -- I mean, in my perspective, we should start using it basically because it adds a level of security to the use of the Internet.  We have some things that are covert, but this implementation is covering another feature that we will not cover with the features we have already in place.  
Basically, the DNS, we need the DNS to function efficiently, effectively and correctly.  Otherwise, it wouldn't do what we intend to do on the Internet.  If you want to be able to ensure that you have an authentic address, IP address, for www whatever, dot com, you need to implement DNSSEC.  And you need to implement, if getting the right address for that is the one that is at www whatever dot com, you are getting the address that dot whatever wanted you to have.  
So some things so far, you can operate certain scams on the Internet.  The application of the Kaminski, basically, it's that we can as a user be scanned out of the Internet if people do it in a malicious way.  We cannot prevent phishing in a certain way, because phishing is more of a social scam.  I mean, you get fooled by clicking the incorrect URL or the incorrect link that leads to a URL that is not leading to the one that you think it is leading.  But you can have today the situation in which we're -- you write down in your browser the address for your bank, and if the DNS for your access provider has been fooled, you might be directed to another place that is not exactly your bank as you intended to go.  That would be prevented if your bank, your access provider, everyone else in the chain implemented DNSSEC.  
So it seems good to implement it.  It seems that we are making it more -- the Internet more secure.  
How to implement it?  Implementation of DNSSEC has been addressed before.  I'll not go into further detail.  But pick the right provider.  That would be the key.  I mean, your registrar should be the one that will make in a certain way your life easy to implement, implement DNSSEC for your domain name, if you're a domain name holder.  
Just to mention our own implementation at the Internet society, we have our good registrar.  We have a nice phone line, direct line to the registry.  And the one that manages, tech calling, technically the technical operations of the registry that we're under, but even though we screwed it up when we implemented the DNSSEC in our domain name.  Basically, we misstyped.  So, choose the right provider, try not to misstype the key, and that would be my two pieces of advice.  
There are a lot of things that you can do today.  It's been mentioned already, it's not wide, wide, widespread, but DNSSEC is there.  There are several TLDs that are already providing the feature.  There are several registrars at least are publicly available.  So I'll not go into that.  And if you have the right provider, you can implement DNSSEC today.  The features are good.  There is some workload that is mentioned by Jim before in running your own DNSSEC operation, but it pays.  So my advice, go ahead and implement it.  
Thank you very much.  

>> JAMES GALVIN:  Thank you, Sebastian.  Let me clarify one thing that you said, since I was there at time when it happened.  When Data work launched signed delegations in June during the Brussels ICANN meeting, the Internet Society was the first dot org domain to sign through a complete system.  As a user from beginning to end.  I mean, there were other zones that had already been signed, because we had the friends and family test period, certainly other TLDs have had zones that were signed.  But it was the first complete signing through a registrar that supported DNSSEC services with an ordinary user sitting at the screen and going through the dashboard at their registrar.  And the screw up that you were talking about, I was involved in that screw up.  I'm not quite sure which side of that we were on. But this goes back to my comment before about the actionable principles.  You have to be able to export your own key.  Well, the person was inputting the public key into the registrar so it could be signed.  And we had a transcription error.  I was reading off the key and they typed it.  And there was a mistake.  
But to give credit to Ondrej, the Czech Republic, he mentioned his tool.  It's an exceptional piece of work, if you use the Mozilla Firefox browser.  I encourage you to incorporate it into your browser.  We did notice that there was an issue with ICOS when it pushed into the registry and out into the system.  Sometimes you got a green key and sometimes you got an orange key.  It took a while to figure out that it was one of the keys that we had a transcription error, not the other.

>> SEBASTIAN BELLAGAMBA:  Thank you.  I didn't go into such details.  

>> JAMES GALVIN:  It was an interesting experience.  So we started at the top with the root system, and I made the comment that what was interesting about it, from a technical point of view, it was a nonevent.  They had gone to a lot of trouble to do detailed planning.  They carefully executed their complete plan and the root was signed.  And it was rolled out and happened.  And for all practical purposes, nobody noticed.  All the way down to the user community.  And you have pointed out your own experiences, and there were glitches down to the both originals, even the user.  Even when you deal with a relative expert in the process, you can still have problems.  Things happen.  It's a learning experience.      So that opens up this workshop to questions and answers from the crowd.
I'm interested in what you have to say and what would you like.  There are microphones, and we ask that you grab a microphone and use them.  Please say your name, and we want to make sure that the remote participants can hear you.  Peter, one of the panelists who is still with us.  He is out there.

>> AUDIENCE:  I work for the Ministry Defense Communications and Information Services.  I'm a Deputy director.  We supply IT and T services, telephone and Internet for the defense system.  I'm Victor.  And I think what am I going to say to my boss and Administrators after I heard that comprehensive presentation.  One of the best I heard all week.  I can't say that I absorbed it all.  
But when I began listening, I said well, what do I need to do?  Now it seems like I need to talk to our Internet Service Provider about this.  Does it mean -- am I correct?  Do I need to worry about my network?  Do we need to purchase equipment?  We are purchasing routers that are dual stack for the IP version 6.  But, my network Administrators are hard to convince when I come back from a conference with a crazy idea.
I'm a member of the National Communications Regulatory Council, Board of Directors, so I talk with people on the national level about policy.  So, what advice can you give me?  What do I bring back?  How do we get my Ministry of Defense system Lithuania into this?  Or is it something that the service provider has to do?  And maybe I can Prod them to do that.  But thank you very much for your very valuable presentations.  Thank you.  

>> JAMES GALVIL:  You're from Lithuania?  

>> AUDIENCE:  Yes.  

>> JAMES GALVIN:  Let me offer one distinction.  And then I'll give the panelists a chance to offer their comments and advice.  One of the people not represented on this panel, one of the categories of people is ISPs.  And it's important to make the distinction that there are two very large parts to DNSSEC.  There is the whole provisions side, which has a lot of components.  And you heard today from the provisioning side.  So you have the registries, registrars were mentioned.  As a registrant you need to be able to sign your zone and get that information out into the DNS.  Root server operators are represented because they are part of the system in making the key information available at the top level.  And the registry have their own set of registry services.  DNS, you have the chicken and egg thing of you have to sign the zones and get the secure information out there.
The other players are the ISPs.  They have to set up validating.  In order for DNSSEC to be useful, you have to make sure of the information, so you have to validate the information.  Somebody has to query as you ordinarily do for an IP address, or whatever service that you're looking for, and then you have to validate the signature and make sure it's there.  The ISPs are the folks who will do that, for the most part.  
The next phase two of deployment, is looking for browsers and mail services and other applications that we have not started to look at yet, to integrate DNSSEC directly into them.  
So my first part of the response to you is it's not your ISP that you need to go to, but it's the provisions side of the system that you have to talk to.  Your own DNS provider.  Your own registrar.  
With that, I'll offer the opportunity for the panelists to give responses to your question.  Anybody?  

>> ALEXA RAAD:  I think one of the first things you have to determine is which domain names or name you want to be secured.  For example, in the US, the US government has actually mandated that all dot Gov sites be DNSSEC secured.  So first figure out which site needs to be secured.  Find out from your network support who the registrar is, and whether that registrar currently supports DNSSEC.  They may not support it for Lithuania, because Lithuania has not implemented DNSSEC.  But they may be a registrar for another Top Level Domain or ccTLD like CZ, where they have had experience or are planning to.  
And the third step and in the likely scenario that they don't offer DNSSEC for the domain that you want would be to ask them when they do plan to offer.  And then take that information to the network support person to say now, you need to be following up to see what you need to do, what you need to plan for.      For example, in terms of being able to input the keys, what you need to be aware of, so that by such and such a time when they are ready to offer, then we can have that site secured.  

>> JAMES GALVIN:  Anyone else?  Let me add one additional thing.  Alexa commented specifically about the US government mandating the deployment of DNSSEC in dot gov in the US government.  In this forum, it's important to point out that is a role for the governments.  All commissions are the largest vendor provider, purchaser of goods and services.
And the government, pushing the need and requirement for DNSSEC, is one of the things that will help to cause it to come into existence in any economy.  
And so I think that is something to keep in mind.  That is something that you need to bring back to your ministries, if you're not the ministry representative.      Question over here, please.

>> AUDIENCE:  Thank you.  I'm Ivana from the Council of Europe.  I would like to follow the question --

>> JAMES GALVIN:  Bring the microphone up.

>> AUDIENCE:  I want to follow on the question that was made.  The question is what is your advice?  My question to the panel is what is your expectation from governments, governmental authorities?  You have in your concise description of the workshop governments should commit to policies for deploying DNSSEC.  What do you expect from governments?  What kind of policy are we looking at?  You mentioned a set of three principles.  Would it make any sense to have those principles in a set of guidelines that could be promoted throughout the community?  Is that something that you're looking for?  Do you want that to be brought at an international level, that they apply across jurisdictions?  

>> JAMES GALVIN:  I can respond but I want to keep the floor open for other panelists to say something.  

>> NURANI NIMPUNO:  I'd like to follow up on Jim's point previously.  And actually, you drew the parallel to IPv6 and the fact that you're looking at your equipment and making sure that it's v6 capable.  There was an excellent presentation by a representative of the German government who talked about what they have done to push for the deployment of IPv6 in Germany.  They were using the tool that Jim talked about, as a procurer of equipment and as a customer of services.  They made sure to put in requirements there, to not only be v6 enabled but also to go live.  And I think you can draw similar parallels with DNSSEC, where governments have a role to play to put in requirements for themselves, so to speak.  
And by doing so, they are leading the way.  And that is a first step.  

>> ONDREJ FILIP:  I just agree.  We have the -- the IPv6 is a good example.  In our country, the government passed a Resolution that every contract made with the ISP to renew services has to be IPv6 enabled.  And they passed a Resolution that every public service has to be available on v4 and v6 by January 1 of next year.  So we are now discussing with the government whether they shouldn't also pass some similar Resolutions regarding DNSSEC.  We are not successful yet, but hopefully the situation will change in the future.  We don't need anymore regulation, any new law or anything else.  What would help us is to start buying the service, let's say.  But DNSSEC is not a special service, but just to require DNSSEC for like governmental domains and also validation on ISPs that are selling services to the government.
That is all we need, and that would be very helpful.  

>> ALEXA RAAD:  I think government should look at this as a public service.  For example, if you are a constituent and I want to reach a government site, you want to make sure that no one is scamming you.  You want to be sure whether you go to look up your school system or whatever, if the government positions this as a public good, and that they do require it for their own agencies, for their own ministries, for anything that has a Web site for the public, I think then it encourages, it's an incentive as opposed to a regulation, it encourages those that support the services for the government to now provide a DNSSEC capability.  
I think the government also has another role.  You've heard over and over again that it takes so many different organisations to really work in concert.  If this truly is a public good and if DNSSEC as we all believe is the upgrade in the infrastructure of the Internet, so that we can make the next generation of the Internet a reality, then you need to incent a number of different parties along the mix.  So how do you do that?  Part is that you can't just push it down the chain.  You have to also educate the public to want to demand that.  For example, when you ask what do I ask my network support guys, those are the kinds of things that the government can help.  It could be, for example, in public education I realised dot CZ's approach of having the Web site for the elections, and saying that this is DNSSEC secure.
That in and of itself without a Webinar or seminar without anything is enough of an awareness of the public to say I ought to look at that for maybe a banking site.  Anyplace that could actually potentially steal my identity.  So very, very small steps.  It virtually costs nothing, but it can make a huge impact.  And I think you guys did a great job on that.  

>> JAMES GALVIN:  so, I'll just, since you -- I'll join the ranks of all of the others saying that yes, governments have an important role to play in the deployment.  You asked specifically about my three actionable principles and should they be turned into guidelines for government?  I would love to see that.  I think those three things are essential to the success of DNSSEC especially during the transition period as we move to critical mass and then full deployment of DNSSEC.      Frankly, there is no -- there is no leverage for making those things happen.  There -- they are stepped from a technical point of view.  There is sound technical reasoning and a basis for saying that that is the way for things to be for this to be successful.  But how do you make it be the case that everybody wants to do it that way? Because there are always motivations for not doing something.  The rest of the details behind those details -- behind those three principles, so people doing the implementation have to look into those.  I can provide information about what those things are.  I would love to see it happen.  And if you are looking to go make it happen and you are looking for help in that process, I'd love to be a part of that.  
Two questions.  One and then two.  All the way in the back first.

>> AUDIENCE:  Thank you.  My name is Mr.  Kiwandi from the Internet Society.  I have a question which is based on what the ISOC is doing in Africa and mainly on the capacity building side.  But also, I'm trying to find whether these -- there is any advice you would give in terms of -- we have looked at the TLDs, or the registries which will be responsible for enabling DNSSEC.  We looked at how that impacts to the registrars.  But looking at the model of how domain name registrations are done in Africa and other parts of the developing world, you'll find that the registries and registrars -- registrars are a specific entity of their own.  And the DNS service is normally provided by service providers.  In some cases they can be a registrar but not in all cases.
Now, for DNS to work all the way, it means that the validation has to have been with the DNS service provider, who is the ISP providing to the end-user.  How do we get them, if you're looking at the whole mass, to enable them to be (Off microphone.) What structure is used?  Is there any measure being done currently that has been done in Europe or in the US to see how many validating resolvers are there on the Internet today and what strategy is being used to increase the number of validating resolvers?  And how do we get the ISPs who are providing this service to the end-users to start that initial process of enabling them to be validating resolvers?  That will bridge that particular gap where the registries have DNSSEC enabled.  The registrars have the services, or whether there are systems in place to be able to design the zones.
But now the people who are supposed to solve the end-users with the validation process actually haven't done their bit.  

>> JAMES GALVIN:  Peter,  if you want to answer a question, you should let us know.  I know he is out there, paying attention.  But, panelists, do you want to speak to the question?  

>> ALEXA RAAD:  I know that we do, as a gTLD, we talk about registrars.  However, a lot of the folks that we call registrars are, in fact -- would consider themselves an ISP.  Would consider themselves a DNS provider.  So that is just simply our classification and it's not necessarily accurate.
So I understand what you're saying in terms of the model in Africa.  In fact, there are a number of what we call registrars in Europe that are in fact Internet Service Providers, Slund one on one is a huge one in Germany. And they provide broadband services directly to the customer.  
I think that the fundamental premise begins regardless of whether you are an ISP or what we call a registrar, the fundamental premises as my colleague said, what is the business case for them?  Before they actually invest even any time, forget equipment or even any resource to go find out about DNSSEC, or validating resolvers, they have to understand why should they do it?  And what we have find is that typically they fall into the following categories:      Number one, they believe that it is the right thing to do.  That happens to be a very, very small percentage, because most of these organisations are commercial.  They -- they are there to make money and not just to take on costs.  
Number two, they believe that they are able to be competitive because they are able to now provide services that others can't.  So, many of the, for example, godaddy, the reason godaddy announced is because they wanted to be ahead of -- that is their motto, always being ahead of other providers.  And godaddy is a DNS provider as well.  
Number three, they want to be able to compete because somebody else has done it.  When we started and we announced that godaddy was providing it, at that time we had, what, five or seven that had announced.  Now, in a span of a month and a half, there's 29.  So that points to the fact that there are reasons for them to be able to be competitive.  
And also remember what Jim said about transfer.  If you have a DNS -- a signed domain name and you're transferring to a registrar that does not, essentially the process says that you have to unsign the name.  Now, I think it would be very hard, once you are offering a feature to somebody, to say okay, you want to transfer the name, but now you have to give up that feature.  
So therefore it becomes a disincentive for them to shift their loyalty or business from one registrar to another.  And it also enables the registrars that do offer DNSSEC to say look, if you want to have this additional feature, it's a -- it's a way to actually gain customers, particularly specifics of customers who really rely on traffic.          Government, banks, even advertising, you know, relies on traffic to make sure that that traffic is theirs.  So it's a way for them to get very high value customers to move over to their business.  I hope that helps.

>>  SEBASTIAN BELLAGAMBA:  So, I'm from Turkey.  I think in region, I'm coming from Latin America and I know something about Africa, but I can imagine the way that it works.
I think Alexa's comments covered it.  That is domain names.  Another situation is our own ccTLD, and I think because you pointed to Africa, it's another scenario that should be considered in this.  And to put together the two questions, the one before regarding government and the one that you raise now, I think in some way the -- the governmental action in promoting this kind of features in the past has been very important in our regions.  Our organisation and several other organisations doing capacity building practices in the region will make a small difference, but at least it's a difference.  
So I think the -- I think Alexa ended well the relationship between our domains in the region and the the rest of the world or in the developed situations.  But I think the intraregional situation deserves discussion and work.  But it's work as we know it, in Turkey.  
Thank you.  

>> JAMES GALVIN:  Thank you.  In the back.  You.  Yes.

>> AUDIENCE:  Okay.  My name is Abi Pruahia and I am from (Off microphone.)  The way it has been presented, that DNSSEC is the future of the DNS.  And this has been publicized in the Czech Republic, so that the end-user has a feeling of the real service.  
Coming back on the other side of the coin, on the technical issues, I would like to have comments from the panelists about the bending of the requirements.  As you know, in Africa, we are a bit lucky that we had some cables landing in east Africa.  We are not sustainable because we don't have (Off microphone.) What would be needed for the DMSSEC deployment?  Thank you.  

>> JAMES GALVIN:  Anybody want to -- I can speak to that.  Okay.  
Yes, when you deploy DNSSEC it does make changes to your DNS infrastructure.  Okay?  One of the things that we have seen is you can expect to see a four to six times increase in your bandwidth requirements.  For a country, what is interesting is that would be an increase most likely inside the country as opposed to what is going on outside the country.  Because you're going to -- presumably most of your constituency is looking for your own domains in your own area.  A lot of countries in Africa can have limited connectivity going upstream and that could be an issue, but that's something that you need going downstream more than upstream.  The size of your systems will change.  And we tell people you'll see 4 to 6 times increase in the amount of memory that you need in order to support DNSSEC.
You've got queue records, signature records.  Those are additions to the zone.  They have to be there.  And that is driving your bandwidth increase.  
One of the other statistics, this stuff is all in the statistics that Narani had, if you look at the slides, they gave you examples of what the root system saw as part of deploying DNSSEC.      The third thing to keep in mind is you'll see a change in your UDP versus TCP queries.  That is going down to a technical detail.  But DNSSEC supports both kinds of queries.  There are different reasons on why you have to fall back on using TCP queries.  The system is 9 percent UDP based.  There are certain operations that handle the TCP.  One thing that happens is you'll get an increase in the number of queries.  You will have additional networking resources that they will need to deal with on the computer as well as just procession in general to manage all of that stuff.
The root system she commented had seen the TCP queries going up to about 6 percent.  We see about 1 and a half to 2 and 3 quarters of all traffic are TCP queries.  I've not met any other TLD who talked to us about statistics has over 1 percent.  All of the others have been less than 1 percent of the total traffic and the root server system has been seen less than 1 percent.  It's not clear why dot org has a larger percentage.  Our best guess is that just as a global TLD, and really is used everywhere in the world so it tends not to have a regional focus, we're exposed to a lot more kinds of technologies.  And there are known issues with certain kinds of routers and modems with DNSSEC, so we think that we're seeing the artifact of that.  In fact, as this is an SSAC presentation, there is an CCAS document which talks -- it was dot SE, that was the first TLD to sign and identify this issue.
They discovered that they had a couple of regions in their country that went offline when they went to DNSSEC.  It didn't take them long to figure out that it was related to some of the modems that they had deployed.  They just didn't handle DNSSEC correctly.  
I'll leave it at that.  One of the things that happened after that, they did a study across a small number of modems and routers, SSAC took this up and contributed with a couple people to take a broad set of routers and modems and test more of them.  And they identified what they could or could not support.  And you'll find this, SSAC is currently undertaking to revise this.  It's been a couple years now.  So we're taking a look at this again.  This applies largely to ISPs.
They deploy this kind of hardware to people, whoever they are providing network connectivity to, they typically provide the modem or router on the end-user side.  And it's that community of people that have this issue.  The large providers, in the US Comcast and others, they are committed to DNSSEC.  And they provide resolvers.  And they have systems set up to deal with their own infrastructure as they begin the capital investment to upgrade routers across the board in cable modems that their customers have.  So that is a detail issue but it's something that people have to worry about.  
Does that answer your question?  

>> NURANI NIMPUNO:  Just I wanted to add to that that I think we need to be clear about that, that the hardware part its one side of things.  I think as my slides showed, for example, you would see -- you could see the increase in TCP queries because of the fall back on TCP because of the size of the responses.  
And it's clear that a DNSSEC signed zone is a lot larger than an unsigned site.  
The other thing you have to take into consideration of course is the management side of things.  You need to develop a good system to manage the keys.  You need to educate your staff to -- to have the right technical knowledge and also to handle that administrative side of DNSSEC.  
I think as DNSSEC matures, as more TLDs come onboard and a lot of people are sharing experiences, I think dot SE is the first one to sign this.  They have been active not only in promoting DNSSEC but also sharing their experiences.  And there are also a lot of people active in producing software to facilitate the process.  
I think the DNSSEC coalition is a great initiative, and that they have not only as an objective to promote DNSSEC but also to share that experience.  And through that, a lot of the players who are involved with DNSSEC have produced documents to help new TLDs or -- well, or existing TLDs to start thinking about how to go about signing their zones.  

>> JAMES GALVIN:  Peter wanted to add.  We have one question up here and then we will go back to the back.  And Peter?  Do we have Peter connected so that he can speak?

>> AUDIENCE:  Okay.  

>> JAMES GALVIN:  She is connecting you now.

>> AUDIENCE:  I'm not Peter.  
I'm supposed to --

>> JAMES GALVIN:  Just a moment.  Not you.  She is getting one of the panelists connected so he can talk.  
Should Peter speak?  Peter, are you speaking?  
Okay.  I think he is going to type his comments.  We are having trouble getting him on.  
Let's move ahead with the next question while he makes his comment.  Then we will read it back.

>>  AUDIENCE:  (Off microphone.)

>> JAMES GALVIN:  That mic has gone off.  Just push the button on the bottom.  You can try this one.  Is it already on?

>> AUDIENCE:  It takes time to get heated up.  I'm Lui I'm from the organisation called Your Link from France.  We are promoting the use of native languages on the Internet.  So, I'm just going to join here as a curious person, a person, you know, curious about some things.  As far as I can observe, we are -- practically everybody in this room is sitting behind a PC hooked to the Internet via a WiFi link.  We have no idea what ISP is behind that.  
And in addition, personally, I used some open DNS.  By that, I mean DNS, which includes TLDs, which are not in the closed world of ICANN.  And in that case, you know, I would like to know whether you are advocating the use of DNSSEC for us users here, and if so, how can we do it?

>> JAMES GALVIN:  Everybody is looking at me.  Peter?  To respond specifically to your question, there are a number of tools out there.  If you're an individual user and you want to add DNSSEC to your operation, you do need to be at least a little bit technically saavy. Because you can go out -- you mentioned open DNSSEC.  They do have a tool that you can use, and you can download and install that as the resolver that you have on your machine.  And you can put it on your laptop and thus you can have all of your applications using DNSSEC when it's available.  Again, there is the Chech Republic plug in for Mozilla which is a way to see what sites are signed and see how that works.  You can see when a grayed out key, which shows you that there is no DNSSEC information, if there was a validation issue or key information that is not able to validate, versus a green key, and that is useful to use in a browser so you can see the deployment and track those kinds of statistics.
Afterwards, you can ask and I'll point ou at some tools, at some Web sites that have tools that you can go to and get access to stuff that you want to do yourself.  I think most users, you want your ISP to have a validated resolver.  And you want to take advantage of that rather than trying to do it yourself.  
Peter has a comment.  He wanted to add some statistics.  Can you move the right-hand side over some?  It looks like the last half of the right-hand side is not there on the screen.
He just wanted to add that they are seeing an increase of 3 times the bandwidth usage -- there is a better place to read it.  Better.  Okay.  
Increase of 3 times.  60  percent of all queries have DNSSEC.  Not a huge amount of signed domains as we're using DNSSEC 3.  That is an advantage that will disappear as more names get signed, and his own file is limited to 3 percent.  
To clarify, the DNSSEC is okay, it's a technical specification.  It means that the queries that they are seeing are resolvers asking for DNSSEC information.  We are seeing about the same percentage, in the 50 to 60 percent of range of all queries that come to our servers are asking for DNSSEC information.  That is misleading, I have to tell you.  The reason why it's misleading is because bind is the number one name server software Out there.  And it always asks for DNSSEC information.  The fact that its resolvers are asking are not meaningful.  It doesn't mean that they are validating.  So that is misleading.  But it's useful to know for marketshare.  It talks about the NC SEC and opt out.  As any enterprise that signs your zones, you have two choices for how you represent your zone when you sign it.
NSEC versus NSEC 3.  The critical difference between them that you need to know about is that with NSEC it's possible for people to step through your zone and see its entire contents.  If you deploy DNSSEC and you sign your zone and you sign your zone using NSEC, then anybody can go out and they can step through and see all of the delegations in your zone.  This typically matters to TLD, a lot of TLDs, this matters to them.  They don't want that to be true.  They don't want people to be able to do that.  There are reasons why they try to protect their zone file.  
One reason, even if you don't have a privacy concern, there is the operational concern of having everybody stepping through your zone one after another, and just trying to take your data.  So it's common for most TLDs to use NSEC 3, which we use for all of our TLSs.  So we haven't seen the 3, 4 to 6 size increase that will come eventually as more zones are signed.  For most small enterprises, when you sign your zone, the visible part only has a Web site name, maybe a few other common services that you offer.  You want people to know what those are.  You want them to be able to see them.  It's intended to be public information.  
You're probably using NSEC.  One reason is that it's a less expensive choice operationally.  You typically don't find that people see all of that in your zone.  
So there is really no great loss once they get it.  It's done and they see it anyway.  I think that adds.  
And Peter can type in there, if he wants to clarify anything else that I said.  
Anybody else want to add?  

>> ONDREJ FILIP:  Maybe one information.  There is a good example of -- there (Off microphone.) They were able to launch DNSSEC in their country.  And I don't think they faced any problems because of lack of resources.  One advantage is that the query rate and also the zone file are small, so that is why the capacity that is available, even though it's not perfect, it's okay for that.  
More problematic is it for larger zones, like dot com or dot net or dot org.  Those have bigger problems deploying than the smaller zones.  

>> JAMES GALVIN:  We are at end of the session.  Sorry you had one more question.  I believe Alexa was telling me that she needs to end and you offered your apologies, and yes, if you have to go, that's fine.  But we will take one last question.  The mic is up on this table.  Or up in the front.  Alexa.  Thank you very much.  

>> ALEXA RAAD:  Thank you very much.  

>> ONDREJ FILIP:  I'm leaving as well.  

>> JAMES GALVIN:  Thanks.  And he will turn on the microphone in just a moment.  

>> AUDIENCE:  All right.  Thank you.  My question is to Nurani regarding the statistics.  On the root servers, was that -- the statistics, did it include the actual root server, the 13 of them, or does that include any custom nodes?  

>> NURANI NIMPUNO:  The 12 excluded all the Anycasted nodes for all of the roots.  Not all roots have operators.  Anycast.  But in our case, for example, yes, that included all of our Anycasted instances.  

>> AUDIENCE:  Okay.  
Well, then, my next question is not -- was going to be that if it does, because we host root servers in Kenya and we noticed a slight increase in the traffic going to the nodes.  And when I wrote to the operator, I haven't really gotten a solid answer that it has anything to do with DNSSEC or otherwise.  Because we don't go into the detail of analyzing what traffic is going to the specific nodes.  So, I just wanted to know if that is the case, because if it is, then it's having an Anycast server in country over the root server is going to be a significant cost saving to the developing countries, when it comes to resolution for the DNSSEC.  

>> NURANI NIMPUNO:  Certainly.  Yes.  

>> JAMES GALVIN:  I think it's important to keep in mind, to add a bit about Anycast, Anycast is a layer underneath things for most people. So it's about having multiple servers in multiple locations that look like one.  And you don't really need -- if you're trying to get access to the root, I mean, you might want a root server in your country, but it doesn't necessarily -- it would be part of the Anycast mesh.  You wouldn't want multiples those in your country or in your particular region.  Does that make sense?  Never mind.  I'm just confusing people.  Let me stay out of it.  

>> NURANI NIMPUNO:  I think he is aware of that.  His point is that by bringing a root server closer to your ISP community, you reduce the amount of traffic to the root server that has to go outside of the country.  And it increases your buses in the country.  

>> JAMES GALVIN:  Sorry.  

>> SEBASTIAN BELLAGAMBA:  We are basically locked.  Well, on the other hand, we have our transcriber and the video feeds, and those folks do expect the session to end on time.  So we have run over a bit.  Clearly the three of us are still here.  If you have additional questions, I'm very happy to stick around myself.  I suspect that they will, too, for a while.  Please come up and talk to us.  I'm happy to provide more information.  
But, -- the door is actually locked.  

>> SEBASTIAN BELLAGAMBA:  Yes.  

>> JAMES GALVIN:  We are stuck here.  

>> SEBASTIAN BELLAGAMBA:  I wasn't kidding.  

>> JAMES GALVIN:  Well, let me adjourn the meeting and we will get together with a table and see if we can push it through the door.  
There is an emergency exit in the back.  There is another way out.  We're not really stuck.  
So anyway, thank you very much.  Thank you to the panelists, thanks for the record for those who did have to leave earlier.  And thanks for participating in the workshop.  I hope it was useful and helpful.  If you pay attention to SSAC, this was an SSAC sponsored session.  If you want future topics presented here more fully, let me know or let SSAC know.  We plan to do these things, picking significant topics and bringing it to this group for discussion.  
With that, we are adjourned.  Thank you very much.
(Applause)
(End of session)