ISOC - DNSSEC Panel Presentation [Draft transcript]
July 28, 2009, 11:45 a.m., Stockholm, Sweden

	
		LESLIE DAIGLE:  So I think we're about ready to get 
started.  If people want to find their seats, we'll get going in about 
a minute.
		Okay.  Good morning, everybody, and welcome.  My 
name is Leslie Daigle and I'm the Chief Internet Technology Officer 
for ISOC, and very happy to welcome you here to our session this 
morning on securing the DNS.  We're certainly very pleased to 
have you all here.  I think some of the organizers were thinking 
that they would be repurposing tickets from no shows, but I 
suspect that was not an issue.
		I would like to point out that we are being live audio 
cast and the audio cast and transcript will be available for later 
download.  Later, when we get to the discussion session, there are 
microphones, so we will be running microphone lines for questions 
as appropriate.
		I also would like to remind people that this is not a 
technical debate.  The IETF is over there, through the rain.  And 
what we're trying to do here is to pull out the messaging of some 
on this particular topic and get it out into the real world.
		So, with that, I'm going to go through some basic 
material about the DNS and DNSSEC, which I appreciate that 
most people in this room are completely familiar with, but I would 
like to use it to set the, set the tone for the discussion, and also to 
provide background to media and other folks who will be referring 
to this later.
		So, the domain name system, as we all know, in this 
room, the DNS is really core infrastructure for Internet applications, 
virtually all the things that we like to do on the Internet, apart from 
routing packets, perhaps, really involves using the DNS which 
makes it a vital part of the infrastructure.  And as a system, it is 
global and yet highly distributed, so the data updates are done 
close to the source of information.
		And that DNS system has served us quite well, 
efficiently and effectively for a couple of decades, and it has in fact 
scaled to the needs of the Internet.
		So, when it comes time to talk about securing the DNS, 
it's important to think about, well, if it's scaled and it seems to work 
pretty well, what are the issues?  There are many threats to the 
DNS as there are to any infrastructure service.  And they come in 
many flavors.  Whether it's issues with configuration errors on 
servers, or errors in data packets from DNS or connectivity issues, 
there are a number of, a number of issues that can arise to cause 
issues with the DNS.
		And there are many solutions as well, including 
improvements in software over the years, improvements in best 
practices and guidance to make sure that everyone who needs to 
is capable to set up their DNS server and DNS data as 
appropriate.
		There are new ways and ever increasing ways to deal 
with denial of service attacks.  And then there's the important step 
of enabling authentication of DNS response data, which is DNSSEC.
		What DNSSEC does is enable the verification of 
responses to make sure that what you get from a DNS is actually 
what the zone administrator intended you to.
		This uses public key cryptography, and in order for the 
whole scheme to work, it really does require DNS uptake 
throughout the DNS hierarchical infrastructure.  This does not 
address all threats, not all the issues listed on the previous slide, 
but it does provide a building block for providing more security, not 
only in the DNS, but also in all applications and services that are 
built on it.
		And we might recognize this as being part of the 
standards and deployment cycle.  Essentially we start off by 
people coming together and intelligently working out what the 
issues are and creating technical specifications.  That's what the 
IETF does.
		This is a collaborative process and best efforts are 
made and the important pieces are agreed upon in technical 
specifications.  It's a completely separate, and frankly, voluntary 
step to take up those technical specifications, implement them and 
deploy them.  
		After that phase, in any given technology development, 
there is usually a period of further development, things built out 
upon the technology that perhaps had not been envisioned, and 
then we often find ourselves back in the phase of reviewing and 
revising technical specifications and building new ones.  This is all 
very normal.
		So perhaps the exciting thing, from the perspective of 
having this panel here today, is that we are now very much in the 
deployment part of the DNSSEC cycle.  And the people who are 
on the panel here today are going to tell you a lot more about how 
important pieces of the DNS system overall, or in fact have 
deployed DNSSEC, or are on the verge of doing so.
		So, I guess one of the key things to take away here is 
that DNSSEC is not an academic exercise.  It is for real, as our 
panelists will elaborate, and the discussion should further clarify.
		On the panel, we have Olaf Kolkman, who is the 
Internet Architecture Board Chair, but is speaking here today as, 
on his own personal title as a DNS expert.  He will be talking about 
the IETF development of DNSSEC and technical development 
experiences.  We have Patrik Wallström, who is from .SE and will 
be talking about their experiences.  We have Jim 
Galvin, who is with Afilias and will be talking about .ORG 
experiences; Matt Larson, who will be talking about .COM and .NET 
activities; and we have Richard Lamb from ICANN, who will talk 
about DNSSEC at the root as well.  So, with that, I would like to 
hand it over to Olaf.
		
		OLAF KOLKMAN:  Yes.  Let's grow as a chicken.  That 
refers to chicken and eggs, which I allude to a little bit later.
		Deployment cycles, Leslie already touched upon them, 
there is a constant interaction between the standardization, 
between development of code and deploying that code in the real 
world, learning from experience, both in development as well in 
deployment and feeding that back to standardization.  This is a 
complicated or not so complicated graph, but the interactions are 
moving in all the ways.
		Now, in 1995 it was publicly realized, it was realized a 
little bit earlier that DNS was structurally vulnerable.  And you can 
ask yourself the question, and many of us actually did, why did it 
take fifteen years to reach the state where it is now?  And what is 
the future, given that that happened?  And so, what I, what I'll try 
to set out and do is look a little bit at that past, at the history, see 
where we are today with the DNSSEC deployment, and sort of 
give my ideas of how it will develop further.
		Chicken and eggs.  You see three blocks of entities, 
basically, that are responsible for, that are actors in the DNS 
deployment world.  The DNS hierarchy, the people who provide 
authoritative answers, starting from the root, going to the TOBs, 
going down into the enterprises and companies, people need to 
sign and deploy DNSSEC in order for those, the people in the 
second block, the ISPs, the enterprises, basically the customers of 
the data, on a somewhat larger scale to do validation in the 
components that are used for that validating name server.
		And then thirdly, once that is all in place, OS and 
application support might actually happen and things might move 
further to the right of you.
		But the questions, of course, why invest in signing while 
signatures are not going to be validated?  And for the middle guys, 
the question is, why invest in validation while there's nothing to 
validate?  And why invest in development if there is so little 
infrastructure?  Those are typically chicken and egg problems that 
hold up deployment, further development, and spread out of the 
technology.
		Now, the time line.  Early days, I think that you could 
claim that Bellovin's paper from 1995, based on a 1990 discovery 
has been the birth of the DNSSEC.  That is when people in the 
IETF became active and started to look at the technology.  I was 
not around at that time.
		It looked at, basically, it looked at the -- now something 
is going on here.
		Basically, it looked at the protocol elements.  It looked 
at the structure, it looked at the security aspects of it and the 
system was designed that the protocol people thought was ready 
for deployment.  This was in 1999.  This was all published as 2535, 
RFC 2535, and people really thought this was ready for 
deployment.  Everything that went on between 1995 and 2000 was 
basically development of code and standardization, and the 
interaction between them.  It was very little deployment 
experience, except in a few labs.
		Around 1990, around 2,000, the first deployment trials 
started.  Sweden was one of the organizations that really wanted 
to get DNSSEC deployed.  In the Netherlands people were 
working on it, and there are other entities as well that were looking 
at DNSSEC and trying to head down to real deployment.
		What was discovered was that, for registries, the 
technology did not scale.  So, by making the jump to early 
deployment in the registry world, the standardization and the 
development effort noticed that they missed something.  Well, this 
happens in real life.  But it also means that the standardization 
effort needed to go back to the drawing board at that point.  This 
resulted in the, what we now call the DNSSEC BIS specification in 
2005.
		That didn't catch all.  Without, without saying what, or 
without putting blame on what exactly happened, there were a 
couple of requirements that either came in late or were ignored, or 
was really, were not really appreciated as valid concerns for 
deployments.  Things happen in communication between 
developers, standard organizations, and the field.
		So, the privacy and scaling concerns were recognized 
at the end phase of the development of DNS BIS in 2005 and, but 
were not put into the specifications until later.  And I'm talking 
about the technology that is now known as NSEC3 but it's an 
important part to get significant fraction of the population that 
needs to deploy DNSSEC on board.  This happened in 2008.
		Now, at the same time -- so now we have a chick.  It's 
very, we've got something that is, that is small, that can work.
		And at the same time, people started to look at how can 
we actually deploy this?  They started, the early players started to 
make the deployment plans.  Training became available.  People 
started to build software to make actual deployment outside of the 
lab easier.  That is the stuff that is going on today.
		If you look at products like open DNSSEC which will 
be, which is currently in development, there are a system 
integraters that will sell you DNSSEC in the books.  Well, the first 
top level domains are signed.  Things are bubbling up.  
Coincidently at the same time, and this is truly coincidently, 
Kaminsky found a new way to approach, a new approach to exploit 
existing vulnerabilities, that Steve Bellovin discovered in 1990.
		That turned attention to DNSSEC a little bit faster.  
Fortunately, we are, I believe now, at the sweet spot, if it comes to 
deployment.  Let's continue.  Let's see how the future can develop, 
because, obviously, this is a volunteer effort.  The players in the 
market or in the industry will need to take the next steps.
		We are very close to getting significant parts of the 
hierarchy signed.  There are, you will hear on this table, there are 
plans to go ahead with major zones.  
		ISPs are now currently looking very seriously into how 
to deploy DNSSEC validation on their end.  Obviously, there are 
hurdles that need to be taken.  But that is the fact of real 
deployment and real evolution of Internet technology.  Things need 
to happen and we learn from that, as a group, as a community.
		Once we've got this in place, we've reached what we 
wanted to set out with DNSSEC.  We secure the infrastructure.  
But there is more.  There's a further future down the road.
		I believe that once you got this infrastructure in place, 
things can move out to the OSs.  And the applications and people 
are already thinking about this, in parallel to the other 
development.  I believe that once we have the DNSSEC in place, 
we certainly have this central component in the Internet that you 
can use to bootstrap trust relations.  And now you can start to think 
about, you know, let your fantasy run wild and think about new 
applications.
		And this is something beautiful about the Internet, the 
constant evolvement that takes place.  We cannot predict what is 
this further future.  But I believe that DNSSEC makes a foundation 
for many beautiful things to come.  
		And then we're at the place where we can say we have 
a chicken, or a rooster in this case, I believe.  
		(Laughter.)
		OLAF KOLKMAN:  As I said, I think we're at the sweet 
spot currently today.  We are at the sweet spot if it comes to 
making the Internet as a whole a more secure place.  The DNS is 
one of those central pieces of infrastructure that's used by virtually 
every component on the Internet.  And I think that, you know, we 
have a, some responsibility as a community.
		And the custodians of the DNS infrastructure are 
actually taking responsibilities.  They are on this table and you'll 
hear about that later.
		Tools, training, software is available to start deployment 
by ISP and this will only grow.  There are OSs, and there's a move 
towards DNSSEC awareness to the application.
		And while DNSSEC evolves, it will not only secure the 
key infrastructure element of the Internet, but it may also create 
new opportunities.  And that makes that evolution and deployment, 
development and standardization to continue.  
		If we are at that future, you can all wear this beautiful 
T-shirt and say, you know, DNS SEC, been there, done that.
		Thank you.  
		( Applause.)
		 
		TED HARDIE:  Do you have questions now or at the 
end?  
		LESLIE DAIGLE:  If we can get clarification questions 
now, but the discussion will be at the end.  
		TED HARDIE:  Thank you.  
		PATRIK WALLSTRÖM:  I will talk a little bit about 
what we have done at .SE within DNSSEC.  
		OLAF KOLKMAN:  Maybe this helps.  
		PATRIK WALLSTRÖM:  Thank you.  We started 
working with DNSSEC in 1999, when we saw that DNS is 
vulnerable in different ways, in the same way that Olaf described.  
So we started working with a little bit of standardization work that 
was going on.
		And we did it, that until September 2005.  And when 
there was a version of bind that has been released for very while.  
So, we signed the (inaudible) with no delegation was only for 
testing, but with the read name service so we were the first TLE 
that was signed.  So that worked quite well.  So, in 2006, we let the 
test delegations, so we had found users using DNSSEC in the way 
it was supposed to be.  And that worked quite well too.  
		So, in 2007, we started to realize that we could do this 
as commercial service, so we actually set the price on the 
delegations in (inaudible).  And then in 2008, we had the Kaminsky 
bug happening, so that is a short time line on what we did.  So the 
current growth of it looks approximately like this.  We can see it 
grows much faster now, and we were working very hard with our 
registers to make them understand the importance of this.  And we 
were also helping them implement the solutions they need to sign 
a lot.
		And as you can see, this bar here is the Kaminsky 
attack being announced, so that's, that increased the interest in 
DNSSEC.  But keep in mind, this is very low amount of the main 
sign, still.  So, it has, this is was the pricing we used.  We initially 
announced a very high price for the security delegations.  There 
were a number of reasons for this.  We were still really quite sure 
that it would work okay, so we wanted to restrict number of 
domains that were used.  And we cannot force the (inaudible) 
increase of the domain would do, if everything would crash and 
burn and stuff like that.
		But, as you see, between 2007, 2008, it didn't really 
increase number of domain numbers to run this as commercial 
service, so we lowered the price in 2008.  So the main factor here 
is really the Kaminsky bug.  And that is also why we have the zero 
price currently.  We cannot have this as an additional service that 
you pay for.  We consider this now as an important piece of the 
Internet infrastructure.
		So, we see a feature where basically all domains, 
domain names are being signed.
		Initially, we did also do some market research, to see 
what kind of interest there was, and the interests were actually 
quite high.  People were ready to pay for this service.  As you may 
know, people are always ready to pay for increased security.  So, if 
you tell them that this will increase the security, people probably 
pay for it.  But, we weren't really sure if they know what, knew what 
DNS SEC was.  So, but now we're working more with getting 
registrars interested in helping them to be more active in, into 
selling DNSSEC.  They have a lot of domain hosting themselves, 
so they will have to take the responsibility for signing the 
customers domains.
		They have also been working with all the major Swedish 
resolver operators to make them validate domain names as well.  
And now all major Swedish are operating it.
		They probably also accept the roots, but, currently, they 
don't work with our TLDs, only SSO.  Because having a lot of keys, 
obviously is very hard to do, because you have to keep track of all 
the different TLD policies.  Working a lot with education and PR in 
Sweden to make people and aware of what the Kaminsky bug 
really means, and why they should secure their name servers.
		We have also signed a number of high profile domains.  
We didn't do it.  They did it themselves, because we proved that 
DNSSEC is really and secure.  So, we have the Swedish tax office 
and Swedish election web sites signed.  And the vote survived the 
recent election and the recent tax returns, so we are really proven 
that DNSSEC works by now.
		We exchange keys for the SSO every year, so we, we 
used to know which resolver operators used to use, use our keys, 
in the resolvers, but we don't read anymore.  So we have, we 
announced the recent key case change in the major newspapers, 
as, just announcing that we have changed our key now.  You 
should probably update, because we don't know the resolver 
operators.  It's really hard to measure the use of the DNSSEC.
		When the Kaminsky bug happened, we saw that the 
amount of vulnerable servers are still quite high, so we wanted to 
reduce that number and also make people use DNSSEC.  So we 
launched this web site, which has a movie demonstrating attacks 
on DNS.  And we can also test your computer, which means that 
you can test that the resolver you are using are, is secure or is 
using DNSSEC.  If it's vulnerable to the Kaminsky bug, it will tell it 
right to you, and it would also explain what you should do.  It can 
also test your domain to see if it runs DNSSEC, but it will also test 
the name service to see (inaudible) and also vulnerable to 
Kaminsky attack.
		We had some deployment experience, problems, 
reducing DNSSEC.  As most of you have heard, we have problem 
with one big domain in Sweden, jab OTC and the person who 
signed it is here and so you can ask him all the questions later.  
What happened was that there was a bug in bind which two of the 
major ISPs were using, which said the AD flag by mistake, and that 
was the real cause of the problem.  It was not a problem that home 
routers were failing because of DNSSEC.  They were failing 
because of the bug.  So that has been fixed and home 
routers have since had no problems with DNSSEC.
		The real problem with DNSSEC in home routers is, if 
the clients themselves tries to do addition, there might be big 
packets going through that the home router would not let through, 
because they do all the candle change stuff within DNS.  This is 
also going to be a problem with IPv6 when you get large 
responses from your resolver.
		We have had some problem with name server where 
name servers have stopped touching the (inaudible) file, which is a 
problem because signatures in DNSSEC expires after a number of 
days.  So if that happens, all the responses from that name server 
are going to be bogus.  So we have increased the monitoring for all 
the name servers that we use, and can also shut them down if they 
are having problems.
		The major problem we have now is registrar transfers, 
where I have one registrar that do DNSSEC for you, and they 
move to another registrar which doesn't do DNSSEC at all, and 
the gaining registrar has no clue what DNSSEC is and removes 
the DNS records, for security.  And this has happened four or five 
times now.  Last time it happened on Saturday.  And receiving 
domain person complained that his domain did not work, because 
the domain server didn't sign with the right key.
		So the way we try to do this, we try to educate the, all 
the registrars what to do when they do a transfer, and what DNS 
SEC is and what they can do.  All the Swedish registrars that has 
registration for the SE domain has an agreement with us that they 
at least must be able to remove DNS records from the delegation.  
But we still have to see it in practice.  They really should know how 
to do it.
		In order to increase the quality of domain names, we 
also have the quality DNS check where we have added DNS 
check.  So you can see that your delegation works in every way.
		This is very useful and it's also open source and you 
can download it and test and implement your own version of DNS 
SEC.
		We are also working very hard with deploying the open 
DNSSEC, which is a tool that we worked together with (inaudible) 
labs and other parties, because we realize that the registrars and 
TLDs very much would like much better to sign the, their domains, 
so, so it's a very policy driven tool.  We have a policy, and that 
policy applied to the signing of the zone.  So, you need to define 
policy, and outcomes the desired zone.  So to have the widest 
deployment possible, it is completely open source.  And we will 
have a preview released this week for this too.  So I encourage 
every one of you to download and try, at least the technical people 
among you.
		Thank you.  
		(Applause.)
		
		JIM GALVIN:  Thank you.  As, Leslie said in the 
introductions, I'm actually with Afilias.  That's the back end service 
provider for .ORG.
		So, first most obvious question to ask, why would .ORG 
undertake to want to assign a zone?  And the answer is in part, 
because it was the right thing to do.  Org brand is known for being 
informative, well intentioned, trustworthy, valuable information.  It's 
reliable.  DNSSEC was a natural extension of all of those 
elements, and so it seemed pretty obvious that it was the right 
thing to do.
		In addition, org brands, PIR was created to serve the 
public interest.  In that respect, then, it was you know, a fairly 
obvious thing for us to do to step up, and want to be part of the 
early crowd in the deployment of DNSSEC and making it 
available.
		And so, beginning about 18 months or so ago, we 
started planning and we realized our goal here on June 2nd of this 
year, a little over, not quite two months ago.
		I don't really want to belabor these next couple of 
slides.  I think that the take away here is really because the threat 
is real.  I mean, it's important to keep that in mind.  There's a lot of 
anecdotal information about security attacks and how DNS itself 
may or may not be related to that.  And what we have here is a 
couple of examples of some actual events that really have some 
interesting documentation that you can get at on line, because I 
know that can be hard sometimes for security events.  I think the 
important take away from these events, when you think about 
whether or not DNSSEC is important to you as a domain owner, is 
just that you are at risk from third parties.  The first example and 
the last one down here was just two weeks ago, the Irish Internet 
service provider.  You're at risk for configuration errors.  Their 
customers, who are potentially your customers, put you at risk, and 
you know, make it possible for people not to be able to get to your 
site and do the things that you want them to be able to do.
		This has been said already a couple of times, you 
know, securing the DNS is not really about just the DNS.  It's not 
about the man in the middle attacks and getting false information 
about the DNS.  It's about securing an infrastructure protocol.  The 
DNS, everything relies on the DNS.  It's important and critical to so 
many applications.  And we don't even know in what ways securing 
the DNS will play and improve overall Internet security.  It's a new 
tool in the arsenal for mitigating attacks, and making many 
applications more secure.  It's not by itself a magic bullet.  But as a 
foundation, as a cornerstone of Internet security, it's an essential 
component of improving everything.
		And again, we don't really know all the places we're 
going to go once the Internet, once DNS is secure.  And that's 
what's important to understand here.  This is back to the chicken 
and egg thing that Olaf was talking about at the beginning.  So 
somebody has to start and you need that chicken, and getting 
more TLDs on board, and making signed in information available, 
makes it possible for applications to begin to think about what they 
can do.
		I wanted to end with some specific advice about what 
you could do as you're making your plans for signing.  You know, 
both TLDs, and of course, individuals who might want to think 
about their own zones, and there's some graphs here at the end to 
show you some of the things that happened to us.  Little bit about 
our time line.  We actually started setting the TTL to zero on all of 
the DNSSEC records.  This was kind of important to us.  It was 
really a worst case scenario backup plan.  You know, a lot of 
planning went into rolling this out.  And of course, our intention 
was, once it started, it wasn't going to stop.  And we're pleased 
that that in fact is exactly how it played out, and we're very happy 
about all that.  But you know, we needed to be able to insure that 
you could turn it off if you needed to, that we can back out if 
something really bad happened.
		And over time here, we've upped some of the TTLs.  
We've done our first DNS key roll, ZSK roll.  A couple things about 
the .ORG zone.  It's the largest TLD now that's signed and we do 
use NSEC3.  7 and a half delegations, 18 million resource records.  
So it's a pretty large thing.
		Three specific suggestions here, as you think about the 
deployment of DNSSEC and make your own plans for doing it.  
You should very much make technology your driver for what you 
do.  You know, as a service provider to PIR, we are very pleased 
that that in fact was the approach that they took.  It was not driven 
by PR or marketing or management.  It was driven by being 
prepared, making sure all the pieces were there, testing 
everything, knowing for certain that it was going to work when it 
was rolled out.  That's very important.  DNS will change your 
operation and the way you do things.  That's as it should be.  
Security does that.  It's not the same when you add security to 
anything.  And you have to expect that.  And so, it's important to 
put the time into making sure that things are going to work right.  
And you can't let that be driven by something other than the 
technology itself.
		The other thing is collaborate.  All the panelists up here 
are a clear example that there are people out there with 
experience.  Of course, this is the IETF, as Leslie said when we 
started.  There are plenty of experts, and they're all willing to help 
and you should let them do that.  Don't miss the opportunity to ask 
for review for, you know, insight into what you're doing and how 
you're doing it.  Very important.  And you will get a lot for that.  And 
we were thankful for that too, ourselves.
		And of course, a phased approach.  You cannot do it all 
at once.  For something that is an undertaking for us of, this large, 
we didn't want to do it all at once.  And I think it's important for you 
to consider that option too.  Do it as a phase thing.  I do apologize 
to Russ here, for stealing his thunder.  We did start with a test 
delegations, incidental zones that were signed because it's 
important to test procedures and because it's important to test 
procedures to make sure it works.  .ORG were among the first of the 
signed delegations that we have in .ORG and I want to thank Russ 
and the IETF and take a moment, really to do that.
		Very pleased that the IETF was quick to eat its own dog 
food, as the saying goes.
		So, oh, you don't have the last couple of slides, the 
graph.  Golly gee.
		
		LESLIE DAIGLE:  We'll put that on line later.  
		JIM GALVIN:  Let me tell you, there were three graphs.  
The first one actually tells you, shows you that 50 percent of the 
queries that we get are actually asking for DNSSEC information.  
Now, some of this is an artifact that the fact of bind, as the most 
popular name server software out there, actually sets the technical 
DO bit up front.  So by default, you get a lot of queries that ask for 
DNS SEC information.  You should keep that in mind, especially 
TLDs and the larger enterprises.  You're going to get DNSSEC 
queries and you need to plan for that.  From our point of view, with 
.ORG, we've seen that 50 percent of our queries have that.
		The page after that has two graphs on it, which I will tell 
you are unrelated, so you should not try to overlay the X and Y 
axes of those two graphs.  But one graph shows you what happens 
when .ORG was signed.
		You will see a bar down at the bottom as if there's 
nothing there.  And then all of a sudden, there's a giant peak, and 
it looks like a building standing there.  That was the moment in 
time, it represents June 1st to June 3rd, so the middle of the graph 
is June 2nd.  And what it shows you is what happened to TCP 
replies when .ORG was signed.  They increased by two orders of 
magnitude at the moment that .ORG was signed.
		That was a little bit unexpected for us, actually.  It did 
not affect the operation in any way.  We didn't have any trouble 
dealing with it, but it was an interesting observation to see.  And 
we're still, even now, really thinking about, you know, what we can 
do to optimize that, and make things better in the future.  But you 
should keep that in mind for large zones.  And I'm sure that 
dot-com and dot-net are worried about that.
		The graph on the right, people always ask us how many 
TCP queries do we get in .ORG, given the graph on the left and 
the increase in replies, how many TCP queries do we get.  The 
graph on the right is a day in the life.  It's June 20 of 2009.  It 
shows up to about fifteen percent of our queries are TCP based 
queries, and that's significant too.  Most people expect DNS 
obviously is primarily UDP based.  And so, if you're not thinking 
about the fact that you're suddenly going to fall back on TCP, you 
should keep that in mind.  That's a lot of queries to suddenly get.
		The average is really around ten percent.  So you'll see 
a range from five to fifteen in the graph.  But the slides are on line, 
so take a look at that.  Okay.  Thank you.  
		(Applause.)
		
		LESLIE DAIGLE:  As Jim is handing off the microphone, 
we're running a little long, so I would ask both Matt and Rick to just 
keep an eye on your five-minute time frame, or I'll help you.  
Thanks.
		
		MATT LARSON:  Okay.  I'm Matt Larson.  Despite the 
vice-president title, I'm an engineer.  I just want to be clear.  But I 
work in VeriSign's office as the Chief Technology Officer, and I'm 
happy to be here today to talk about where VeriSign is headed with 
our deployment plans for DNSSEC.
		I want to very briefly talk about where VeriSign has 
been with DNSSEC.  There's been a long involvement with the 
DNS SEC development and it now represents a significant fraction 
of my career.  So I'm very excited that we're finally now going from 
talking to doing.  And that we're actually deploying DNSSEC.
		I want to just touch briefly on the NSEC3 extension that 
you've heard now in several presentations.  As Olaf said, NSEC3 
is key signed to address both privacy and scaleability concerns.  
VeriSign was one of the organizations that helped develop and 
encourage the adoption of NSEC3 protocol by the IETF.  And we're 
quite interested in it from the scaleability perspective.  When you 
sign a zone with DNSSEC, the size of the zone immediately gets 
much larger, and how much larger depends on the specific 
parameters you've used, but it can be three to four times as large.  
And dot-com and dot-net combined today have some where, 
somewhat larger than 90 million delegations, so they're very big to 
begin with, and three and four times larger than that would be even 
larger that we didn't want to contemplate.  So NSEC3 will allow us 
to scale much more gracefully.
		Over the years we have done some pilot projects 
relating to DNSSEC to allow us to get operational experience and 
then to allow the public to get operational experience as well.
		For example, one of those was a pilot that dealt with 
NSEC3, the most recent pilot was signed roots on pilot.  And in 
that case, we actually used the production signing infrastructure 
that we use for our certificate business to also secure and do the 
cryptographic signing of the sign root zone, and in fact, the actual 
signing of the production root zone will use a similar architecture, 
but I'm stealing my own thunder a bit and getting ahead of myself.
		And then I did want to take a moment, I was surprised 
Olaf didn't mention unbound, so I will mention it.  One of the other 
things that VeriSign is very pleased to have had a part in is the 
development of the unbound recursive name server and DNSSEC 
validator.  Several organizations thought that it would be important 
in the interest of software diversity and more choices in recursive 
name server, and to build one that had DNSSEC built in from the 
beginning.  And VeriSign was among the organizations that was 
involved initially to develop the prototype and do some design 
work, going from a prototype to an actual production, reliable 
releasable, usable recursive name server was done by NL net 
labs, Olaf's organizations.  And they've done a tremendous job 
with that, so I would encourage you to look at unbound for all your 
DNS SEC validation needs. 

		OLAF KOLKMAN:  That's a good plug.  
		MATT LARSON:  Some day I'll want a favor.
		All right.  So, with regard to VeriSign specific DNS 
plans, we certainly recognize that there is tremendous demand for 
DNS SEC in dot-com and dot-net because of the way DNSSEC 
works.  If you have a domain underneath dot-com or dot-net and 
you want to sign it and take full advantage of DNSSEC, it does 
require that dot-com and dot-net also be signed.  So there are 
potentially 90 million people wanting us to sign dot-com and 
dot-net.  However, the deployment of DNSSEC overall will 
represent really the largest change in the DNS infrastructure in its 
20 plus, almost 25 year history.  And in my opinion, it's one of the 
largest changes we'll ever have done with DNSSEC.  So as a 
result, we're approaching this cautiously. 
 		As I already mentioned, one of the significant issues is 
that everything gets larger.  The responses get larger so that 
means significantly more bandwidth.  The zones get larger so that 
means you've got this much larger thing to load in memory, in your 
authoritative name server, store on disks, store information, move 
it around.  Everything gets bigger and more unwieldy.  
		So, getting ready to do DNSSEC in dot-com and 
dot-net has been a major development effort for us.  Really every 
component of the dot-com, dot-net registry has been affected.  The 
registrar interface, EPP protocol that registrars use to provision 
domains, and the registry will have to be updated to allow 
registrars to provision DNSSEC material.  Of course the schema 
of the database changes.  We have to store that DNSSEC 
material.  The logic of the system, the business rules changes, 
there's a brand new component cryptographic signing engine, and 
this is going to use special hardware.  VeriSign uses its own DNS 
resolution software.  We've written our own authoritative name 
server, because of the particular demand serving dot-com and 
dot-net.  Our monitoring system has to become DNS aware.  And 
that's just partial list.
		So, there is a lot to do, and work is already in progress, 
but we are proceeding cautiously, but deliberately.
		We definitely want to get this done.  It is going to 
happen, but at the same time, we're doing it in a way that is going 
to preserve the stability of dot-com and dot-net, in particular, and 
the Internet's DNS as a whole.
		So, the dramatic build up, dot-net is going to be signed 
by the end of 2010, and dot-com will be signed in early 2011.  As I 
said, it does represent a major development effort.  That is the 
reason for some of these time scales.  And also as I mentioned, 
we're interested in moving very cautiously, given the size and the 
significance of these particular TLDs.  
		So just some of the technical details, completely 
unsurprisingly, we will be using the NSEC3 protocol and in 
particular, opt out for both dot-com and dot-net.
		And I guess this is a really minor technical detail, but 
registrars will be provisioning DS records, as opposed to say DNS 
keys, with the DNSSEC EPP extensions.  
		So that's about all I have to say about dot-com and 
dot-net, but I'd be happy to answer more if I can during the 
question and answer period.  And I have one slide about DNS in 
the root zone, which I imagine there's also interest in.
		So, right now, there is a set of root zone signing 
requirements that's been developed by the U.S. Department of 
Commerce, and it's undergoing invited technical expert review right 
now.  So, many people have seen those requirements for signing 
the root and are commenting on them right now.  The actual 
signing is going to be a collaboration between VeriSign and 
ICANN, who are the current contractors to DOC, and the current 
partners who provide the root zone to you today.  VeriSign is the 
functions -- excuse me.  ICANN is the VeriSign -- the third time will 
work.
		ICANN is the IANA functions operator and Veri-zone --
		(Laughter; applause.)
		MATT LARSON:  I would like to note that it is six hours 
ahead of my usual time zone.  I'll blame it on that.  
		So Veri-zone as root zone -- did I say Veri-zone?  
VeriSign.
		I'm so glad my management will be able to hear the 
audio transcript of this.  
		NEW SPEAKER:  You have the audience laughing.  It's 
okay.  
		MATT LARSON:  So the way the root zone is going to be 
signed, the way the roles and responsibilities will be split up is 
VeriSign is going to create and manage the zone signing keys, and 
then we already create the root zone.  We already publish the root 
zone to the root name servers, and so we're going to insert the 
step of actually signing the root zone in the middle there.
		ICANN as the IANA functions operator is going to 
create and manage the key signing keys for the root zone, and 
then they will have to sign the root zone key sets, which consists of 
the zone signing keys, and the key signing keys.
		So, there will have to be an interaction between 
VeriSign and ICANN, and we will send them zone signing keys and 
they'll send back signatures to put back in the files.  So we're 
actively developing that protocol and the means to secure that 
interaction.  We're taking advantage of face to face time right now 
between VeriSign and ICANN to work on that here in Stockholm.
		And we are working toward implementation in 2009.  
That's the goal.  But with that being said, this also is a major, 
major effort with a lot to do, a lot of documentation to write.  It's 
also very important, it's absolutely critical to the stability of DNS 
that the root zone, when DNSSEC appears, be done right and that 
this be done cautiously.  So 2009 is a goal.
		And thank you very much.  
		(Applause.)
		
		RICHARD LAMB:  Testing.  Okay.
		All right.  Let's see.  Okay.  My name is Rick Lamb.  I 
work at ICANN.  I'm in the DNSSEC program manager.  Let me 
describe some of our work.  The nice thing about being the last 
guy, there's not a lot I have to say at this point.  That's good.
		The road to signing the root has been a difficult one and 
I'm not going to cover much of this.  The main points I'd like to 
make is getting to this point required the work of a lot of people, 
and there's a lot of people that I have to thank.  The trailblazing 
work by .SE.  So many things were kicked off from that.  If you look 
at the .SE design, there's a lot of similarity.  The consistent 
pressure from the community, the IAB, IARs, many others.  This, 
without these pressures, we would not be where we are today.  
And that's just a short description, short time line of what things 
happened.  
		We all have to bow to Kaminsky.  He helped us all in so 
many different ways by raising the visibility of this thing in so many 
different venues.  As Matt said, there were DOC requirements. 
Right now I call it intense cooperative effort because we're 
shooting for 2009 and we're working really hard to get things 
together.
		And from our new CEO's point of view, he recognized 
it's really important.  Rod Beckstrom came out, and said based on 
his experiences, personal experiences, cyber security effort, this is 
actually very important to him.  It's been taken off the ICANN web 
site but it's very important to him.  
		Before I leave this slide, I have to emphasize the 
cooperative effort I've had from everybody in the DNSSEC expert 
community.  It's amazing how helpful you are, and how open you 
are with things.  So many thanks.
		All right.  I'm going to skip through these quickly.  Just, 
it's been said, but DNSSEC does not solve everything.  It does not 
solve all the ills, or some of the social engineering attacks like 
check free, does not insure the accuracy of content.
		Again, it's, this is old stuff for you, all you guys.  But it 
does solve the cache poisoning incident, and one of the bigger 
ones that had a lot of visibility, and as well as the Brazil banking 
situation.  And one of the things I'd like to point out, oftentimes 
people say, what about SSL?  They're complementary.  They solve 
two very different problems.  So to quote a wonderful affiliate's 
paper I saw, the answer is simple.  You do both if you actually 
want to take full advantage of security.  So they are two very 
separate issues.
		All right.  Now my part of the talk here, it's what does 
signing the root do?  Why do we care?  It removes barriers.  And 
not just simplicity.  Having one root key to the system makes the 
thing all simple for all the ten million plus resolvers out there to 
configure things, but it is also allows for compromise recovery.  So 
if a TLD has a key that's been compromised, here's a way, here's a 
very simple way for them to be able to change that just by sending 
IANA a change key.  It also allows them to unsign something, if 
they have to.  There's a certain amount of flexibility by having a 
signed root, as opposed to multiple TLDs.  That's, you know, one 
of the things that's going to aid deployment as much as possible.  
		We also want to lead by example.  So again, ICANN is 
being one of the managers for the root.  We've really focused a lot 
on DNSSEC at the root.
		All right.  But, wait, there's more.  There's a lot more 
that we can have with this.  One of the things that Kaminsky and 
others, as well as this community has for sometime, folks have 
done in the past, there's a lot more to this.  Getting the root signed, 
there have been so many attempts in the past, to try to create a 
global authentication systems.  There have been so many PKIs.  
Passports is one example.  I worked in the state department many 
years ago, and one of the things I worked on was trying to get 
multiple countries to agree who is going to be the root.  That does 
not happen.  That never happened.  So those PKAs never, they  -- 
it's impossible.  It's been tried, but no one has been able to come 
up with a global authentication system like that, single point like 
that.  And it's been -- I think with the passport system, they finally 
spoke to one of the UN organizations up in Montreal, and they 
have a list of keys from about seven countries.  So it's a difficult 
problem to solve.  lt's, people like Microsoft and others have tried 
to do this, with their Passport product as well.  So they've tried to 
solve this problem.
		But we're in a very interesting place right now.  As you 
can tell, the root is going to get signed.  That removes this 
fundamental barrier to a global infrastructure that we have, and 
global PKI.  I don't want to use that.  PKI and DNSSEC are 
different things, and we purposely treat them differently.  But to 
quote Kaminsky again, the K -- the DNS adds the K to PKI.  DNS is 
already trusted infrastructure.  It's sometimes trusted too much.  
There are people that use it often times to actually validate when 
you ask for a new account.  You get an e-mail to check to see, did 
you ask for this account.  Well, that's relying on DNS.  And 
sometimes some of these certificates, the SSL certificates also rely 
on DNS.  So it's already an infrastructure that the world trusts.  
And throwing DNSSEC on this gives us a wonderful opportunity, 
an alternate source of authentication that we can use for all kinds 
of things, new platforms, new products. 
		But the point of all this is, the genie is out of the bottle.
		Once the root is signed, there's no going back, in a 
sense that there's going to be some complaints about, no, if we do, 
if we sign the root in the trustworthy fashion, which I think we will 
be, we've been working very hard to do this as securely and openly 
as possible.  We're going to end up with something that is going to 
solve, offer solutions to a whole host of problems.  Certainly there 
will be creative destruction along the way.  There will be new 
products.  There's a huge industry out there that sells anti-spam 
equipment, all kinds of stuff and there's going to be some pushing 
and tugging there.  But DNSSEC, and particularly now that the 
root will be signed, is going to offer a whole new range of products 
that we can now take advantage of.  
		And it's been envisioned for many years.  That's an 
example of some of the fine work that IETF has done in this space.  
And to quote some lines out of -- there's a White House report on 
cyber security that's out there.  I mean, there's been a lot of talk 
about cyber security in the political space lately, but almost every 
one of them -- in the White House report, we cannot improve cyber 
security without improving authentication.  So a lot of these guys 
have recognized the importance of being able to have some sort of 
authentication.  
		This certainly is not going to solve everything.  I'm 
never going to say that.  It is a start.  And it is, it's, I think it's the 
only source of a completely cross organizational, you know, 
international source of authentication that we will be, on a platform 
authentication that we can have.  And so that's my key point in this 
talk.
		One of the -- just to keep this short, so it's happening.  
It's a tool.  Test it.  In fact, if you type DNSSEC in IANA, we've 
had a test bed running for at least two years.  It uses the highest 
security level crypto devices and has a couple of open resolvers.  I 
know it's a bad thing, but it's a test.  Couple open resolvers, try it.  
If you go to one of those sites, you'll see there's nice pieces of 
codes there from Andre (inaudible) from Dot CZ that show a lock 
on, or not a lock, depending on whether or not you're using DNS 
SEC or not.  That's cool.  I have to thank him.  
		This is a rare opportunity we're at.  I think, not everyone 
recognizes that what we have here is something that beats all, as 
far as another source of authentication.
		And I just want to leave you with that statement there.  
It does clear the way, you know, for not just fixing the DNS, which 
is what we all want, but also opens up this platform that we can all 
cooperate on and build new products.  And I would very much like 
to see the industry pick up on this and try to take advantage of 
this, come up with products, try to help us all.  Anyway, that's it.
		
		( Applause.)
		LESLIE DAIGLE:  Okay.  Thanks.  So we are running a 
little long, but I hope you'll agree with me, it would have been 
pretty hard to find some material to cut out of that, in terms of real 
practical activities.
		Now, I do want to take the time for a question or two, 
before we all run away.  And I see hands over there, but Monika, 
do you have anything that you wanted to ask, or are you good to 
go?  
		MONIKA ERMERT:  So, I'm Monika (inaudible).  I'm a 
reporter.  It's funny that I get the first question.  You don't know.  
Usually I get the last one.  
		LESLIE DAIGLE:  That's how you know it's not an IETF 
meeting.  
		MONIKA ERMERT:  From all the questions I have, 
perhaps what I find interesting, what Rick just said, that we have 
now this platform for authentication that could be used for anything 
else, and would be better accepted than other things.  How sure 
are you that this system, which still is a system that is positioned in 
the U.S, will be accepted by all the government that you talk about, 
would not be willing to sign up to this, let's say UN certificate stuff 
for other certificates stuff?  And that perhaps falls for both, for 
everybody of you.
		
		RICHARD LAMB:  The layer 9 aspect of that I cannot 
address.  And maybe I did not make it clear.  In these other 
systems, the systems were designed, top down.  So first, there had 
to be agreement, various political parties to come together, and 
then build a system.  Of course, that's doomed from the start.  And 
so, in this case, I think we're very lucky, because, now we have a 
bunch of engineers in the room trying to actually solve the 
problem.  And we've gotten this far.  And we're going to have, we'll 
have something.  We'll have this, we'll have a signed root and 
that's, once that's there, people can start building on it.  TLDs are 
free to do whatever they want.  I think that's something I probably 
didn't make clear, but this is from the bottom up, as opposed to top 
down, and very little politics.  
		JIM GALVIN:  Can I add to that?  I think an important 
distinction is that the DNS is actually in use, and there today.  And 
the Internet depends on it.
		You know, the PKI technologies that were developed 
were all about supporting new applications and new technologies, 
so you needed acceptance of those things as well as the PKI.  The 
DNS is already well accepted and so now we're adding the security 
services to it, and that, I think is a very important reason for why it 
would be more readily accepted than PKI ever was, and hopefully, 
it will begin the development of new applications.  
		PATRIK WALLSTRÖM:  And somebody said, 
countries that don't trust the roots, they trust the TLDs, so they can 
put them into the their applications.		
		LESLIE DAIGLE:  Okay.  I think we have another 
question.
		
		VASILY DOLMATOV:  I'm (inaudible) council member.  I will 
note I will not discuss political statement of Richard Lamb.  I 
should discuss (inaudible) but I would like to bring your attention 
too, one more piece of work for deployment of DNSSEC which 
was set aside in all the presentation.  There are some countries 
that are using cryptography already, and they acknowledge that 
platforms should be available to harmonize with the regulations, in 
order to, these countries be able to deploy DNSSEC and to use it, 
and to use all these protocols.  I would like to bring attention of 
IETF people and others, people working in DNSSEC field, that this 
field is sometimes underestimated until DNSSEC is started to be 
deployed.  It is like not (inaudible) so it's now, it's just the time to 
(inaudible) to make protocols and technologists available for this 
situation, with some regulated, some additional regulations 
(inaudible).  
		LESLIE DAIGLE:  Thanks for that.  I think that was an 
important contribution to identifying some of the pieces that will be 
worked through, as we actually get to the point where more of 
these things go live.  I don't know if any of the panel would like to 
speak to that or consider it contributed.
		Okay.  Ted?  
		TED HARDIE:  I just want to make sure that I'm not 
speaking to the council.  
		LESLIE DAIGLE:  And you are?  
		NEW SPEAKER:  Ted Hardie.  
		OLAF KOLKMAN:  Who is also not speaking with any 
hats on.  
		TED HARDIE:  I have to say, I loved your 
presentation.  It was so polite.  Let's face it, the first egg was 
eaten.  The second chicken was stolen by foxes.  The third one 
had its wings broken by tussles between applications registries 
and (inaudible).  You put forward your wonderful metaphor, but 
you've taken off all the things that MONIKA might have written 
about.  How unfair of you.  
		OLAF KOLKMAN:  In fact, I thought about putting the 
alternative bend to the future story, which is Kentucky Fried 
Chicken.  
		
		TED HARDIE:  We actually do have a problem here.  
You show what we've got here, a very, very proud rooster.  But we 
do have a problem, and that is, how do we keep it from heading 
towards rooster instead of becoming a capon?  For those of you 
who did not grow up in farms, that's a rooster that ceases to be 
one.  And the big issue is applications developer.  There's a huge 
amount of work in getting from the ISP does this, to the application 
does this.  And there's a huge resistance to it from enterprises.  
Because let's face it, we've gotten to a world where split DNS is 
pervasive and where enterprises use split DNS not just to control 
what's requested within their own domain but to lie to the people 
who are in the domains, about what the zone maintainer intended.  
		So my big question to the panel is:  Is Kaminsky 
enough to scare us out of split DNS?  And if it isn't, what will be, so 
we can get our cockerel to grow into a full size cock.  
		LESLIE DAIGLE:  So --
		OLAF KOLKMAN:  That last phrasing still is -- 
		LESLIE DAIGLE:  While Olaf is collecting his thoughts, 
I'd like to, I'd like to leap in a little bit here and remind people, part 
of the reason we're having this session at all, although certainly 
the history has been a little rocky, I think the fact that we've got, 
you know, serious infrastructures operators here, operators talking 
about what they're actually doing in their business livelihood, not 
just research departments, is at least an indication that we have 
momentum here.  So I don't believe that we have ever in any 
technology developed in the IETF solved all the problems on the 
drawing board.
		So, I'm excited if the panel can really address your 
question with an answer, but I would reiterate that the important 
thing is to get motion here so we can course correct.  
		OLAF KOLKMAN:  And in that sense, there's very little 
to add to what Leslie just said.  We are in this deployment 
development standardization cycle.  And there are a few tough 
nuts to crack.  Ouch.  I didn't mean that.
		
		LESLIE DAIGLE:  Maybe we'll move on to the very last 
question.
		
		OLAF KOLKMAN:  Seriously.  There are tough 
questions.  There are tough questions in deployment.  No doubt we 
will find, as a community, when we deploy any technology 
developed, within this ecosystem, we'll find corner cases where the 
Internet is just not really the Internet as we thought it was.
		And walk into those boundary conditions and we need 
to think about how we can adapt for (inaudible) of the current 
networks.  And that's a challenge.  That's an ongoing challenge 
which we need to be open about, as the standardization 
organization that's meeting over there, but also, as a bunch of 
developers and people who deploy technology.  So, let that cycle 
continue.
		
		LESLIE DAIGLE:  Okay.  Then, this will be our very last 
question, and I thank you all for your patience in sticking around.  
		NEW SPEAKER:  Okay.  It's not about chicken.  
		LESLIE DAIGLE:  And you are?  
		NEW SPEAKER:  (Inaudible) speaking as an individual.  
And so, we've been seeing people talking about signing.  However, 
you know, to me, the other part is validating the thing.  What is the 
plan, for example, for ISOC or others to make sure that someone, 
you know, all the parties interested are actually validating that 
data?  Because it seems to me that we can do a lot of parties 
signing data, but if no one is validating, there's no use.  Anyone 
has any plan to make sure the providers and all the parties 
involved will actually validate the data?  
		LESLIE DAIGLE:  Since you invoked ISOC in that, there 
are -- indeed, we didn't talk about that on this panel.  There are a 
variety of activities that I think were alluded to under the rubric of 
education, and you know, support for making sure that entities that 
have to know what they need to know in order to take this up, and 
run with it, one of which is, there is a DNSSEC coalition that .ORG 
is organizing and corralling, and a lot of the work they're doing is in 
terms of education, messaging, et cetera.  
		Anyone else?  
		PATRIK WALLSTRÖM:  .SE has been actively 
working with resolver operators, so in Sweden, all the major 
resolver operators are using the trust for validating.  
		LESLIE DAIGLE:  Okay.  Then I will say thank you very 
much to the panelists, and thank you all very much for coming.  
		( Applause; end of session.)