DNSSEC Workshop
Wednesday, 8 December 2010
ICANN Meeting
Cartagena, Colombia.

 >>JULIE HEDLUND: Good morning, everyone.  This is the DNSSEC
workshop, and we hope that if you're anywhere near this room, that
you'll come on in and take a seat and we'll be starting very soon,
and welcome to those who are here.

 There are programs down in front and we encourage you to sit down
in front so that you can have a good seat and a good view.

 So everyone please come on in and join us and we'll be starting
shortly.

 Welcome, everyone.  This is the DNSSEC workshop.  Very pleased to
have you here.  If you can hear me and you're not in the room and
you're outside the room, please come in and join us and we do have
some programs down in front, so please pick up a program and we're
very glad that you could join us and we're going to go ahead and get
started because we have a very full program today and we want to keep
everyone on time.  Thank you.

 >>STEVE CROCKER:  Good morning.  My name is Steve Crocker.  It's a
pleasure to welcome you here.  I see we have a very large room and
only a modest number of people, but I'm hoping and expecting that
we'll have more join us incrementally.  Fortunately I'll be talking
for a few minutes and mine is the least interesting part of the
overall program.

 The program committee is in front of you but before I mention them,
I want to give a little shout out to our extraordinary scribers Laura
and Teri working from a distance.  This is a first-class team that
I've had the privilege of working with and observing over several
years and they just do an amazing job, and I think we all just sort
of take it for granted that we can just look at the screen and see
the translation of our words, no matter how indistinct our words
sometimes are.  So I'm -- it's really quite excellent the work they do.

 And speaking of excellence, we have evolved a program committee
over a period of time that has also been a first-class operation. 
Markus Travaille from SIDN -- raise your hand, Markus -- and Simon
McCalla from Nominet.  Where's -- down there.  Russ Mundy.  There's
Russ in the front row.  Julie Hedlund to my right, and I'm Steve
Crocker.

 We have -- we've put a lot of work into these.  A standing call
once a week, and just a tremendous amount of energy to work out all
the pieces.  And then of course an enormous amount of cooperation
from you.  Last time and this time we've extended the session from
our traditional morning to include the afternoon and, in the process,
providing a lunch which is sponsored by a really broad range of very
active companies that are -- are just been easy to work with.  I sort
of sent out the note, pass the hat, explained, and the checks come
rolling in.  It isn't a huge amount of money but it's necessary and
makes this go, so I'm appreciative of Dyn, of Comcast, of Go Daddy,
SIDN, .se, which is also supporting the open DNSSEC work and I think
that's cosponsored by others.  Nominet.org.  

 So really an all-star cast and I'm expecting, actually, that list
will grow a little bit over time as we do this in the future.

 Next slide.

 So what we're going to cover today is I'll give a capsule view of
deployment and then we'll have a panel discussion on best practices
on the stimulation of deployment of DNSSEC in the ccTLD and gTLD
communities.

 Markus Travaille will moderate that, and we have an extensive
panel.  I'll let him introduce everybody at that time.

 Roy Arends will give a talk on incidents and responses, and in
particular a visible event that caught everybody's attention.

 Roland van Rijswijk -- I know I'm going to screw this up -- van
Rijswijk?  Is that close?  Close enough, thanks.  From SURFnet.  He
will give a talk on lessons learned from DNSSEC deployment, and then
we'll move into a session on tools, open source tools.

 Russ Mundy and João Damas from Internet systems consortium on
DNSSEC for humans on the next development in BIND.

 Then we'll move on to a panel discussion on implementation
approaches, best practices on a variety of DNSSEC deployments around
the world.  

 Simon McCalla will chair that, and the number of quite excellent
talks in rapid-fire order.

 Don't be -- don't be put off by the numbers there.  It's all very
tightly organized.

 Then next, let's see, there was a 7 missing which I think is lunch,
right?  Right.  So after lunch, we'll have a remote talk from Jason
Livingood at Comcast on ISP validation capability.  Comcast, a major
ISP in the U.S., has put DNSSEC validation into their system and
taken a very leading position on that.

 And then we'll close off this lengthy session with a portion that I
always look forward to very much, which is a focus on activities from
around the region.  The developments here in Colombia, a survey of
activities around the entire region conducted by LACTLD, and then Ram
Mohan from Afilias, which is providing the back end for several of
the ccTLDs in the region that have recently been signed, and then
Frederico Neves from the Brazilian operation, NIC.br.  So that's what
we're going to cover and now I will say just a few words about two
specific things.

 I've been keeping track, as best I can -- and the events are
getting ahead of my abilities to track it, actually -- of the
deployment of DNSSEC particularly in the ccTLD community but also
tracking the rest.

 So I've got a series of maps that will be a kind of poor man's
animation that are at three-month slices for this year, 2010, and
then a projected jump through the end of 2011.

 Next slide.

 So this shows the information that we have as of the end of March,
March 31st, this year 2010.

 We've evolved a very compact set of four questions that we ask to
track the status and projected plans among TLD operators.  One is: 
What date did you go into -- to begin experimenting?  This is often
not so visible to the outside world because it could be just
laboratory experiments, and in any case, it's not visible to ordinary
users because they haven't put it into the root or anything.

 Those countries that are in that state as of the end of March, but
not in a more advanced state, are shown in yellow on this screen.

 The next state is a -- not a technical state but is a description
of the degree of commitment, and it's:  When did you -- or when do
you, if it's in the future -- plan to announce that you will
eventually have full operation of DNSSEC.  That's not the date of it
happening; it's just the date of a formal public commitment to that.

 So that's shown in -- depending upon your preference for how you
name colors -- orange or light brown, and I hope that there are
people who have a better sense of color than I do.  I'm sure there's
a name for that color.

 And here we show the U.S. and Canada and Australia, for example,
and Japan and France that I see quickly in that state, again, as at
the end of March.

 And the green is when there's actual signed operation, at least at
a partial level.  So this could be that the zone -- the zone is
signed but not yet taking registrations or some other definite state
of being in partial operation but short of full operation.

 And then finally blue is full operation, taking registrations or
taking key information from registrants up through registrars,
usually, and here we see that Brazil and Namibia and Sweden, among
others, were in that state at the end of March.

 So with that as the description of the colors, I'll march through,
as I said, at quarterly intervals here.

 So the next slide shows the end of June.  Actually, Julie, back it
up, if you would.

 And now just step smartly through this, sort of boom, boom, boom.

 Good.  So now back it up, if you would.  Thanks.  A little bit more.

 This is good.

 So here's the -- that's March.  Let's go forward.

 This is June of this year.

 Next one is September of this year.

 And the next one.

 So this is the end of this year.  This is the projected state,
essentially as of now.  It's projected to be the end of December but
it's essentially now, so there's a substantial amount of blue and
green with -- and more to come, obviously.  And now, jump forward to
the next year and now you see yet more.

 I believe this data is -- actually understates the situation and
that there's actually more good news than that, and then of course
because this is geographic presentation, there's a disproportionate
visual effect for the countries with large land masses, and in areas,
for example, in Europe where there's quite a few countries and it
doesn't show up with as much detail.

 Anybody have better mapping skills than I do, I invite you to come
up and help me out here.  We'll be happy to merge the data with
better maps.

 Next slide.

 This is the same information presented in -- to show all that data
over time, and I -- as I say, I think that the situation is actually
slightly better than this, but what we will see here -- what we see
here and what we'll see over a period of time is a very distinct set
of trends towards marching upward, and I think that -- so this tops
out at about 50, but I think the next time that we put these slides
together, the numbers, including all the ones that are in
experimental mode, are probably going to be perhaps half again as
high as that.

 So that's the -- the information that we have on the adoption rates.

 It's all quite substantial, compared to the hopes that we had when
we started several years ago, so things are rolling along.

 It's also, of course, if you want to look at it from a glass-half-
empty point of view some distance you have to go, but I'm hopeful
that we'll see over the next couple of years a very steady rise in
these numbers.

 Next slide.

 So a different set of measurement issues is, it's all well and good
to have zones that are signed.  Is anybody actually doing any
validation?

 As expected, this is going to take longer and is in much earlier
state, so we're just at the infancy, the very, very ding of the
process of actually having queries that are -- where validaters are
asking for signed answers and making use of them.

 So next slide, please.

 So as we said, TLDs are getting signed, registrars and registrants
still in the very early stage, resolver software is moving along
relatively well.

 Deploying resolvers in the field is still very early days.  Telia
in Sweden was rolled out as part of the whole early rollout in Sweden
and took a very leading position.  Comcast in the U.S. has taken a
very forceful role.

 But the actual validation is still in very early days.

 Next slide, please.

 So there is a small subtlety, in that a number of resolvers are
automatically requesting signed responses, but only a very small
fraction of those are actually being checked.

 So they turn on the bit asking for a signed answer, but they --
when they receive the signed answer, they don't actually do anything
different from treating it as an unsigned answer for most of them.

 So from an authoritative servers point of view, if you are tracking
how many queries you get that are asking for a signed answer, it
looks much more substantial than the actual facts of the situation
warrant.

 So the question is, is there a way to tell which of those requests
for signed answers are likely to be actually validated.  And the
answer is, yes, look at those requests which are for the keys. 
Because if the clients are not requesting the key, then they can't
possibly do the validation.  And if they are asking for the key, then
it's almost certain that they intend to use it for validation.

 Next slide, please.

 So when we measure that, we need regular measurements in place.  We
don't have all of it in place, and others are working on the same
thing.

 We have been working, my company, Shinkuro, have been working with
PIR and Afilias which run the dot org zone.  So the following slides
show the fraction of total queries and answers that are for keys.

 The measurements are taken at multiple locations; that is, Afilias
runs name servers in different points around the world that respond
to requests for dot org.  And so those are samples taken from those.

 The samples are typically runs of 30 to 40 minutes, which cover
tens of millions of queries.  But what we're going to show in the
next slides are the fractions of those that are asking for keys.  And
they will be very small numbers, as one would expect.

 Next slide.

 So the queries -- the key queries are in the range of 1% of 1% or
less.  And there is some variation with geography.  There is also
measurable changes over time.

 As I've said, the actual use is quite small.  On the other hand,
the good news is that there is actual usage and that it's measurable.
So we're getting the needle to move off of the pin, as it were.

 Next slide.

 So this is first crude results.  The multiple colors represent the
different locations.  It's too small to read, I think, but there is
Miami and Amsterdam and Seattle and Toronto and -- what's the other
one?  Hong Kong, I think.

 And there's pairs of runs at each of those locations.  And the data
that the -- the axis on the left, the Y axis, are the fraction of
queries that are for keys.  And the variation in the vertical results
is the differences from -- in geography as to what fraction are being
asked for.

 And then over to the right is a different date.  There's two runs
at each place, so in some cases the data is essentially the same and
is overlaid.  In some cases you see two different triangles.

 The -- But the interesting thing, at least from my point of view,
is that there's a slight upward trend even across those two dates.

 Those are for the requests for the keys, and the next slide -- is
there a next slide?  Yeah.  Those are responses.  We have slightly
different runs there.  Data collected from the same places on a
variety of different dates.

 There's no -- I don't present these results as if they are
meaningful in their own right or that there's much stability to them.
Simply to give a flavor as the beginnings of a measurement process.

 And without question, to stimulation discussion, to invite
interaction.  Anybody who is doing a better job of this, feel free to
jump in.  But I think this will be an increasing trend over the next
many months to build up a more coherent and more reliable and
repeatable measurement system.

 Frederico.

 >>FREDERICO NEVES: May I suggest that we measure the relationship
or the rate of -- on a delegation-centric zone like dot org from the
NS queries or the referrals and the DS ones, not the keys.

 >>MARKUS TRAVAILLE: Interesting.  Interesting.  Well, I think we'll
want to actually measure all of that.  There is no reason -- I don't
see any need to be restrictive.  As I say, this is early, and as we
flush it out, and as others, it will be interesting to see the
relationship of all of those.  But of course that's a very good idea.

 Thanks.  Are you doing measurements in that as well?  Yeah, good.

 So over time, as a community, we'll get together and bring this up.

 Let's make a point of discussing this even more when I have the
pleasure of visiting next month.

 Yeah.

 Good.

 So that's the end of my initial remarks.  I think that's the end of
the slides.

 Yes.  Onward.

 And so thank you very much.

 Any questions or comments?

 Okay.  Thank you.

 So let's move forward with Markus, your panel discussion.

 >>MARKUS TRAVAILLE: Thank you very much, Steve.  Ladies and
gentlemen, welcome to the first panel in this DNSSEC workshop about
adoption of DNSSEC in registries, registrars, ccTLDs, gTLDs.

 I'm very happy that we have been able to put together such a great
panel of people from registries and registrars who are willing to
share their view and also maybe share best practices and how to
market DNSSEC and to achieve more adoption.

 When I prepared this panel with the panelists, I really asked them
not to put any technical language in their story, so we are trying to
avoid DNSSEC technology.  We are talking about adoption here.

 Technology will be discussed later in the session.

 So please let me welcome the participants.  We have James Bladel
from GoDaddy on my left, your right.  We have Matt Mansell from Mesh
Digital, Domain Monster sitting next to James.  And then we have
Julie and myself.  And then we Pavel Tuma from the Czech registry,
Lance Wolak from dot org, and Chris Wright from AusRegistry.

 All of them will make a short presentation on where they are and
what they are doing about adoption, and then we get to a discussion.

 I really invite people in the room to participate.  And let's have
a debate in the next hour about best practices on DNSSEC adoption.

 James, please.

 >>JAMES BLADEL: Thank you.  And while we wait for the slides to
come up.  These are available on the Web site, so I won't belabor
every single bullet point, but just kind of give you an overview of
our progress in making DNSSEC available to our customers and
providing some interesting tools.

 Next slide, please.

 So included here is a quote from our president and CEO in including
DNSSEC in our overall company strategy.  And I think the key take-
away here is that it's the right thing to do for our customers and
it's the right thing to do for the larger community.

 Next slide.

 As we discussed in Brussels, we are taking a two-phased approach to
DNSSEC rollout.  The first that we announced during that ICANN
meeting was DNSSEC record management.

 This allowed registrants who manage their own DNS servers and
wanted to manage their own DNSSEC set keys to kind of -- this is more
of a self-service type product offering.  It was a free service that
would involve us transferring those keys and passing them through to
the registries that were supporting them.

 What we announced is that there was a future product on the
horizon, and I'm pleased to tell you today that this is launching
here imminently, I think within a matter of days, as our premium
DNSSEC offering which is an end-to-end DNSSEC solution for our
registrants.

 Here is just kind of an overview of the self-service tool.  It
allows customers to attach DNSSEC information to their domain names
which we would then forward on to the registry.

 The DNSSEC is an even simpler interface.  It's not coming across
very well on the slide, but it's as simple as having a DNSSEC on/off
switch.  So customers who have no particular interest in the behind-
the-scenes technology of DNSSEC can simply flip that switch and then
enjoy the benefits of a secured domain name.

 Behind the scenes, of course, there's quite a bit more work
involved, and there's a list there of the bullet points of all the
operations that GoDaddy provides for the customers under this service.

 Next slide.

 DNSSEC is certainly the highlight of this premium DNS product, but
it's not the only feature.  There's a number of other benefits to
adoption of this.  And it's -- But I think that the key message here
is that it does include a very simple DNSSEC feature.

 Supported TLDs.  We have some that are available now, and I think
that those are well-known.  There are a few coming early in 2011, and
I think this segues or dovetails with Steve's presentation.

 I wanted to point out that our sponsors, dot CO, for this
particular meeting, have also announced their plans in 2011, and we
are working very closely with them to make sure that we have that
available when it's ready.

 So, you know, I don't want to spend too much time on this, and
yield back the balance of any presentation discussion for the Q&A
later, but that's an overview of the progress we've made since
Brussels where we announced our initial service.  We have come a long
way since then, and I think by the end of this year, it's just going
to be a matter of adding the new TLDs as they sign their roots as well.

 So thank you.

 >>MARKUS TRAVAILLE: Thank you very much, James.  I think you had a
very clear message, like keep it simple and don't bother the end user
with DNSSEC, and sell it as a premium service.  So it's a very, very
nice message.

 We get back to that later.

 I would like now to give the floor to Matt Mansell.

 >>MATT MANSELL: So I've taken a slightly different approach on
this.  When being advised onto the panel to discuss this, I think it
was made quite clear to me that it was important that we talked about
challenges in developing a DNSSEC product.

 So rather than tell but the product we have, I've taken some time
to give you some of the considerations that we made.

 So let's kick off straight away.

 I think the first and most important point that we wanted to make I
think is that it has to come at a price.

 There's no two ways that we operate in a commodity industry.  And
so, therefore, the costs associated with this are going to need to be
passed on or absorbed.  But there are definitely costs that are
included.  And whether you are DNSSEC aware or not, I wanted to
highlight some of them.  So there's a potential hardware overhead,
there's a very small bandwidth overhead for the trust verification
and for the extra data.  

 The support overhead could be significant.  This is a complex
subject and it requires a different skill set of people to be able to
deal with.  So that comes down to ISP hardware that will need
troubleshooting, key renewals that will complicate things, very
subtle registry differences.  The provisioning can be complex, and
the sales overhead could be costly.

 So I wanted to start with the bad news, really, that it has to come
at a price.

 And really answer two questions.  Is it impossible to market or is
it easy to market?  So we'll start with the impossible to market point.

 I guess the point I want to make here is that what I am about to
talk about in terms of it being impossible to market relates to
everything we know in this room as DNSSEC, whereas the general public
don't care.  They don't care, as Roy from Nominet explained to me the
other day, they don't care what's in the engine.  They just want to
be able to drive the car.

 So some of these points, I think you will see very few people
communicating to the general public.  And I will talk about that when
we talk about easy to market.

 I think I am yet to read an easy guide to DNSSEC, and I think this
week was possibly the first week ever, through the session that was
run the other day, where I have actually seen a session where people
could relate DNSSEC by the blue-smoke analogy that Nominet gave.

 Other than that, I regularly see things like "Let me explain this
so you can understand" before it dives off into the details of keys. 
Or don't let your eyes glaze over with cryptography.  They are very
complex guides.  They start very light and get very hard very, very
quickly.  

 At best, you will get an explanation of resource records and
delegation signers.  At worst, you are having an explanation NSEC or
NSEC3, or you are trying to explain so someone why nonexistence
should be proved or you explain the difference between key signed
keys and zone signed keys.

 So that's the bad news, I guess.  If we were going to market it
using the current explanation of DNSSEC, I think it would be a big
challenge.

 And the good news is that potentially it could be easy to market.

 Can we just go back a little bit, please.

 Maybe the fourth slide, I think.  Could you just skip straight to
the fourth slide.

 So I guess what the fourth slide was going to say, once we get to
it, thank you, all right.  Keep clicking.

 So I guess the fourth slide was simply going to say, and I have got
it in front of me here, actually, and we will keep clicking to get to
it.  Maybe you can take care of that, Julie.  Is that there's kind of
two categories of people.  There's the retail users, that ultimately
are ignorant to the requirement.  They only just understand padlocks.
Can we see if we can get it up on screen?

 There we go.

 I'll put it down.  You push this through.

 They only just understand padlocks, and I guess that's the average
end user.

 And they are now just start to go learn about extended validation. 
That little green toolbar that's at the top.

 And actually today, out of the hundreds of thousands of customers
that we have, I'm not actually aware of one single inquiry where
someone has actually contacted our customer service team and said, "I
have heard about DNSSEC.  I'd like it."

 So I think there's a definite challenge there.

 You're fighting it with it there.  Can we just leave it in
PowerPoint mode, maybe?  Just leave it in PowerPoint without going
into slide show.  That will do.  Just on slide 4.  That will do.  We
can all see that.  That's fine.

 So, you know, I'm not aware of a single inquiry.

 So that's the retail side, the end-user side.

 On the corporate side, you know, I think they will be more aware. 
But not many of them are aware right now.  We all think they are.  We
all think it's very important to hotels, we all think it's very
important to banks, but right now it's not come up on most of their
radars.  And when it does come up on their radar, they are going to
want it to just work, they are not going to care how, and they are
going to be very happy to pay a premium to effectively stop DNS
phishing, which is a simple explanation of what DNSSEC solves.

 So potentially, is it easy to market to those two sets of people? 
Well, it could be difficult if we explain it to them as DNSSEC.

 If we can slip to the next slides.

 So we see basically two models evolving, both being chargeable
products.

 The first model on the retail side is very simply an upgrade to
security plus for X dollars.  And we see that as DNSSEC wrapped in
with maybe Two Factor, maybe wrapped in with SSL, maybe wrapped in
with privacy, change logging to account access, maybe even an
extended validation when the original domain is purchased as a
premium product from the registry.

 So wrapped into a security-plus type product.  We don't see us
going to your average end user and saying, "Hey, come buy DNSSEC."

 We see, "Hey, come buy security-plus, of which DNSSEC will be a
part of that."

 And then we see a corporate model which is add DNSSEC for X dollars
because your average I.T. manager is going to want to buy what he
knows, and that is DNSSEC.

 So that's really how we see DNSSEC developing.

 Thank you.

 >>MARKUS TRAVAILLE: That you can.  Thank you, Matt.  I think it was
a very interesting presentation.

 Let's go over to Pavel Tuma from Czech registry.

 >>PAVEL TUMA:  Anyway, thank you, Markus, for the presentations.  I
think we are moving forward and the presentation will be ready today.  

 Instead of saying we have more than 100,000 domains -- dot CZ
domains, DNSSEC has secured and how we got there.  I wanted to do a
short teaser for the following panel discussion, a provocative
question of:  Is there a demand for DNSSEC?  

 So is there a demand for DNSSEC?  First, let me remind you that bad
things can happen.  "I had a Czech Dream" is a story of two
filmmakers who created a fake supermarket just to see what is the
power of advertising.  So please roll the clip.

 (Video playing).

 >>PAVEL TUMA:  So that was just a sample of it.  And they did
really well because the advertising campaign they created for this
fake supermarket was really enormous, billboards, city lights, flyers
all over Prague.  And it was really smart because they didn't tell
anything directly.  The message was not clear.  They didn't promise
anything, so they couldn't be sued in any way.  But you probably can
imagine what happened at the end of the clip.  The people are very
angry, some of them were even aggressive.  And it created a
nationwide discussion about how could they do it, the morality of it
and even the financing because a part of the budget was provided by
the government fund for cinematography.

 So is there a demand for security?  Anybody in the auditorium who
uses the antivirus software?  I think it would be a lot of hands. 
Same for the firewalls.  There are a lot of security tools, malware
detection, SSL, anti-phishing in the process.  And this is -- this is
really a multi-million dollars industry, so is there really no demand
for the security or is it just about the awareness?  

 Take, for example, the average Joe user.  He sends and receives the
e-mails.  He reads the news.  He is on a social network.  He pays the
bills.  He uses a lot of other important services.  And I don't think
he will choose to stay insecure if he is aware of what a threat is,
what consequences there are of the DNS abuse, that he can lose the
passwords, that he can lose the accounts, he can lose the image, he
can lose money.  I don't think he will choose to stay insecure.

 What we see of the security of the DNSSEC particularly is a
feature.  It is not a service.  Imagine a car without safety belts. 
How many of us would buy a car without safety belts?  And how
successful would the car vendor be selling the car without the safety
belts now?

 So this is a sort of what I call DNSSEC food chain.  We as the
registries are on the right.  And what we think the best way -- how
to increase the awareness of DNSSEC is to start right on the left
with the end users, with the average Joes like this one, because if
he is aware, he will demand the security from his ISP, from the
domain owners, from the services he uses.  And then these domain
owners will demand DNSSEC from the registrars and the registrars
will, of course, demand the DNSSEC from the registries, and the
circle will be closed.

 So that's just the direction we wanted to go in the near future. 
And let's discuss that in a panel discussion later.

 >>MARKUS TRAVAILLE:  Thank you, Pavel.  I'm curious if we can find
a YouTube stream of this movie, where?

 >>PAVEL TUMA:  I think so.

 >>MARKUS TRAVAILLE:  Okay, interesting.  Then I give the floor to
Lance Wolak from dot org.

 >>LANCE WOLAK:  Thank you, Markus.  I have some introductory
remarks.  So I will give Julie some time to get the slides up.  

 Good morning, Lance Wolak from dot org, the Public Interest
Registry.  I'm very pleased to be here today.  Thank you.  As you
know, PIR is teamed with Afilias as its registry services provider. 
While PIR was involved in all the planning details which led to the
production launch of DNSSEC in June, we've moved forward with PIR
taking on a large marketing role with DNSSEC with full confidence in
Afilias to manage the technical operations, including the DNSSEC
enablement of our registrars.

 So about a month ago, we launched a campaign to raise awareness for
DNSSEC.  We're using PIR activity, registrar outreach and an
educational portal primarily to drive this campaign.  So let me
introduce you to this campaign.  Next slide.

 "Practice Safe DNS," the objectives of this campaign, well, it is
initially to educate the technical audience about DNSSEC's benefits
and its implementation, so really to provide a platform for the
experts -- the DNSSEC experts to inform and educate.  So in this
campaign, you'll see a heavy use of videos, really intended to give
this a personal touch, make it a conversation between people.  We're
honored to have Steve Crocker as one of our initial speakers in this
campaign.  These are voices of the people that are there to
demonstrate the ability of DNSSEC to provide a safer and more secure
Internet.  So we want to increase the visibility among I.T. experts,
router makers, Web developers, registrars and the like, specifically
the infrastructure side.  We'd like to convey the trust and
confidence in DNSSEC within the greater Internet community.

 These are our initial targets within the infrastructure community. 
We want to develop the educational content that will appeal to this
audience and show the value of DNSSEC and connect the I.T.
influencers, the DNSSEC experts to this specific audience.  So we've
made "Practice Safe DNS" a community campaign and we have also
integrated this community campaign into PIR's own media outreach
activity.  Next slide.

 So going forward, "Practice Safe DNS" is in its initial month and
in that initial month had more than 1500 visitors, 3,000 videos
downloaded and we continue to ramp up that Web traffic and activity
with our PIR efforts.

 Secondly, we're profiling the sign names.  We'd like to
characterize which domains have been signed.  Are these banks?  Large
fund-raising organizations?  To try to look for some trending within
those names.

 With that information, the next step would be to develop case
studies as examples to the industry.  So who are the first movers for
DNSSEC, and what was their motivation to sign?  And how can others
identify with their situation?

 So while initially we're targeting the infrastructure providers, we
do see shifting in including actual sign domain names and looking
specifically at the adoption of registrants.

 We're also developing registrar promotions to encourage and reward
those who have gone into production with DNSSEC, to have incentives
for those registrars who are considering going into production with
DNSSEC and, again, rewarding those who have already gone through
their process and rewarding them through sales and financial
incentives to keep moving with this.

 We'd like to bring more of the movers, the influencers into our
"Practice Safe DNS" campaign.  Does anyone in this room have a story
to tell about DNSSEC?  Submit a blog to this campaign.  Have a
conversation with the larger community.  In fact, if you have a
message to get out to the infrastructure community, we're shooting
video today at the PIR meeting room which is on the first floor of
the conference -- of the convention center here between 4:00 and 6:00
p.m.  This is your way to get your message out to be a part of the
campaign, to educate the greater I.T. community about the benefits of
DNSSEC.  So please visit practicesafedns.org and join the campaign
for DNSSEC adoption.  Thanks.

 >>MARKUS TRAVAILLE:  Thank you, lance.  Go to the last speaker,
Chris Wright from AusRegistry.

 >>CHRIS WRIGHT:  I took a slightly different approach.  I have a
presentation here to do really quickly, and I will try and get it out
of the way so we can get on to the discussions.  Just about what the
actual business case is for DNSSEC or how we can go about creating
one.  Next slide.

 So the first thing I wanted to point out is that it is actually
hard to create a business case for DNSSEC, especially in Australia. 
We're having a really hard time getting our registrars interested in
wanting to support DNSSEC and wanting to integrate it into the
products.

 For most people, DNSSEC is hard and complicated to understand. 
Most people don't actually understand that DNS is not 100% secure. 
And we always hear things like, "We've been using the Internet for 20
years and never had a problem," those sort of things.  So until
you're actually affected by some sort of DNS attack or cache-
poisoning attack or something, this is not really seen as an
important thing to many people.

 There's always a cost, as was mentioned before; but even if DNS was
free, a lot of people wouldn't use it.  It is just too hard.  If we
do make it easy, which does cost money, then people won't use it
because they have to pay for it.

 So what's the driver for registries and registrars and ISPs to make
all of this easy?  Most of these organizations are commercial
organizations, and they generally want to see returns and whether
that's either in reduced risk or increased profit or kudos or some
other reward for the effort they put in.  That reward generally has
to be balanced with the amount of effort or cost that they put in.

 I think it is clear that we need to generate a demand for DNSSEC. 
At the moment, it is not quite clear how to do this.

 We all know that DNSSEC is important, right?  We all know that
securing the DNS is a good thing and shouldn't that just be enough? 
Unfortunately, it's not.  How can we help create or solidify the
business case for those that's not enough?  Next slide.

 So there are two ways that I believe anyway, that we can help.  The
first way is to try and reduce the effort or reduce the cost that's
actually involved in DNSSEC.  That's for everyone.  Come up with ways
to reduce the cost for the registrars, reduce the cost for ISPs,
external validation for registrants to deploy DNSSEC with their
domains and so forth.  And the second is to provide an incentive,
work out what the incentive is to get people to deploy DNSSEC.  Next
slide.

 So reducing the effort, well, that means bringing down the cost of
implementing DNSSEC.  There is some ways we can do this.  We can
research and share our ideas.  We can simplify the process.  We can
automate the process, or we can find ways to reduce risk for other
parties.  And this has to be applied to everybody.  From the end user
at home to have DNSSEC and validation enabled, at the moment it is
too hard.  I have to go and download Unbound and install it on my
machine or so forth.  There is no simple way.  It is not just working
out of the box.

 Some examples of how we could reduce the effort for registrars, for
example, provide tool kits to them to facilitate connecting to the
registries.  Most registries do this anyway.  Registrants, services
such as GoDaddy described, one-click DNSSEC.  Just make it easy so
that people don't have to care.  They just tick a little box and say,
"yes, secure my DNS" and it's done.

 For ISPs, create simple DNSSEC resolvers.  Don't make it too
complicated for them.  And for end users, build it into software and
turn it on by default.  It is going to be much easier if it is just
there and working and they don't have to do anything.  Bottom line is
try to make DNSSEC transparent.  Next slide.

 So how can we provide incentive?  There is two ways.  There is a
top-down push or a bottom-up pull.  Top-down does work to an extent,
but generally a bottom-up push is a better way to go about it.  Next
slide.

 Top-down, we can just make a DNSSEC a requirement.  We can make
contractual obligations or government can mandate it has to be done
or ICANN.  And this is what's happening in the new gTLD program. 
DNSSEC is a mandated requirement.  So that's obviously going to force
people to do it.  The business case makes itself there.  If I don't
do this, I can't have a new gTLD.  That's pretty simple.

 Usually, though, you can only go as far down as registries.  It is
harder to do with registrars, especially in the dot AU environment. 
It is for a top-down approach.  

 You might be able to do it with ISPs, depending on how your country
is set up.  In Australia, we have ISP licensing so we might be able
to force it that way.  Generally, people don't like doing things they
are forced to do.  This is not necessarily the best way to go about it.

 Next slide, please.

 So bottom-up, so bottom-up, basically, is generate user demand,
either from the registrants or I need to have my domain name signed
or from the end user, "I want to use a secure Internet or I'm not
going to go to your Web site unless the DNS can be trusted."  We need
to create a reason for people to want DNSSEC.  Next slide, please.

 So one potential reason is security.  We can play the security
card.  But everybody plays that all the time.  Increased security,
that really only works if it is visible to end users.  End users can
be trained or can tell that this domain over here is not using DNSSEC
and that's insecure.  This one over here is.  So think sort of the
green bar in the browser.  Unless there is some sort of cue, some
sort of indicator to end users that this is secure and this is not
secure, this whole security thing is not going to work because they
are not going to know otherwise.

 And it requires education.  So we are going to get out here and
educate these end users, just as it took ages to educate users that
they have to look for the padlock.  How many times have you seen
people just sit there and get the warning pop up that says, "The
certificate doesn't match the domain name" and they are like, who
cares, they just want to get to the Web site.  It happens all the
time.  Next slide, please.

 But a better potential reason is to see DNSSEC as an enabler.  So
what can secure DNS help us do.  Now that DNS is 100% trustworthy,
what can we do with it?  Once we have that, once we have that reason
for things that we can do with secure DNS, then people will need
DNSSEC.  I can't use DNS -- I can't use DNS for this purpose unless
it is secure, therefore, I need DNSSEC.  That will instantly create
demand.  So what are the new services and products that we can build
on top of this new secure DNS platform?  Next slide.

 So examples of how we can provide incentive, target larger security-
conscious organizations.  They will probably buy into the security
argument, the banks and the people who have large online presences. 
People who have something to lose if people are deceived and not able
to get to their Web site or tricked into going somewhere else.

 Lobby software developers to implement DNSSEC in their products,
lobby the browsers to get that green bar up there or whatever way it
is that they are going to indicate to users that a domain is secure.

 Build DNSSEC as requirements into other applications when it makes
sense.  I don't know.  Perhaps SSH could have a requirement for the
domain name to be able to be securely verified with DNSSEC that it
maps back to the IP address or something.  Who knows what things
could be thought of.

 And the last one is find innovative uses for a secure DNS.  Example
of an initiative going on at the moment is publishing certificates in
DNS to supplement the use of CAs.  If this sort of catches on and
takings off, that in itself will drive the adoption of DNSSEC.

 Next slide.

 So in summary, we can create a business case for people to deploy
DNSSEC at all levels of the tree, whether it's registrants, users to
complain to their ISPs because they don't have validation or
registrants to complain to their registrars because they want DNSSEC
and the registrar is not offering it, forcing registrars to
implement, et cetera, by reducing the cost, making it easy for those
people to implement it and generating demand.

 Once we have those things, then we can actually start to market
that case to people.  And then we can worry about how we are going to
market that case.  Until we have that case, we are not really going
to be able to market anything.

 As an industry, we should try to do all of this consistently. 
There is no point everyone flying off in different directions trying
to sell DNSSEC in different ways.  We should try and be unified in
our front and try and get this done in a way that's consistent. 
That's it.  That's all I have.  Thank you.

 >>MARKUS TRAVAILLE:  Thank you very much, Chris.  Thank you very
much all the speakers by keeping it short.  I think you made a
tremendous effort in doing so and I think you had clear messages.

 Are there any questions, remarks from the audience or from the
chatroom?

 I see Russ is -- Russ Mundy.

 >>RUSS MUNDY:  Yeah.  This is mostly directed at Chris, from his
last part of the presentation.

 There's a number of the applications that you've already mentioned
that already are DNSSEC capable, and so the question that I have for
the panel in a more general case, not just Chris but whomever up
there.  

 How do we go about, as a community, both informing those that make
use of these capabilities that the capabilities exist and encouraging
them to not only make use of them but to push on providers of DNS
capability that doesn't currently do DNSSEC to get them to sign and
to provide validation?  

 How do -- how do we move in that direction?

 >>CHRIS WRIGHT: I think an important thing is for those
applications to make it clear and visible to the end users that
DNSSEC validation is being done or attempting to be done and that
it's failing in those cases.  

 So I don't know whether that's a big warning box or change
something to a big red star or whatever it is.  Come up with ways,
visual cues, I guess, that we can let those end users know that this
application is attempting to do something with the DNS and it hasn't
got the secure response that it was looking for and that's bad and
this is why.

 That's one way that I can think that we can try and start trying to
get that message across.

 >>MARKUS TRAVAILLE:  Anybody else on the panel who would like to
react?  

 Lance?

 >>MATT MANSELL:  Yeah.  I actually think it's even simpler than
that and I think that, you know, that is that you don't market DNSSEC
to the end users.  You know, that you market security.  

 I think the minute you try and talk DNSSEC to the end users, they
won't buy it.  It's too complicated for them to understand.  I think
it needs to be a fast, simpler, blue-smoke explanation as Nominet
gave earlier on this week.  

 You know, it's really that simple, I think.

 >>MARKUS TRAVAILLE:  All right.  Thank you.  Okay.  I -- 

 >>LANCE WOLAK: This is Lance Wolak.

 I would like to just say that I believe that if we can show the
elements of the chain of trust that are DNSSEC ready and show that a
specific domain has a complete path and here's what the benefits are,
I think that would be a big step forward.

 From a registrant perspective, I don't believe that there's any
real barriers to adopting DNSSEC.  I believe that they will take the
security services that are available to them because I do believe
there's a very strong awareness that we need to have as much security
around our domain as possible.  

 So, again, I think it's a matter of proving out that the
infrastructure is ready and proving that certain vendors are now in a
position to provide DNSSEC and have the level of readiness.  That
will put the pressure on those that aren't there yet to come on board.

 >>MARKUS TRAVAILLE:  Anybody else like to comment on the visibility
for the end users?

 >>JAMES BLADEL: Yes.  Just quickly, I just wanted to echo a lot of
what Matt and Lance were saying.  

 I think that we need to continue to build that critical mass. 
Building awareness is tough.  A lot of end users are not looking for
secure DNS because they don't even know what role DNS plays in their
activities on line, so telling them that it's vulnerable and needs to
be secured is an uphill battle.

 But what we can do is identify barriers, barriers either of cost
barriers or technology barriers, and help lower those so that a
certain percentage of early adopters will get on board, and then I
think that the applications will follow.  

 But it all has to work kind of concert.  We're still in an era in
2010 where we still have to take the message out there that SSL
certificates have a value and a benefit and are critical for certain
functions on line.  So these are -- we're never going to be finished.
We just have to keep moving the snowball downhill and hope that it
picks up momentum and hits the tipping point with some of these
applications and services.

 >>MARKUS TRAVAILLE:  So just to make a point of order, if people
talk in a microphone, please mention your name for the scribes
because they're not here and they don't know who is talking.  

 This was Markus, by the way, the moderator.

 [ Laughter ]

 >>MARKUS TRAVAILLE:  I have one question, still, on this
visibility, which is the role of the major software vendors like
Microsoft and Google and all others.

 Is there a way of putting kind of a strong lobby on them to make
DNSSEC more visible, and how can we do that?  Is there anybody who
would like to -- yeah?

 >>JIM GALVIN: Yeah.  Actually, that was my question.  I'm sorry to --

 >>MARKUS TRAVAILLE: So your name is?

 >>JIM GALVIN:  I'm Jim Galvin from Afilias.  

 And I was going to say that I've heard two very important messages
here -- at least two -- from the panel today:  A focus on the need to
keep it simple for the user; and then an emphasis on services and
integrating security with services and applications on the Internet.

 But one thing that I didn't hear, which speaks directly to your
issue -- I'll generalize it a little bit -- which is:  What about the
relationship of DNSSEC and platforms?  

 So Microsoft Windows and Apple are the two big examples.  Linux is -
- and the various versions of UNIX is another good example.

 I'm interested in the perspective from the panelists on the role of
platforms and the integration into resolvers in particular on
platforms, since that makes DNSSEC more generally available to all
services and applications, but where do you see the role of platforms
in this issue of integration of the DNSSEC and adoption?

 >>MARKUS TRAVAILLE:  Good question.  

 Is there anybody who would like to comment on that on the panel?  

 Chris Wright from AusRegistry.

 >>CHRIS WRIGHT:  Obviously it's really important to get those major
platforms on board to make it easier for the application developers
to start to utilize the services that DNSSEC offers.

 However, that being said, there are ways -- and it happens all the
time -- for applications to work around resolvers that exist in the
OS layer and so forth.

 So I don't see that we have to sit around and wait for the OS
vendors to get on board and get their platforms sorted out.  Unbound
is a perfect example of a way to bypass what the OS vendor's done and
bring DNSSEC support to the end user.

 The difficulty with that, obviously, though, is that it involves
the end user having to do something.  Download a bit of software,
install it, and so forth.

 If we can sort of take that sort of Unbound idea and embed it into
whatever our secure application is that we're building, I don't know
if we're -- we're talking about an SSH client making use of the
DNSSEC to get SSH keys out or -- if that ability to query those
results from the DNS and then validate them and so forth happens
within that particular program independent of the operating system,
it doesn't actually really matter.  We're still getting the end
benefit.

 >>MARKUS TRAVAILLE:  Anybody else?  

 We have James.

 >>JAMES BLADEL:  That's a good question, Jim, and I think that it
is important.  I think to your list I would also add mobile
platforms, especially when you consider the resources, whether it's
storage or processing cycles, are always going to be a little more
scarce in those environments.  So I think that those need to come
along as well.

 >>MARKUS TRAVAILLE:  Pavel Tuma?

 >>PAVEL TUMA:  Well, I agree with you, Jim, that it would be really
ideal to have DNSSEC support in the platforms as it would be super
simple for the end users, but these are the 800-pound gorillas, and
just try to imagine how long it took for Microsoft to include
firewall in Windows.  These were years.  And within those years, we
had other solutions from the smaller, more flexible vendors and
that's what I think would happen with DNSSEC too.

 The space is here for the small vendors for us, for anybody who
develops the applications.

 >>MARKUS TRAVAILLE:  Thank you very much.  

 Jim Galvin, another question?

 >>JIM GALVIN:  Just a comment.  So I think I -- what I heard is,
yes, there certainly is a lot of value and ultimately we do need to
get the platforms on board, but we shouldn't see that as a barrier. 
We need to move forward with what we can do now and continue to press
the platforms to come up to speed, too.  

 And I see a lot of nodding heads, so thank you.

 >>MARKUS TRAVAILLE:  Thank you very much.  Marcus Faure from CORE.

 >>MARCUS FAURE: Yes.  So I do not need to introduce myself.  

 A similar point.  I think you can create awareness just by going to
one of the major browser vendors -- say the Mozilla Foundation, which
I think is not as heavy as Microsoft -- and bring them to add a
little something to their browser so that the user becomes aware of
DNSSEC.  

 Maybe another light or maybe that the button beneath the URL bar
only turns green for all DNSSEC-aware TLDs, if the certificate is
correct and you have DNSSEC.  And you could ask them to start that at
a certain date and that will create pressure all along, all down the
line.

 >>MARKUS TRAVAILLE:  Thank you.  Is there anybody who would like to
comment?  

 Chris Wright.

 >>CHRIS WRIGHT:  Yeah.  So I think the challenge with this is to
not go overboard, though.  I think it's dangerous if we sit back and
we say, "No DNSSEC, bad site, don't go there, don't use this site."  

 I think DNSSEC has to become just one metric that's used in
measuring the relative security or insecurity of a particular site.

 So I don't think it's going to be quite as easy as, say, "Okay, go
to Mozilla and get them to put an indicator up as to whether DNSSEC
is there or not."  

 They're going to need to think about it bit more and work out how
they're going to integrate that into -- and whether they come up with
a scoring mechanism to score a site based on a few other factors --

 >>MARCUS FAURE: You could say "secure" and "very secure" or
something.

 >>CHRIS WRIGHT:  Right.  Exactly.  

 So as long as we keep that in mind, then, yeah, it would be a way
to get started.

 >>MATT MANSELL:  I think this just echoes the simplicity point
again because, you know, if you take extended validation, you know,
the amounts of calls that our support team takes that are just, you
know, "How do I get that green bit in my browser," and kind of
stripping it back to basics again, it all comes back to not promoting
it as DNSSEC and actually just promoting it as an actual level of
security.  

 And I think, you know, it's great if you can get a browser to
support it, but ultimately there needs to be ground-up adoption. 
There needs to be a reason that a user needs to say "I want that
extra level of security," and I guess it stands to registrar to
create that incentive with their users.  

 So it's working on how we can do that.

 >>MARCUS FAURE: But I think you can only get that when you talk to
the browser people, so that the people are aware of it.  I don't
think it will work the other way around.

 >>MATT MANSELL:  Yeah.  I think it's a combination.

 >>MARKUS TRAVAILLE:  Okay.  I saw other hands.  

 Lance and Pavel?

 >>LANCE WOLAK:  Lance Wolak.  Just a final remark on that question.

 While we can talk about how best to implement some type of an
indicator of level of security, I think the point that I heard was
can we look to leaders within the industry and have them be
spokespeople for the deployment of DNSSEC.  

 And I think that that's a great way to do this, and that -- again,
that's something that we're looking at doing specifically with our
own campaign, and to the extent that we can get the large software
vendors and hardware vendors working with us in pioneering and
evangelizing around DNSSEC, that is really the best way to go.

 >>MARKUS TRAVAILLE:  Pavel Tuma?

 >>PAVEL TUMA:  And I think what Lance just said.  The process is
already ongoing.  We develop the Firefox plug-in, which displays the
red and green piece in the address bar, and I think that's really
enough for the end users.  It doesn't have to be any more complex
than a red and green icon, and nothing else.  

 All the banks now teach their users to double-check in the address
bar whether there is an SSL certificate, so -- in whatever way.  So
we can teach them the same way with DNSSEC, red or green icon.

 >>MARKUS TRAVAILLE: Thank you very much.  I have a question on the
left.  

 Is this on the same topic, Roy?

 >>ROY ADAMS:  I just want to respond to the point, but the question
is on the same. 

 My name is Roy Adams.  I want to make a small statement.  I think
the best way to do validation in the end is as close to the consumer
as possible.  That means in the application or in the OS, and not
just at the ISP.

 Thank you.

 >>MARKUS TRAVAILLE: Okay.

 Please introduce yourself.

 >>VANDA SCARTEZINI: Okay.  My name is Vanda Scartezini.  I am a
member of the board, representing the ALAC.  And also member of SSAC.

 From my experience, the best way to reach the consumers, the users
in general, is in that relationship with the government.

 So when you think about most of the countries now days, has at
least the most of the users are in countries where there is e-
government solutions.

 To convince the governments to demand that things, to have that
relationship with the government in any service they provide is the
best way to make people think about that.  Because they need it.

 So I believe that we have here two opportunities to marketing DNS. 
One is just make a huge presentation to the GAC, and talk, then, how
to talk about -- include this, you know, thing inside their
governments.  It's one point.

 The other point is just the ALAC and all the RALOs, because there
is more than 150 ALS connected in the five regions.  So -- But they
don't understand clearly the same.

 So once you have some campaign in direct response for -- I know
that's a session for that, but never works like that because there is
parallel sections from the groups, and the groups must be there
because they are here to be there.

 So there is a lot of things that could be done in order to promote
and push the use of DNSSEC into the whole community.

 So that's just suggestion.  Thanks.

 >>MARKUS TRAVAILLE: Anyone else?

 >>STEVE CROCKER: Vanda, thanks very much.  So just for the benefit
of the audience and also just to complete this, so this looks like a
very constructive opportunity for a cross-organization, for SSAC and
ALAC, to actually have something to talk about, which I always look
forward to something sensible.

 So we'll put that on our agenda and we'll open up a discussion with
Cheryl and try to work out a campaign.  I think that's an extremely
helpful suggestion.  I like it very much.

 Thank you.

 >>MARKUS TRAVAILLE:  Anybody else would like to respond?

 So is targeting the governments a sensible approach in different
countries?

 It sounds like a good suggestion.  I personally I am talking to the
Dutch government trying to convince them that they deploy DNSSEC for
their domains.  But I guess -- Any other questions?  Comments?  I see
Roy Arends.

 >>ROY ARENDS: Hi, Roy Arends of Nominet.  I have a question for
James, for Matt and for Chris.  And this is about eating your own dog
food.

 Dot com will be signed, I understand, in March 2003 -- 2011; sorry.
And I don't know when dot com dot AU is going to be signed.

 What is your timeline when that happens when your own major brand
is going to be signed?

 Thank you.

 >>JAMES BLADEL: I wasn't sure if you wanted us to answer in the
order that you described, but as we're using gTLDs, we will probably
secure our brand with our own products as quickly as possible.

 >>MATT MANSELL:  This is Matt Mansell speaking.  For us, I think
it's about waiting for the demand, to be frank.  It's all very well
that dot com is signed in March 2011, but we need end users to be
seeing DNSSEC as a requirement they must have.  And yes, we need to
lead by example to encourage that our end users do the same, but not
necessarily at the loss of complications.

 So, you know, I think it's pretty evident that we'll probably sign
next year at some point, but I can't -- I'd be lying if I said it was
top of our agenda, is the honest answer.

 >>CHRIS WRIGHT: From a dot AU perspective, we also have a project
executing at the moment which essentially stops at the point of doing
the actual signing, so working out all the parameters, the processes
that we are going to use, et cetera, et cetera.

 The actual decision as to whether we go ahead with signing the
zones or not is out of our hands.  So we actually have to, first of
all, convince people who don't know the policy body in AU, but
secondly, the Australian government has a vested interest in this,
and they have clearly stated that they want to have a say in when and
if this happens.

 That being said, I wouldn't be surprised if it didn't occur next
year.

 >>MARKUS TRAVAILLE: Thank you very much for your answers.

 Two more questions from the audience.

 Who was first?  Yeah, go ahead.

 >>ROD RASMUSSEN: Yes, Rod Rasmussen.  And I think many of you know,
I have been a supporter of DNSSEC in general, so don't take my
comments as a nay sayer against DNSSEC but I have some major concerns
at this point.  But I would like to echo, one of them is based on
what we were just talking about of getting things as close to the
user as possible.  Right down to the applications so people have a
better idea of why things are failing when they fail.

 And that's my concern right now, is risk/reward measurement in
adoption of DNSSEC today.

 I have -- My company works with hundreds of banks and financial
institutions and e-Commerce players and things like that.  So I have
a pretty good feel for how they are viewing DNSSEC and the like
today.  And my advice to them today, if they were to say, should I
adopt DNSSEC, would be no, not in the current status of where it's at.

 Now, I would want them to explore it, get ready, et cetera, but the
reason is, when I take a look at the risk of adoption and based on
where we're at today and the state of the art, we have lots of
failure.  There's a lot of moving parts to this.  It's still leading
edge technology, et cetera.  So a lot of people who are doing these
assessments are saying, okay, what reward do I get?  I get protection
from DNS cache poisoning.  The question is how often does that
happen?  We don't have really good studies and information about that
out there.  

 So then I weigh that against the risk of messing up my key
management, et cetera.  We have had fairly public events where entire
TLDs have been darkened if we were doing actual validation on a wide
scale.  

 So if I take that and I say, okay, if I mess up my key management
or if something goes wrong and my online banking platform goes down
for several hours, what does that cost me versus having, you know,
security from DNS cache poisoning.  Right now, that balance isn't
correct.

 And I don't know -- Just as an example, we did a survey of dot gov.
This goes to the that of top-down versus bottom-up.

 Did a survey of dot gov and released that in September.  Some of
you may have seen that.  Despite a U.S. government mandate for
federal agencies to adopt DNSSEC, only about 36% had as of September
and were publishing.  That's, okay, that didn't work so well but they
are still working on it.  That's great.  

 The problem is 2% of those zones were failing.  So if we were doing
validation, 2% of the government TLDs wouldn't work.

 So that's -- And I'm doing risk/reward management.  That's a real
issue.

 So I think we have got to get around that, plus move things down to
the application layer.  So if there is a failure, then users can
adjust -- can make a judgment as to what that failure is.

 Right now, it's at the ISP level.  That's the other problem.  ISPs
don't like people calling them saying the Internet is broken.  But we
have got to move that down.

 So to wrap that up, I am very concerned about the failure rates and
getting that done.

 And then also, is there a concerted effort or lobbying kind of
coordinated effort, I guess, to get the application vendors to
actually -- and the OS guys to actually implement this into their
software.  Because that's where it's going to have to be.

 So it's kind of a bunch of comments, and I'm sure there's some
reaction to that.

 >>MARKUS TRAVAILLE: Is there anybody?

 >>JIM GALVIN:  Markus, Can I ask for a clarification of his
numbers, please?  Was it 2% of dot gov are failing or 2% of the 36%
were failing?

 >>ROD RASMUSSEN:  Right, no, so it's 2% of -- Let me be very
precise here.  So we did a survey of dot gov, and it turns our a
majority of dot gov domains aren't actually federal agencies.  I
don't remember what the balance was.  It was like 60% were state and
other agencies.  So of the 40 or so percent that are federal, 36% of
those were signed.  You can do whatever the math is on that.  It's
like 12 or whatever.  But a lot of the state ones are signed, too.

 Of the federal agencies that we're signing, 2% were failing.

 So it's a number in the, like, 10 to 20 domains were failing of the
ones that were signed.  It's a fairly small number, but it's
significant.

 No, 2% of all of federal.

 >>STEVE CROCKER: Do you have these numbers -- This is Steve
Crocker.  Do you have this information tabulated and posted and cross-
referenced and so forth?

 >>ROD RASMUSSEN: I thought I sent that to you, Steve.

 >>STEVE CROCKER: Probably so.

 But the other point is that that's a point in time, and it's worth
repeating and watching this.

 It's not -- I mean your point is well taken, that this is early
days.  There are some perturbations, and so the ultra conservative
point of view if you are giving advice to give your clients, for
example, is hold back.  So there always has got to be a spread
between early adopters and so forth.

 But the distinction between useful data and FUD, I think, in this
case is sort of putting that information in the right perspective, is
that 2% all the time because that's just kind of an inherent thing? 
I think the answer is no.

 Is it 2% at a particular moment in time and then you measure it a
week or a month or three months later and it's all been ironed out
and it's stable for a long period after that?

 So I think that would be the important kind of thing to grab hold
of.  And your information is a very helpful stimulus to set a
baseline and frame the question.  And then we can get subsequent
follow-up answers on that.

 So I want to take it in a constructive fashion.

 >>ROD RASMUSSEN: I mean that in a -- I am trying to challenge a
little bit but also be constructive.

 And of course we sent the information in to NIST as well so we can
get the agencies that we saw fail get their zones signed correctly.

 >>STEVE CROCKER: I am personally interested in how you acquired
that information.  It's been a bit challenging engaging with the gov
people to get that information.  They have been -- tended not to
engage.

 So everybody, even people in the government, are working from the
outside looking in, as opposed to from the inside.

 >>ROD RASMUSSEN: And we are going to repeat that study, at least on
a quarterly basis as well.

 >>STEVE CROCKER: Great, great.  Thanks.

 >>PAVEL TUMA: Pavel Tuma.  I would like to comment on the other
side of the study on DNS attacks.

 We conducted research in a real environment, how long does it take
to do the key spoofing con- (inaudible) by the DNS server, And we
found out with 95% of probability that it's within two weeks in a
real Internet environment.

 If you want to see the details, go to labs.nic.cz and the document
with the output of the of the studies is there published.

 >>ROD RASMUSSEN: Let me clarify on that point.  I know those
numbers and it's a great study.  I've looked at that.  It's real-
world cases I am referring to, is how many times has this affected a
bank or end users who have been actually spoofed and hurt.

 I know it happens.  We have seen it in very infrequent cases. 
However, getting real data out there so that risk managers can say,
"Wow, there actually is a problem here.  We need to cover for this,"
that helps makes the case.

 >>CHRIS WRIGHT: Chris.  There's also the case of accountability,
because at the moment, if an end user goes to a bank Web site and
somebody has cache poisoned the DNS and they actually go somewhere
else and those credentials are compromised, it's not clear, and I
don't know anywhere where it's ever actually been tested in a court,
whether a bank is accountable for that.  And if they are not
accountable for it, then part of them wouldn't actually care.

 That doesn't help make the case for why they should fix the problem.

 It's not like credit cards, for example, where there was a driver
for banks to go and stick the chips on all the credit cards
everywhere to make them more secure.  Because every time someone
fraudulently used a credit card, the bank was accountable for that
and had to pay the cost for that.

 So it was within their interest to make credit cards more secure. 
If they are not accountable for what happens with their domain names
online and when people get misdirected and so forth -- and I
understand the argument would be very difficult to try to work out
who is accountable -- but that case doesn't exist now for DNSSEC.  We
can't use that as an argument for why they have to deploy it.

 >>MARKUS TRAVAILLE: Thank you very much.  And for the sake of time,
we have two more questions there, and then I have -- oh, there's one
from the chat room, so we have two questions and one from the chat
room.  And then we will go to the next.

 >> We do have one.  It's a comment from the chat room from Marc
Lampo, and that is in response to Pavel's comment earlier that the
cache poisoning -- I have lost it here again.  Okay.  Those numbers
pointed to, for the cache poisoning, those numbers must be for
attacks from the Internet, but chances for successful cache poisoning
are much higher when launched from malware internal on a PC.

 So there's -- I think what he is pointing at is the threat to end
machines having malware cause the same effect.

 >>MARKUS TRAVAILLE: Okay.  Thank you.

 Yes, please, announce your name.

 >>HAN CHUAN LEE:  Good morning.  Hi.  My name is Han Chuan Lee from
Singapore.  I have been looking at DNSSEC registry in my country.  

 So I want to look at the DNSSEC on the service provisioning point
of view.  And if a domain owner register their name with a registrar
but have the DNSSEC hosted by another provider, that might be a
little problem here because for any updates to the DNS, it has to go
through the registrar; right?  But the DNS provider do not have any
contractual agreement with the registrar.  So all the contract
agreement are with the registrant.

 So if the -- for any changes to DNS, you have to go through the
registrar and the registrant may not even know what to do with all
the extra cost.  (Inaudible) DNS now further complication.

 So we think there is an incentive or there is a market push or
market change to, actually, for domain owners that want their names
to be signed to actually go to a one-stop solution provider that is a
registrar as well as a DNS hosting provider, and resell the software
as a result.  Because, sure, becoming a registrar, they may find it
more -- very difficult to provide such a service and either become a
registrar or not provide it at all.

 >>MARKUS TRAVAILLE:  Anybody would like to comment on that?  I
guess people on the table already showed they are going to offer
complete solution -- managed solutions.  So that's in the direction
you are pointing at.  So that's a good comment.  Anybody else like to
-- no?  Thank you, Han.  Thank you.  It was a good suggestion.

 And then I have the last question or command.

 >> WARREN KUMARI:  Actually this is two comments.  Warren Kumari. 
First off, I'm interested in what Chris was mentioning earlier about
using DNSSEC to supplement the CA model.  That's what's happening in
the IETF in (inaudible) and Dane working groups.  Secondly, it was
mentioned numerous times that if the large OS and content and browser
players supported DNSSEC, that would be good.  

 I can mention that Google is actively trying to get support finally
in Chrome as well.  No idea when yet but, you know, it is coming
sometime, hopefully not too long.

 >>MARKUS TRAVAILLE:  Okay, thank you very much.  With that, I would
like to close this session.  Beforehand, we said a measure of success
of the session would be the number of people asking questions at the
microphone.  I think they were good questions and many questions, so
thank you very much the audience and also the panel for your active
participation on this topic.  And, yeah, I think an applause for the
panel would be appropriate.

 [ Applause ]

 So now I give the floor back to our chair, Steve Crocker.

 >>STEVE CROCKER:  Thank you very much.  Next up we have Roy Arends,
yes, from Nominet.  Thanks very much, everybody.  Go ahead, Roy. 
Thanks.

 >>ROY ARENDS:  Thank you, Steve.  Is this microphone on?  Perfect. 
My name is Roy Arends.  I work for Nominet.  I'm here to brief you on
an issue we had with DNSSEC in the U.K. zone recently.  So on the
evening of September 10th, one of our engineers got a call --
actually got a text message, from the monitoring system.  It
basically says, "Please check out the main signing system because it
doesn't respond."  And when the engineer checked it out, he saw a
kernel panic.  I won't go all technical on you, but a kernel packet
is basically a shut-down of the kernel, which means that the entire
system is unresponsive.

 Now, that being said, the signing system is the main machine in our
signing infrastructure.  It is what signs the U.K. zone.  So when
that happens, we kind of panic a little, just like the kernel did.

 The problem was actually related to an HSM driver.  And one of the
issues we had with this HSM is that we couldn't reproduce the error. 
And if you can't reproduce the error or the kernel packet, you can't
fix it.  And even when you -- even when you write scripts to test it
or to circumvent it, you can't test the scripts when you can't
reproduce the kernel panic.  But that said, it happened.  They happen
all the time.  Disks crash.  CPUs burn out.  Network cables get
detached.  It is just a fact of life, and that's why we over-provision.

 Even though it was a critical system, there really was no time
pressure because we have -- if you understand DNSSEC, the signatures
that are being produced, we have a shelf life of two weeks.  That
means when the system crashes right now, the infrastructure that's
out there in the DNS will still be valid for two weeks.

 And we have two very simple failover scenarios.  Now, if you bear
with me, this is the pinnacle of hardware engineering and software
engineering in the 21st century.  It is going to be very complex. 
And the first scenario is you reboot the box.  And the second
scenario is -- it is also very, very complicated.  If something
fails, you just use the other box.  So this is what we call active-
active scenario.

 So Scenario 1, very simple, the Microsoft way, you push a button
and it restarts.  However, it only takes a few security experts to
make a very simple process very complex.  We demand proper security
hygiene on our systems.  That means we require presence of a security
officer.  And a security officer in this case is not a guy with a
badge.  It is actually a member of our senior management team, so in
that case, a guy with a cape.

 When we restart that box, we need a physical presence of a security
officer and auditor.  However, it was a Friday evening.  There wasn't
really any time pressure and we had an alternative scenario.  So
let's go to Scenario 2, activating the secondary system.  This is the
other box that I was referring to.

 It's basically a carbon copy of the main signing system.  In fact,
it doesn't even know it is the secondary.  It is the exact same
system.  And computers are basically deterministic systems.  If they
have the same seat, if they have the same software, if it is the same
time and the same configuration, it does exactly the same thing.  And
so we can have it run independent of the main signing system, and
that's necessary because it should not communicate with the main
signing system in case the main signing system is completely offline.

 We did some pre-deployment checks before we go to the secondary
system just to make sure everything works, and everything works.  We
checked for the configuration file.  We checked for the proper zones.
And we checked if all the keys were there, and everything was
correct.  So everything was ready to go, but it was still Friday
evening.  There was no time pressure.  So we waited until the next day.

 Now, on Saturday the 11th of September, on that unfortunate day
that has nothing to do really with this scenario, we decided to make
the secondary system active.  And I can just say this was not -- this
whole incident was not a terrorist attack.  It was just a failure.

 So we decided to make the main secondary system active.  And this
would allow us signing to continue and would make the main signing
box that just failed offline and quietly investigate what has gone
wrong.

 So we also didn't need any security officer on site because the
secondary signing system would just run, has done all the time.  We
would just have it talk to the world just like the main signing
system had done.

 That said, we started a signing system at 2:30.  Everything went
perfect, no alarms, no bells, no whistles.  We looked again and
everything worked perfectly.  However, something was not quite right.

 We saw very few, very little failures happening in our
infrastructure, in the wider Nominet infrastructure.  And when we
looked at it, it turns out that the system was in an unfortunate
state.  On first sight, we saw that the main signing system and the
secondary signing system did not use the same key.  Now, in itself,
that doesn't really matter, and I will explain to you in a second why
that is.  But it led to some validation problems in the field.  This
could be quickly resolved by flushing the cache for an ISP company or
basically wait until the old key expires and a new key gets accepted.
But that shouldn't have happened.

 We also at the time when we were investigating the issue saw some
messages on Twitter basically saying, "There is a problem in the U.K.
We need to restart the cache."  And from that follow-up we saw
Twitter messages.  So we also made sure that our marketing team and
our engineers worked together and briefly explained that, yes, we had
an issue and we were working on it very hard.  In the meantime,
please, if you have an issue, flush your cache.

 So what did happen, it turns out that the secondary system has an
older ZSK.  What it means is that sometimes you hear in DNSSEC
terminology the term "DNSSEC key rollover."  It is, basically, you go
from a key that you currently use to a new key that you want to use. 
And this older ZSK, even though it was old, it was probably signed --
properly signed by the KSK.  So this whole zone and the whole signing
system was internally consistent.  So it validates fine.  There was
no problem, unless, of course, you had already cached in the
validator the previous key which had a TTL of two days, 48 hours. 
And so validaters with those old key saw signatures by the new key
and it couldn't validate those.  This was really the issue.

 So why didn't we see this?  Why couldn't we flag this?  And I'm
going to be a little bit technical here, but this is related to our
signing system.  We use OpenDNSSEC, and OpenDNSSEC consists of two
main parts.  There are other parts of OpenDNSSEC but for this talk,
it is related to these two things.  The first part is the enforcer. 
And excuse the term but it is simply a way of translating a policy,
for instance, which key to use, what keys to use -- sorry, how to use
that key, for how long to use that key, when to do rollover.  That's
basically the policy.  It turns that into a configuration for the
signer.  And the signer use that is configuration to sign the U.K.
zone.  So it is a two-step approach.

 And what we noticed was that the enforcer was unable to overwrite
the configuration file at one point in time.  So when it is unable to
overwrite that configuration file, the signing system would just use
the configuration file that exists in that exact path.  Basically
using an old configuration.

 So the signer would then still use the old ZSK.  So that was the
core of the problem.

 We used the auditor to check the zone status, but the auditor
that's basically checking the consistency of the zone, if everything
is correct according to the policy, right, it takes a look at the
time.  It takes a look at the configuration file, and it didn't flag
anything.  And the reason for that is we use ODS -- that's a
technical term -- we basically use utility to list the keys on both
systems.  If they completely agree onto a binary level, if it is
exactly the same key set, then there is no problem.  Both keys, the
new and the old key, were present on both systems.

 Also, use ODS-KSMUTIL to report the policy.  What that means is it
takes the current time, it then looks at the policy, and it will tell
you the keys it's currently using.  Of course, that would tell us the
keys that we should be using.  However, this is nothing to do with
the configuration file, and we never noticed that the configuration
file had the old keys in there.  And we also had no checks if the
file could be overwritten, and that's something we learned.  You can
never know what you don't know.  It is a very hard problem.  In
testing and building tests, you don't know what you don't know.  And
the other extreme is that you take things for granted.  You don't
know what you take for granted because you take them for granted.

 So we made some additional measures for this to prevent this from
happening in the future.  We updated our audit scripts to include
caching.  We monitor now problems with overwriting failures with
permission checks, basically.  We turned the TTL down from 24 hours
to one hour.  And we also don't require a security officer anymore to
reboot the main signing system.  We only require one finger to push a
button.  So lessons learned:  As I said, you can't test everything
beforehand.  But a good friend of mine, (saying name) from SIDN told
me recently, and absolutely makes sense, you can have 100,000 checks
and you can have a million tests but it takes just one bug to take
the entire system down.

 We also noticed something completely different, is that hardly
anyone is validating DNSSEC yet.  When I explained that to my
manager, Simon, I told him I have good news and I have bad news.  He
said, Okay, tell me.  I said, No one is actually validating DNSSEC
yet.  So he says, okay.  And what's the good news?  And I said,
Simon, that is the good news.  Another thing is what we notice is
problems get very publish very quickly.  Even though hardly anyone
was validating our zone, just a few Twitter messages triggered people
checking by hand our zone and we can see the difference between
checking by hand and using proper normal validation procedures.

 Since it would be explained on lists, it would be better for us to
be that beforehand.  It is better for us to basically be transparent
as we always are and communicated that we have problems and
communicate what the issues were.

 Another idea is if you have a system crash, please have it on a
weekend because less people are using your systems on the weekend. 
And lastly, I just -- one thing I wanted to point out, this was
really not an OpenDNSSEC issue.  This was simply what we think, was a
permissions problem.  Anyway, that's it for me.  Thank you for
listening.  If anyone has any questions, I would like to hear them.

 >> JIM GAVIN:  Jim Gavin from Afilias.  I have just a question or
comment just reacting immediately to the last statement you put
there, "it is good to have problems on the weekends," except that I
think the issue -- the benefit you had was more about people not
doing validation than the fact it was on the weekend because in
principle, I would expect a lot of the user community to be -- I
mean, maybe more active on the weekend, right?  I mean, end users
doing their thing.  I would think more people would have seen more
problems on the weekend than not if they were actually doing
validation.

 >>ROY ARENDS:  To be fair, having a problem on the weekend referred
to a DNSSEC problem because it takes48 hours in our case to expire
from the cache so only on Monday.  

 I basically thought at that point in time of the presentation, you
would have liked to hear a joke.  Thank you very much.

 >>STEVE CROCKER:  Thank you very much.

 [ Applause ]

 Our next talk is by Roland van Rijswijk from SIDN via a video that
we have here.  So let's just queue that up and move it on.

 >>ROLAND van RIJSWIJK:  Hello, everyone.  Welcome to this video
presentation.  Let me briefly introduce myself.  My name is Roland
van Rijswijk.  I work for the research network in the Netherlands
called SURFnet.  We connect all academic institutions to the
Internet.  I will briefly walk you through what we do with DNSSEC. 
Of course, we started out researching DNSSEC in the beginning when
the protocol was just introduced but didn't have much of a use case
for it until the Kaminsky attack came along in 2008.

 In 2008, our connected institutions asked us to research DNSSEC
specifically because they felt it might offer a solution to this DNS
attack.  In 2009, we published a white paper on DNS security called
"hardening the Internet" which you can find on the URL displayed on
this slide.  We were the first large Internet provider in the
Netherlands to enable DNSSEC support on our resolver infrastructure
and we helped in setting up the DNSSEC dot NL platform which was set
up to research what it entails to deploy DNSSEC for the dot NL top-
level domain.

 In 2010, of course, the root and dot NL were both signed and
SURFNet implemented DNSSEC in its Surf domain and managed DNS system,
which is a system that our connected institutions can use to both
register domains as well as manage DNS zones.

 And we were also the first participant in SIDN's "Friends and Fans"
program which means we were the first signed dot NL domain.

 Now, this slide shows two screens of our SURF domain and managed
DNS system.  This is a system where our connected institutions can
register domains.  They can edit DNS zones.  And we wanted to extend
the system with DNS functionality to make it easy for them to
implement DNSSEC for their zones.

 So this slide contains a brief set of requirements and design
choices we made while setting up this system.  The most important
thing is that DNSSEC should be easy users.  As you all know, DNSSEC
can be very hard to implement, and we wanted to take away all the
hard options from our users and make it a push-button solution.

 Furthermore, DNSSEC should be quick.  If you turn on DNSSEC, it
shouldn't take very long before your zone is signed and it is on the
Internet.  Apart from that, it also shouldn't influence the
performance of the system.  Users that make changes to the system
expect them to be online very quickly.  For instance, now if they
make a change, it takes about five minutes for it to come online. 
This shouldn't change if we implement DNSSEC.

 Because we participate in the OpenDNSSEC project, we also want to
use OpenDNSSEC as a signing system.  And we want to use hardware
security modules for key storage because we feel that this is an
important way to protect the key material.

 Finally, we wanted to design redundancy and security in from the
bottom up because we want our system to be robust, for instance, if a
data center fails.

 This slide shows our end result.  Basically, you shouldn't pay
attention to the text in the dialogues because it is all in Dutch. 
But what it shows you from left to right is the way our system works.
When a user has a zone that is unsigned on the left-hand side they
see a gray shield which indicates that the zone is not signed.  When
they push the button, enable DNSSEC, a spinnable will start running
while the process of signing is ongoing.  When the sign zone has been
published on the Internet, the shield turns blue and that is all they
have to do to enable DNSSEC.  We go from an unsigned to a signed zone
in about 15 minutes.  

 The most important aspect is what have we learned while we make
this deployment.  Well, one of the first things we learned is that no
matter how much you test something always goes wrong.  We signed
SURFnet.NL for the first time in September on a Monday.  Everything
looked great.  It worked smoothly, a signed zone was served out to
the Internet and all the seconders validated until Thursday evening. 
I got a phone call from a colleague who said, You turned on this
DNSSEC thing and I can no longer read my e-mail.  Do you know what
happened?

 So I started to get a bit scared at that point and had to look at
our systems.  And it turned out that half our zone had gone, which
meant no more e-mail, no more Web sites, no more voice over IP.  So
we had a bit of an issue.

 As it turned out, there was a component in OpenDNSSEC that
contained a bug.  We set our system up as a bump in the wire, which
means we have a public -- hidden primary system, a DNS signer and
public primary system.  And the zone is transferred from the hidden
primary to the signer where it gets signed and then transferred out
to the public primary which serves it out to the Internet.

 As it turned out, the component that pulls in the zone from the
hidden primary had a bug which meant that only about half the zone
was being transmitted.  This meant that everything below the letter S
in the alphabet had gone from the zone.  So garbage in, garbage out. 
The signer signed whatever it got in and served it to the Internet. 
And because our e-mail system is based on Zimbra, which starts with
the letter Z, and because WW starts with a W, all these sites were
gone.  So this was a bit of a problem.  So what did we do?  Well, we
fixed the bug in OpenDNSSEC and resubmitted that back to the project
and we also removed this component from our setup and replaced it
with a secure copy so we could check whether the whole zone had
arrived on the signer.

 When we set up our system, we paid a lot of attention to
monitoring.  We felt that the only way to detect problems in an
online system is to do continuous monitoring.  And what we actually
do is that we monitor several aspects of our DNSSEC setup.  We
monitor validation continuously so we check if key records in our
zone validate currently.  We check signature expiration which means
we pull in the whole zone and check whether signatures are about to
expire or not.  We monitor whether the HSMs are available, and we
monitor whether the signers are available.  As it turned out, this
was a very good move because this monitoring actually saved us from a
disaster.

 One of our HSMs experienced a connection problem a couple of weeks
ago and that meant that the zone wasn't getting re-signed.  And
because we do monitoring of signature expiration, we got an e-mail
that said, "Hold on.  Your signatures are about to expire" and, of
course, that should never happen because the system continuously re-
signs.  So this pulled our attention towards a problem and we were
able to solve it in time without any damage because our signatures
were still valid.  

 That brings me on to policies.  We put a lot of effort into
designing our policies to be sensible, and one of the most important
things we did is we thought about signature lifetime.  So what we do
is our signatures are valid for seven days, but the zone gets re-
signed at least three days before the signatures expire.  So that
means that if there is a problem with re-signing, we have three days
to fix the problem, which is exactly what happened when one of the
HSMs had a connection problem.

 Another aspect that you should pay attention to is your secondary
name servers.  SURFnet dot NL is not only served on our own
infrastructure but we also piggyback on the infrastructure of some of
our colleagues in the U.K.  As it turned out, they ran a very old
version of BIND on their name servers which meant that they weren't
able to serve out certain DNS records, specifically NSEC3 records. 
And what you should keep in mind, if you run something like Redhead
5.x, which is a very common server setup, you should upgrade your
version of BIND at least on your secondary name servers.

 Now, to finish off, we have documented all the design decisions and
requirements that we made for our DNSSEC deployment on a blog.  The
URL is in the slide shown here.  So please, if you want to learn more
about our setup, go to the blog and read some of the articles there.

 That is it.  If you have any questions, feel free to send me an e-
mail.  I will try to answer your questions as quickly as possible. 
And thank you for your attention.

 >>STEVE CROCKER:  Thanks a very nice presentation.  Obviously, it
is not interactive.  And so we won't be able to take any questions,
or if we took them, we wouldn't be able to do anything with them. 
We're going to take a very short break.  Let me ask you to come back
in no more than 7 minutes.  There's some refreshments outside, I
hope.  Not sure.

 Let's see.  Aim for -- let me be specific -- 10:35 max.  That's
eight minutes.  Thank you.  We'll start up promptly then.

 [ Break ]

 [Scribes have no audio]

 >>RUSS MUNDY:  I guess a mic check first.  It is okay.  Great. 
Thank you.

 Glad to have this chance to talk about some of the open source
tools that are out there and existent -- in existence for DNS security.

 The first -- this is really a two-part presentation.  The first
part is really focused on the toolkit that our organization has put
together and has made available on DNSSEC-tools.  The second part of
the presentation is about a survey that we present -- or that we
provide to the community on what, on a broad scale, we can find,
everything we can find in the world on open source tools.

 We have some commercial products in there, but the main focus is on
open source also in the survey.

 So the first part is an example of what can be built in terms of
tools, and it's a set of things that we've looked, examined, and
think are necessary to help do DNS security.  

 So the first slide shows a simple illustration of what a end user
is having to do today to get a DNS query answered.

 So you want to know what the World Wide Web DNS record is for some
particular site and so you send that DNS query.  It goes out through
your recursive name server, through an authoritative name -- goes to
an authoritative name server and then eventually gets the information
back to the client.

 Now, none of this can happen unless the holder of the name that
contains that particular Web server is -- has already inserted the
content into DNS.

 So a user can ask for names and get an answer as long as the data
is there, but if it's not today you don't really know if you mistyped
it or whatever.

 So it has -- the process in the very beginning really has to start
with getting content into DNS.

 So in a simple illustration, today if you are going to do DNSSEC
validation, the simplest way to advance into DNSSEC is to have the
holder of the DNSSEC -- of the DNS record for the particular Web
site, have it be a signed zone, put the DNSSEC information into DNS,
in addition to the regular -- the other DNS information, and have a
recursive validating name server that's being used by the client
actually do the validation.

 And that's really the very simplest thing that is needed for the
beginning of DNSSEC, if you will.

 So within a set of tools that we've developed to facilitate this
and many other things, one of the most important selling points is,
these things are, by their very nature, intended to be completely
free.  The license is a Berkeley license, so they can be used in
commercial products, they can modified, they can be done with pretty
much whatever you want to do with them.

 The only provision is you leave our copyright and you can't sue us.

 So the tools site is where these are collected and that's a picture
of the Web site.

 And when you use the set of tools, you can actually then put the
new pieces in place, and you'll see the new arrows drawn there, and
those are the additional things that need to be done over and above
what happens today for regular DNS.

 And when you do this, you have to look at both the key -- the
zoning signing aspects, you have to look at maintaining your keys and
you have to make sure you have the appropriate bandwidth for your
servers as well as a CPU and so forth.

 And so this is really getting all of your server side things ready.

 On the validation side, you have to be able to have a trust anchor,
is the term that's used in the DNSSEC world, which means you have
some place that you, as a validating name server operator, have
decided you will trust.  And today, with the root zone signed,
that's, for most people, going to be the root zone key.

 There's a few more error codes that show up because you have
DNSSEC, and there's some additional troubleshooting things that have
to be able to be looked at.

 So I want to quickly go through some of the tools, not talk about
them in any depth but just to pass by quickly.

 So this is just a bit of a taxonomy of the toolkit from DNSSEC-tools.

 The zone administration tools are really pointed at making it
easier to sign and maintain your signed zone, and so if you are the
operator of an authoritative name server that's serving one or more
zones, there's a set of tools there to help automate and facilitate
all of the signing activities.

 And the set of tools that you see on this picture, these are the
names of the tools that exist in the toolkit.  There's the
zonesigner, which is the one that's -- obviously people think about,
that you have to get the DNSSEC information created and put into the
zone.

 There's a zone -- there's a mapper tool.

 There's a tool for examining whether or not the master file you've
created for the zone is properly structured and has the proper content.

 So the zonesigner tool, like I say, is what actually does the
signing.

 Rollerd is a tool that rolls your keys in an automated manner and
the defaults are in accordance with published RFCs.  Donuts is a tool
that examines your zone content that you've put in.  Before you
actually load the content, you can look and see if that content is
structured properly and contains all of the right records.

 There's a tool called "mapper" which this is an illustration of the
output of that tool, and it gives you a graphic picture of the state
of each name in your zone, and so you can, if you so choose, just
have this running on some display somewhere, and it updates at your
choice of frequency, and you can see visually whether or not
something needs to be done long before it expires or has another
problem.

 So the authoritative server tools are largely a subset of the zone
administration tools that I just talked about, and that's where they
go in the overall chain.

 Now, we'll get to the validating recursive server tools.

 This is somebody that's sitting -- whether it's in an enterprise or
an ISP operation, you'll hear more from Comcast in a little while and
this is the set of activities they are very focused on, doing
recursive name service with DNSSEC validation.

 And there -- you of course have to have your trust anchor and
there's a way to get updates.  That's what the trustman is about. 
And this can all be set up so that it happens automatically.

 There's debugging tools, which we'll show little pictures of those.

 And then there's some logwatch tools.

 So you can see in the overall picture, this is at the validating
recursive name server, where these tools are sitting, and trustman,
like I say, is a tool that's intended to watch and keep track of your
trust anchor and if it has changes coming, it will go and fetch those
changes, so you always have a current trust anchor or trust anchors
in place to do your validation from.

 DNS packet flow is a tool that was developed that actually looks at
DNS packets.  It's not explicitly DNSSEC.  This is a simple
illustration of a very simple DNS packet flow.

 The next one, drawn with the same tool, is an illustration of how
many DNS queries it takes to fill a browser for just our relatively
simple tool site that I showed you earlier, and if you happen to be
CNN.com, it takes a lot more queries.

 So this is also put in, to make the point that when you or a user
or a customer goes to a Web site, there are many, many, many DNS
queries that get generated.  Not just the URL at the top of the page.
That tool lets you see them.

 Logwatch is a tool that lets you examine any logging information
and pull out the data that applies to DNSSEC, so you can examine
either after the fact or upcoming things you need to look at.

 End user tools.

 And these are where we're really getting to moving the validation
closer to the end user.

 Now, in this case, though the illustration still shows it happening
at the validating recursive name server, you can do validation or
recursive name server all the way to the end device, if you so choose.

 We have a set of libraries that let you do that.  There is also a
separate function that's available in the toolkit called libval_shim
that lets you put software on an operating system that will do
validation for every single DNS query going in and out of that system.

 The applications won't have any knowledge of it, but the operating
system will be doing DNSSEC validation.

 And I'd like to just point that this was one of the items that was
raised in the first panel, that this is one of those tools that lets
you do DNSSEC validation today even before the vendors have provided
it as a full-blown support in their operating systems.

 DNSSEC-aware validation applications.  We have quite a few of
those, actually.

 There's a set of developer resources which I'll go over very quickly.

 There's an API itself that talks how you can -- how you can and
should interface between applications and the actual validation
library functions themselves.

 And one of the things that needs to be really done is the Unbound
API and the API for our toolkit are, in fact, different and the
developers of both have agreed that we want to get them back
together, and so that work will be going on in the IETF to develop a
standard API.

 Now, the -- the Firefox is actually a set of patches to the Firefox
code itself.

 If you just do a plug-in, it validates the top URL at the top of
the page, but as I showed in the earlier number DNS queries on a
standard Web -- on a normal Web page, there are many URLs in the
center of the page, and in fact, if you validate only the one at the
top, this is better than not doing any validation, but you still have
the risk of having URLs in the middle of the page hijacked and in
fact, we've shown that last summer where we did a real-time
demonstration of Steve Crocker admitting that DNSSEC won't solve
world hunger.

 But that was done in real-time.  We didn't put it together for this
one.  But that was done on this Web page, and so it is important to
eventually, when you get to the end system, be able to validate all
DNS queries going -- in use by applications.

 We also have a Thunderbird set of extensions that, coupled with a
mail system, will let you validate e-mail.

 Now, this is a Nokia N900.  The picture you see on the screen at
this point is actually an application that runs on the Nokia N900. 
So size and getting close to the user, well, a DNSSEC-aware phone
gets pretty close to the user, and that is actually available for
N900 users today, and it's through the normal distribution chain for
the Maemo distribution.  That's the Linux derivative that runs on the
N900.

 Some of the postfix sendmail SPF extensions are available in the
toolkit that, used in conjunction with the Thunderbird, gives you a
full DNSSEC-capable mail system.

 The wget FTP, a batch of FTP protocols have patches available to
make them DNSSEC-aware.

 OpenSSH has actually, for some length of time, had DNSSEC
capability in it and available, and it continues to be available but
is, as far as we can tell, not very widely used.

 Lots of documentation is available on our Web site.  Elsewhere too.

 Now, here's a picture that sort of tries to illustrate putting
everything together on one slide of where the tools that-our toolkit,
DNSSEC-tools.org, provides as available.

 So this is -- there's a lot of tools here and I've gone over them
very quickly, so I won't try to cover any more on the specific tools.

 I want to jump right now to our survey of available resources.

 Unfortunately the new blog wikified Web site that we're using
doesn't lend itself to short URLs, so this slide has a very small
font URL on it, and that's where the survey data is located and we
urge people to take a look and if you have other tools, if you know
of other tools, the actual place in the system is a wiki, so you can
do the update yourself.  You can send them to myself or anyone on our
team, sparta.dnssec@dnslabs.com.  We have on the survey itself, we've
grouped the tools by their general functionality.  The -- the
functionality isn't, by any means, consistent across the tools.  They
-- we've tried to hit the major function for each of the tools.  Some
tools are listed multiple times because they do a lot of different
functions.

 Right now, there's about 100 entries, or a little more, in the
survey.  And the good news is, the number of tools continues to grow.
The bad news is, it makes it a lot harder for us to keep the survey
up and I'm sure that it's badly -- well, I won't say badly out of
date.  It's certainly out of date.  There's tools out there that we
don't know about or we've just heard about, haven't had time to put in.

 One of them in that category is the recently announced toolkit from
Dan Kaminsky, Freebird, and that's available on the Black Hat site.

 Actually the URL there is for the survey.  Again, there's a set of
slides from the Monday beginners session that has the URL for the
Freebird site in it.

 So this is a real quick run-through of some of the categories.

 The name servers available, BIND, NSD, Unbound, OpenDNSSEC, that
are the major open source DNSSEC-aware name servers.

 Key generation and zone signing, there is some overlap here. 
Again, because of the functionality that's accomplished by the
various toolkits.

 So for those of you that are using existing software, many of the
categories -- open source software, I'm sorry -- that are in this
section, you can add in these pieces to your existing infrastructure
rather than tearing your infrastructure apart and putting a whole new
one in.

 Key rollover, this is an important aspect of keeping your keys up
to date.  

 There's hardware interface for those folks that want to use modules
with -- for the signing functionality and the graphic mechanisms.

 There's a set of tools talking about troubleshooting for the zones,
and there are a range of things that look at different aspects of
where there might be problems in a zone.

 DS record creation.  You also have to be able to get your -- your
DS record up to your parent, and there are various relationships and
various ways of doing this.

 Many of them involve passing through a registrar, but not all of
them do, and a number of these tools are designed specifically for
organizations that have a direct relationship with their parent and
want to automate that update without -- and don't have a registrar
sitting in the middle.

 Key updating, key fetching information, this is for automating your
updates to your keys that you need for both -- I'm sorry, for your
validation function.

 Automated trust anchor rollover.  

 Troubleshooting tools.  A wide range of troubleshooting tools that
relate to DNSSEC are available.

 And here's a list of DNSSEC-capable applications.

 As you can see, it fills the slide.  I haven't quite gone to the
second slide yet, but I also haven't, for instance, listed the N900
application on there for doing validation.

 So there are actually quite a large number of applications that
have been instrumented to be DNSSEC-aware and can do DNSSEC today.

 And the validation libraries for those that want to have the
capability on their particular platform -- usually an operating
system -- to do validation of DNSSEC without having applications
necessarily know that it's going on underneath of them.  

 Some Perl software development kits, because there is a lot of
software in the Perl world that ties to DNSSEC.

 The validator API, the two that are listed there, the one from
DNSSEC tools and the one from Unbound.

 Testing resources, there's a number of testing resources, one of
which is from Roy Arends that allows you to generate packets that are
mangled in some manner.  Another one is out of our toolkit that
allows you to generate zones that have intentional errors in them,
because one of the things we've seen over the years of working on
DNSSEC signing and checking and validating and so forth, the actual
mechanisms in the software that create the signed zones have been so
extensively and exhaustively tested, it's hard to get a bad zone
created, and so you can't tell if your validator is properly working
and failing things when they should be failed.

 So these are tools that -- that let you do this type of testing
against your zone that you're responsible for.

 There's operator guidance and documentation, and in summary,
there's a lot of stuff out there.

 Now, much of what you see is indeed pointed at the open source
world, so people that are in the product realm of things such as
folks that are using a Microsoft-centric infrastructure, they have in
their Windows 7 and I believe it's Windows 2008 release, they have an
initial DNSSEC implementation so they have started supporting it.

 There are hardware -- additional hardware vendors that have one-
step type of solutions.

 So there are more and more tools coming out available all the time,
and like I say, we try to keep up in the survey.

 Please feel free to look at, give us feedback if we've missed
something, if we've got something wrong.  We certainly want to get it
fixed.

 And one comment that I want to add, just at the end of my
presentation here, that came up in the earlier panel, and that was
with respect to where you do validation.

 And because of the early nature of people in their zone signing and
their mechanisms -- and we've seen some mistakes made in keeping
signed zones signed -- there was a comment from the chatroom that
initially it might be wiser to start out doing validation primarily
at the DNS-aware validating, ISP-operated, knowledgeable DNSSEC
places so when problems like this come up, that they can be handled
more -- by more knowledgeable DNS people.

 So that's something I just wanted to bring up at this point because
it did -- the conversation moved on in a previous panel but I put it
out there to get it in the record.

 And I think we need to probably move on.  I don't think we have
time for questions, so João?

 >>JOÃO DAMAS: Thank you, Russ.  So presentation -- sorry.  I'm João
Damas.  I work for ISC.  We are the developers of BIND.  

 Is that the first slide?  Oh, okay.  Sorry.  It was my fault then.

 So the talk "DNS for Humans" is actually about protocol
implementation for the name server, which is BIND.  BIND 9.7 in this
case.  

 It's just going to be a brief overview.  Because of some mistakes I
made when the original came up, I also give a hint of BIND 10 because
it was mentioned in the beginning even though it's not related to DNS
for humans.

 What's the idea with this whole DNSSEC for humans initiative that
we did with BIND 9.7?

 BIND has supported DNSSEC throughout the whole history of the
protocol development, but it's been more of a tool for hard-core
people, geeks, working on actually the development of the protocol
and not so much something that was easy to use for an ISP or a
network administrator to provide the service.

 So we tried to actually take that and fix it so that people
wouldn't find this task daunting.

 So it's all about automation.  It's all about supporting additional
facilities that -- machinery that is common at ISPs or enterprises
that are familiar with handling keys and making life easier for people.

 Okay.  In automation, for instance, one thing that does with
respect -- that's different with respect to the previous version is
that once the zone is signed, if you tell it to keep an eye on it,
BIND will make sure that the signatures never expire, that things are
rotated as they should, and that your zone stays operational,
preventing some of the errors that have been mentioned earlier.

 There is also support for the RFC 5011 automatic trust anchor
rotation that's for use at the ISPs validating resolvers.

 Before, it would have to be a human looking at one particular TLD
or any given zone that would change their keys and you would have to
go in manually and update it, change it.  That was a very easy thing
to make a mistake at, and lead to an error, so that's also automated
now.

 In an ideal world, the only key that you would have to rotate would
be the root key, of course.

 Support for HSMs was also introduced.  HSMs -- hardware security
modules -- are specialized machines, computers, that protect key
material.  They are usually seen on https Web sites, for instance, as
the place where you would store the keys so that they are in a safe
place and they are not messed with, broken into, and so on.  

 So BIND now supports storage of keys in that type of machinery as
well, and it includes the tools to manage it.

 Not only -- because these machines are usually not all that easy to
deal with.  

 This is dynamic DNS for zones for which there is a need to use
dynamic DNS because it is like laptops, machines that go in and out
of network and see the HTTP assignments or user mitigations on a very
regular basis and resort to the dynamic DNS as a way of managing that
rate of change.  You can now have full support for managing DNSSEC
operational on those kinds of zones as well.

 The usual type of agreements -- of improvements, better
performance, which is always good as things scale up.  New algorithm
support, as time goes by, older algorithms are not so recommended
anymore and new ones are introduced.  We introduce support for SHA2,
which is a new set of algorithms.  Some people are already starting
to use them.  And GOST which was a Russian security protocol for
which there was some demand for using in particular cases, and why not?

 Because this is all about security, we also -- I also wanted to
point out DNSSEC is trying to provide additional layers of security,
but there is a lot more things that you have to keep thinking about
at all times regarding improving security.  One of the things we
added to BIND 9.7 in this respect was prevention of DNS rebinding
attacks, which some people were suffering.

 What is to be included?  Even though the whole 6 signing process is
now automated, we haven't include support for automated key
management.  So there is no automated way of creating running keys
and so on.  There is a bit of a discussion on whether this is
actually necessary.

 Arguably you choose a cryptographic algorithm because it does
provide protection.  If that's the case, then your keys would be safe
no matter for how long it's used.  And you don't actually get any
additional safety by rotating the keys because if you are afraid of
having your keys broken, then what you should be looking probably is
at the different algorithm, not at just shifting the keys all the
time.  And also shifting keys has operational impact, right?  Every
time you make a change like that, you're bound to make a mistake that
then ripples out through the network.

 There is one feature that we were talking about, which is bumping
the wire signing.  What does this mean?  When this is implemented,
you could potentially use BIND as a drop-in box in your current DNS
work flow where the zone is generated, put up in a server, moved to
the secondaries.  It is very much what OpenDNSSEC does in that
respect.  You add an additional machine and not change any of the
existing processes that you already have in place.  You just
introduce an interception where DNSSEC would be injected.

 That's all I had to say about, 9.7.  Because, as I said before, the
type of BIND back then, I just wanted to have a slide on clarifying
what was that all about.  Well, BIND9 of, which BIND9.7 is one more
release, has been around for a while.  It has been around for more
than 11 years.  And as any other piece of software that you probably
use, when software has been around and under active development for
such a long period, it becomes less clean, as it goes.  

 Also, the models that you use to architect things may need some
refresh because the world changes.  That's what BIND9 is doing.  It
is a rethought of how BIND should be working and the new approach so
that it supports better the realities of today.  It will be released
at the production-ready level next year, 2011, towards the end of the
year.  But there are better versions now.  If you want to look, you
can look at now and give us feedback because it is actually a good
time to tell us what you are missing, what you would like to be done
differently.

 And the overall list of things that is included in 9.7 is listed
there.  With that, I'm complete.

 >>STEVE CROCKER:  Thank you, João.  Let me jump in with a question.
2011 is hard upon us.  Are you talking about early 2011, late 2011? 
I think there is quite a bit of interest, and it will be quite
helpful to get feedback whenever the time is.  And in terms of --
oops -- in terms of these sessions, I would anticipate that we would
like to schedule a -- sort of the second half of your talk, in a way,
incorporating the initial feedback and report on usability and
performance and complexity and so forth.  What's your guess?

 >>JOÃO DAMAS:  The release target is late 2011.  So you would be
talking 11, 12 months from now.

 >>STEVE CROCKER:  Okay.  So -- I don't think we have any idea where
we're going to be -- where the ICANN meeting is going to be.  But
what we're targeting is, basically, this meeting late in the year. 
Okay.  Future attractions.  Thank you.

 Any other questions?  Good.  We're running a little behind, so we
did want to structure this session so there is time for questions but
I'm equally happy to move right along.

 The next part of this is a panel discussion that will be moderated
by Simon.  And I guess we have several people who need to make their
way up here.  Ondrej, is Matt here?  He's in the GAC room?  And Ram
and Rickard and João is here and we are going to bring Rick Lamb in
by Skype.

 >>RICK LAMB:  For what it's worth, I'm here.

 >>STEVE CROCKER:  Thanks, Rick.  Thank you for getting up early. 
You are three time zones earlier, right?

 >>RICK LAMB:  Yeah, just a bit.

 >>SIMON McCALLA:  Hello?  Great.  Good morning.  Welcome,
everybody, to the second panel today.  Thank you all for coming.  The
aim of this panel is to take a look into some of the more technical
details behind DNSSEC implementations, take a look at how it has been
deployed around the world and take a look at the variety and styles
of deployment that have been used for DNSSEC.

 I'm delighted and honored to be joined by a very, very
distinguished panel, both physically here in the room and also
electronically on the wire.  This panel has an enormous amount of
depth of experience of either designing or implementing DNSSEC.  

 So without further ado, let me introduce your panel.  On my left
here we have Ondrej Filip who is the CEO of CZ.NIC.  I think you have
the largest number of signs DNSSEC domains in the world at the
moment.  Is that correct, Ondrej?  It is fantastic to have him here.  

 On the wire, from the West Coast, we have Rick Lamb from ICANN who
needs no real introduction but I will anyway.  He was clearly one of
the great architects of the root signing ceremony and heavily
involved in that.  

 Hi, Rick.  Are you with us?

 >>RICK LAMB:  Yes, I am.

 >>SIMON McCALLA:  Brilliant.  Welcome.  Welcome to the panel.

 To my left over here, we have Matt Larson who is the VP of research
at VeriSign.  Matt was very much part of the root signing ceremony
and also one of the key architects of DNSSEC.  Welcome, Matt.

 Over to my right, we have Rickard Bellgrim.  He is a DNSSEC project
manager at dot SE.  He is one of the key organizers also behind the
OpenDNSSEC project.  Welcome.  Thanks for joining us.

 We have João Damas, who I'm sure you have already seen speak, but
he works for ISC and has just been telling you about how BIND has
DNSSEC integration built in.  That's fantastic.

 We are hoped to be joined by Ram Mohan as well, but we'll commence
as we are anyway.  So, gentlemen, thank you very much for joining us
today.  We are going to kick off with a short presentation from each
of the panel on their experiences.  And we asked them really four key
questions about their experiences of DNSSEC.  So each one of them is
going to try to answer those four key questions.  Here we go.  

 We're asking:  What are the high-level design decisions did you
make behind DNSSEC?  How did you implement and introduce DNSSEC into
your live environment, which is really key.  What were the challenges
you faced?  And what were the lessons you learned?  Nice, simple
questions.  

 Without further ado, I think we will kick off.  Ondrej, are you
okay to kick off first?

 >>ONDREJ FILIP:  Can you hear me?  Thank you very much.  My name is
Ondrej Filip, and I'm from dot CZ, the Czech domain registry.  I will
not beat around the bush.  I will try to focus on the four questions
the chairman sent us.  

 If I can ask for the next slide.

 The high-level design of full implementation is basically two
parts, which are interesting from the technical point of view.  One
is the whole DNS system.  So we use currently NSEC3 with RSASHA512. 
We were probably the first registry who migrated from NSEC to NSEC3. 
We used key signing key, which is 2048 bits.  And we do a rollover or
we plan to do a rollover every two years.  We have the zone signing
key, which is 1024 bits, and we do a rollover every two months.  

 Currently, we use, I think, well-known tools for the key signing
which is BIND and ZKT, so Open Source two that are available.  I
think much more interesting is the -- how it is implemented inside
the registry.  Maybe some of you know that we developed our own Open
Source registry registration called Fred.  It is not used just by us
but there are some other mainly smaller registries that also use this
system because it is free.  Everyone can use it, and the source code
is available.

 We wanted to follow exactly the same scheme for DNSSEC as for the
domain name registration.  So we do not address the registrant
directly.  We have registrars, and those somehow deal with the
registrant.  So the information about DNSkeys is transferred to us by
EPP protocol, which we accordingly modify.

 And we introduced maybe one interesting feature.  And we have a lot
of reasons why to do it.  We call it, for example, key sharing.  Next
slide, please.

 It is a quite interesting thing.  In our database, there is object
domain, it has some registrants and it has some number of
administrative contacts.  And, also, it points to another object,
which is a name server set.  And this name server set has some list
of name servers and technical contacts.  It means that this object
can be shared among a lot of domains.  And we reuse the failovers
again for key set.  

 So the registrant does not send us DS recall but the whole public
part of the key.  And this key set is attached to multiple domains,
and we calculate DS records on behalf of the end user.  

 Why did we decide to do so?  The main reason was to allow big
domain name operators to be able to use just a single key for
multiple domains, so they can easily roll over that key.  They can
easily change name server and everything.  So those are the main
reasons to have those guys with a lot of domains to easily operate in
our environment because the majority of all domains is registered or
run by those guys, not by any end users directly.  Next slide, please.

 The deployment started somewhere at the end of 2007.  We made our
first public announcement in 2008.  That's an interesting story.  It
started DNSSEC project after discussion with Steve Crocker when he
attended a Prague IETF meeting.  The public announcement was on March
2008.  And in April, we signed ENUM zone.  We use ENUM zone very
often just for testing because it is not so critical domain.  So
after internal tests, we signed ENUM zone.  Then we wait some time
for public comments and we signed Czech domain at dot CZ during
September 2008.  And at the end of September, we opened our registry
for end user public key registrations, so (inaudible) DS records.  

 And then as I mentioned and in August of this year, we make
transition from NSEC to NSEC3.  So what are the current results?  We
have roughly about 109,000 domains in total which is the highest
number in the world.  It is probably more than the worldwide
together.  

 Why this happened?  There is a lot of end users that sign their
domains, but the majority of this number is made by two registrars
who decided by default to sign all domains for end users that do not
protest or have some sort of opt-out conditions.  

 And we are discussing with other registrars, and we believe that
some will join this initiative.  So we will have a really huge
penetration of DNSSEC inside Czech domain.  Next slide, please.

 I was asked to briefly discuss some challenges.  I spred into two
things.  First is technical challenges.  They were easy.  Always if
you have some technical challenge, you discover some people.  Some of
them find a solution and the others can follow.  So that's pretty
easy process that can be replicated that's understandable.  At that
time, when we started that, we have a lot of software support.  There
was some back-end implementation.  But that was the situation of the
year 2008.  Now, two years later, we are a completely different
environment.

 We had to use -- what to do with large zone, how to transfer
updates because, of course, if you re-sign, complete the domain, that
is a huge update.  So we had to implement signature reusing and all
the things which are, for example, in OpenDNSSEC now automatically, I
guess.  So those were issues from 2008.  But the hard part was the
communication, how to spread DNSSEC, how to make it visible in the
end user community.

 And one thing which complicated our job was that signed and
unsigned domains look exactly the same and does exactly the same
thing.  So we need to solve the issue of visibility of domains.  So
that's why we made a FireFox add-on or a FireFox DNSSEC plug-in which
is very popular.  We have a lot of downloads.  That is, basically, a
green or red or whatever color key inside the URL box so you can very
quickly see if your domain is signed, if your provider is validating
and so on.  

 So there was a lot of issues which I will not go into detail but we
tried companies, newspapers, also government, for example, EU2009.CZ
which was the official domain of the Czech EU presidency was the
first signed -- first signed domain of EU presidency.  We also did
some sweet conditions for registrars.  We didn't charge anything.  We
also gave them more money for marketing if they used DNSSEC.  And
there has been a lot of effort to discuss validation of ISPs.  That's
the very hard part.

 Next slide, please.  Our lessons and maybe conclusions we made from
all this effort, we believe that DNSSEC needs to have somebody who is
trying to market it, who is trying to spread it.  And we believe it
is the registry responsibility.  We always communicated that it's not
some special service, that it shouldn't be charged so broadly.  It is
just a feature or natural part of the domains the same as you have an
airbag in your car.  

 You can't be alone.  You need to find allies.  You need to be very
communicative with them.  And we proved that it can be deployed at a
larger scale.  Of course, there are some technical things.  But as I
said, those are easy.

 And maybe one more thing that's interesting.  When we started
DNSSEC or registrars signed the domains, we didn't realize we can
share some resources with other TLDs because, for example, when dot
EU started DNSSEC, those registrars that signed all the CZ domains
also signed all the EU domains.  That means we are not alone.  And
each TLD that signs helps the others.  It is a very good example of
direct communication, the nature of sharing resources.  That's all
from my side.  Thank you very much.

 >>SIMON McCALLA:  Fantastic, Ondrej.  That's great.  I would like
to bring in Rick Lamb now remotely, if that's possible.  Rick, we are
just putting your slides up.  Okay, Rick, over to you.  Rick, can you
hear us?

 >>RICK LAMB:  Hello.  Does this work?

 >>SIMON McCALLA:  Yep, we can hear you.

 >>RICK LAMB:  All right.  Great.  Thanks.

 All right.  Well, my name is Rick Lamb.  I'm the DNSSEC program
manager at ICANN and the architect for a lot of the work that was
done with DNSSEC there over the years.  Next slide, please.

 First off, I would like to make it clear that this was a joint
effort with VeriSign and the Department of Commerce and so we learned
an awful lot from this teamwork.  The teamwork here was really
amazing.  We learned an awful lot of things, and this could not have
been possible without us all working together actually to get to this
goal.  Next slide, please.

 Okay.  The high-level design, as was said, this was a team effort
with a number of different groups.  And the goal here was to come up
with a system -- our goal was to come up with a system that people
will use.  I mean, anybody can create a signed root.  Anybody can
deploy this.  But it's got to be something that people trust in and
find usable and available and all that.  So in the end, we had to
come up with a trustworthy system.

 So the high-level design broke down to three basic items here:  How
do we build a system that has a certain level of trust and integrity?
And that required transparent operations.  And I'd like to make --
quote a line that I read from Judge Brandeis, "Sunshine is the best
disinfectant."  This is the principle for accountability and
transparency.  

 One of the things that went throughout our whole operational and
whole design was to make sure every part of it could be published and
shown to the public or to the Internet community in any way possible.

 So to further follow on the trust/integrity bullet, direct public
participation by the public in the key management and third-party
audit.  The audit is to gain trust.  You are going to say what you
are going to do, do what you are going to say and then have a third-
party check it.

 And then, of course, the security aspect.  No one is going to trust
a system that does not have -- does not pay a certain amount of
ability to do security.  So we have a crypto security, physical
security and then (poor audio) protection, access control, multi-
person access and control systems in place.

 Finally, availability, particularly for the root.  For the root
zone, it absolutely has to be available all the time.  So there needs
to be -- we made sure that our design has sufficient time between
operations to perform the operations.  We have mirror sites.  And
some of the things that often are overlooked is to have pre-
documented, predesigned disaster recovery plans in place as well. 
Again, there are overall -- the overall picture here is to try to
come up with a system that the public can trust use, rely on and
depend on.  So these were things we found critical.  So our high-
level design encompassed those elements.

 Next slide, please.

 Okay.  How do we implement and roll this out?  As I said, earlier,
I made sure we publish every piece of material we generate from the
key ceremony as well as any software that we use.  The software is
published.  The DVD is published, the film, scripts, everything. 
There is a Web site up there for that.

 And this, by the way, is a rare case.  A lot of security-type
operations like this do not typically publish all this sort of
information, but we decided early on that this was a critical part.

 We have something called a DNSSEC Practices Statement, and this
parallels a lot of what we learned from the certification authority
community, the DPS.  This is part of saying what we are going to do
and doing what we are going to say.  This is where we publicly say,
"Here is how we operate our signing system."

 And then in order to get the public participation directly
involved, we got 21 trust community representatives from around the
world, 18 of which are non-U.S., by the way.  And these people form a
very critical part to this whole thing.  As I said in the beginning,
anybody can create a signed root zone file and publish it.  That's
not special.  Why would you trust this one?  Why would you trust
ICANN?  I mean --

 [ Laughter ]

 The only wasn't we could ensure this is to get the direct
involvement of respected DNS technical community members in here, and
we were fortunate enough to be able to get 21 of them to get involved
in this.  Without these guys, this would have been just one expensive
science experiment.

 But with them, we actually have something that can be a global
source of trust and maybe a platform hopefully for innovation,
security solutions and authentication identity, all these things in
the future.  So they are a critical part of this.  And I always have
to mention them and thank them for being willing on their own dime
and their own time participate as trusted community representatives.

 Okay.  Then we have to make sure that someone audits and does the
proofs that we are do willing what we said.  So we have something
called a SysTrust audit.  That's by a big four accounting form.  They
basically -- SysTrust is an internationally recognized certification.
They come in and analyze our processes.  And we are in the midst of
that right now.  We are hoping to pass that.  But this is something
that is an annual process and hopefully add further trust to the
operations.

 And then some of the technical details, as many of you already
know, the KSKs, 1048 bits, the ZSK is 1024.  There are RSA keys and
we are using a SHA256 hash.  From the crypto components also we are
using a -- this is just a U.S. certification, but it is FIPS 140-2
level 4 hardware security module.  This is what holds the keys. 
Level 4 is the highest level you can buy at that time.  I think it is
still what you can buy at the highest level.  It is designed such
that any tamper, take screws out, shake it too hard, apply high
temperatures, do anything strange to it, even strange power
fluctuation, and it deletes everything inside automatically, destroys
the key.

 Unfortunately it doesn't generate any smoke or anything like that. 
It destroys everything and I've tested that, not intentionally, at
least twice and it has been very expensive.  Anyway, so it is a good
way to protect the key.  It works off of three out of seven of these
trust community representatives to enable.  

 The way the TCRs are involved is ICANN cannot by itself use the
private key, half of the KSK.  We have to rely on the trust community
representatives to come in and enable it.  We have three out of seven
of them four times a year coming to locations we have in multiple
sites.

 And the last thing, not to be forgotten, you need a good random
number generator.  A lot of times the failure of crypto is just not
having a good random number generator.  Part of these hardware
security modules come with a certified random number generator.  All
right.

 And then for the physical layers, we have multiple physical tiers,
multi-person control, anti-passback meaning that it actually is the
access control system.  The card readers on each one of the doors are
counting the people in there and who they are and making sure the
right people are in each tier, each room.  

 Wall construction, standard design, 9-gauge stretched metal.  It is
stuck in between drywall.  

 And let's see, 24-by-7 monitoring course.  We have motion
detectors.  This is part of the intrusion detection stuff, motion,
seismic, video and guards that are just part of the facility.  We do
not have our own guards.

 And then as far as the operational time window, we have 60 days to
perform this.  So this goes to the availability question.

 We have a fair amount of time to get this right and, you know, the
signature is the -- we have 60 days, we have multiple sites, mirror
sites in Los Angeles and Washington, D.C., and if that even fails --
and at each site, we have two cryptoboxes holding copies of the
private halves of the KSK, so we have four HSMs in total.  

 We have a documented disaster recovery plan, should, say, these
TCRs not be able to arrive.  We have a way to deal with that.  

 Should -- you know, should something else happen, we have -- we
have the plans all pre-documented, according to this.  

 There are backups of keys used to recreate the key, as well,
available.  

 So then part of this design, the physical design and the
availability here, is to first consider the risks.

 It's very important to consider the risks first before you go about
designing something like that.

 We're looking for undetected compromise as the worst-case.  If we
can detect a compromise, it may be ugly, but, you know, we can find a
way to generate a new key and roll it.  The worst-case is undetected
compromise.  

 So you won't see, you know, armed guards, metal detectors, although
they are there, but you won't -- that's not the focus here.  We're
not trying to protect against a terrorist attack or someone coming in
visually.  

 And each one of these things, including, say, the 9-gauge stretched
metal wall material, all that stuff is designed -- and even the safes
are designed to reveal any effort to try to compromise or open these
things, not necessarily to protect it against every single threat in
the world.

 So this is just an important aspect of that.

 And then finally, in the deployment, this was a very critical part
that a lot of folks at VeriSign helped out with as well.  This was
how do we deploy.  

 We deployed it using something we called the DURZ, deliberately
unvalidatable root zone, and this was something where all the form
factors, if you will -- the size of the keys, all the materials --
was in the root zone so that it would tickle and check various pieces
of equipment that are out there, but they were deliberately not the
right keys or not validatable keys.

 And so this is the way that we were able to roll this out slowly. 
Matt had a very large role in this, and this was, you know, doing
this at one root zone server at a time and carefully monitoring the
traffic, collecting tons of data, doing tons of analysis, and, you
know, thank God going all the way to the last root server, there were
no problems.  So this was actually quite a carefully and delicately
arranged rollout and it all went well.

 Next slide, please.

 >>SIMON McCALLA:  Rick -- it's Simon here, Rick.  We're running a
little bit behind time, so if we can just speed things up a bit, that
would be really helpful for the rest of the panel.

 >>RICK LAMB:  I will.  I will.  Sorry about that.

 >>SIMON McCALLA:  Thank you.

 >>RICK LAMB:  Challenges.  Okay.  So the main thing -- the main
challenges that came out of this thing were finding out what the best
practices were.  

 As I said, finding out how to build these kind of rooms and looking
at all the security stuff.  Companies tend not to reveal this stuff,
so this was very hard.

 That was one challenge.  

 Although we found that even our own NSA that said documents that
said, "Here's how you build a room," so...

 And embracing -- the other challenge was getting the Internet folk
to embrace an audited I.T. security mind-set.  It's not that we don't
care about security -- "we" being, you know, I'm an Internet geek as
well, but it's just a different mentality.  So that was the other
thing that was difficult to get around.

 And then the other challenge was formalizing the documentation. 
Policies and procedures.  I mean, no one likes documentation, but
here's a case where this has to become institutionalized.  It has to
be simple.  It cannot rely on any one person.  And so formalizing
that documentation was the other thing.  

 Contractors, contractors, contractors.  They're never on time. 
That was a really big challenge.  

 And then finally challenge is also a good thing and embracing HSMs
and PKCS11s, smartcards, that whole world, there's a certain
discipline that that comes with, that that actually helps you design
things.  Once you start working in that world, you'll see what the
discipline is and it will force you to do the right thing, which is
really good.  And -- yeah.  

 So next slide.  We're almost done.

 Okay.  Lessons learned.  Sorry for the delay.  I'm watching it on
the video here.

 Lessons learned, okay?

 The first key step, we went around and around trying to figure out.
I mean, we're -- this is going to be the root.  This is really
important.  We could easily go overboard.  We could spend millions
and millions of dollars.  Well, we spent a lot, but, you know, we
could spend an infinite amount of money trying to protect everything.  

 The first thing is, identify the customer, identify who is relying
on you, and identify your risks.  And early on, we were able to
determine that we were not going to protect against global disasters;
that our focus was going to be looking -- being able to detect
compromise and have a plan, documented plan on how to recover from
the compromise.

 That was one of the first steps.

 So -- and the next one is develop these documented policies, key
management, and then listing them kind of order in importance there.  

 First, come up with a key management policy.  How many people do
you need to use the key?  Who are they?  How are they vetted?  How
are they -- who are they?

 A DPS.  Making sure there's some published document that says
"Here's how we do things" for the public to see, scripts that say,
"Here's exactly how you will then execute each."

 We had key ceremonies, but however you want to do your key
management.  

 And then pre-documented disaster recovery plans, something like
that.  That adds a lot of comfort to the people that are relying on
your service.

 And then institutionalize these things, okay?  

 This doesn't have to be expensive.  If there's one message out of
this whole presentation I'd like people to walk away with, it's we
spent a lot of money.  A lot of us that were the early adopters of
DNSSEC, or early deployers, had to spend a lot of money and time to
do this.  You know, together it's not that hard.  It's actually not a
very hard process.

 All right.  Embrace PKCS11 and tamper evident bags.  Very keep way
to add security, just using these tamper evident bags, numerically
ordered bags, and putting various key material in them, as well as
equipment.  Multiple compensating controls.

 There's no such thing as perfect security.  We've learned that. 
You need video intrusion detection systems, motion detection systems.
You need multiple compensating controls.  That's a term of art used
from some of the SysTrust audit requirements as well.

 DNSSEC deployment doesn't have to be expensive.  Learn from those
guys on the panel.  Absolutely.  Because -- and ask -- you know,
we're here to help you try to understand how to do this in your own
deployments.

 And then the final thing that's very important that we learned,
this is not static.  This is a -- not only do you have to make sure
that your signatures don't expire, which certainly we are -- you
know, we're seeing many examples of, and finding people learning the
hard way that you do have to -- this isn't -- DNSSEC is not just a
static thing, but also the documents themselves, the processes
themselves.  This should have a formal annual review and this is a
way to incorporate improvements and make sure that the right people
are -- still have access to the system even.  Something as basic as
that.

 So it really boils down to something as simple as that.

 So I think with that, I'm pretty much at the end of my
presentation.  

 That picture in "Lessons Learned" there is actually Francisco, one
of the internal witnesses out of the last slide, but that's okay, and
he's been -- you know, we have a number of really, really star
players that actually make this -- make this system the trustworthy
system that it is and hopefully a system that, in the future, people
will be able to see -- start to see DNS as a sort of trust and so
that there will be benefits both for the consumer, opportunities for
businesses -- you know, as Chris Wright said earlier, there's room
for innovation here.  You know, I mean, this should be a race to the
top and registrars or whoever can become people who actually sell and
innovate in trust services, now that we have this system in place,
and so -- and hopefully ICANN, in small part, in working in the root
here, can continue to be a trustworthy source of -- source of that
key part of this picture.

 With that, thank you very much.  Sorry for running late.

 >>SIMON McCALLA:  Thanks, Rick.  Thank you very much for that.

 Okay.  We're just going to move on.  Could I just say to all
panelists, we're running really behind time at the moment so if we
can try and keep it to five minutes that would be great.  I'm going
to pass on now to Matt Larson from VeriSign, and Matt, you're good to
go.

 >>MATT LARSON:  Thank you.  Okay.  I've hit "Start" on my iPhone
stopwatch and telling you this is going to take 10 seconds so I'll
start going.

 So I will go fast here.  

 Could I have the next slide, please?

 In terms of the high-level design, I focused on really high-level
parameters.  It occurred to me after seeing Ondrej's presentation, I
should say that both dot com and dot net will be signed with NSEC3
using Opt-Out.  We're using SHA-256 as well.

 But let me go to the bullets that I have on the slide.

 I guess the most significant point of the design is that it's an
entirely custom solution.  Our authoritative server platform is
already custom, and when it came time to integrating DNSSEC, we
realized that there was no way that we could use any off-the-shelf
software, we had to write our own signing system, and as a result,
the signing is very tightly coupled to the registration system.  

 It's done incrementally.  When changes come in via EPP, the data
that needs to be signed is actually signed and committed to the
database before the EPP completion notice is returned to the client.

 Our signing server component that the registration system
interfaces to serves to abstract multiple HSMs for redundancy and
scale, and these are located in multiple facilities, "Tier 4" meaning
four levels of access to get to them.

 On the resolution side, I mentioned ATLAS, our high-performance
custom authoritative name server.  It had to be upgraded to support
DNSSEC.  

 In terms of key management, we've been keeping secrets for a long
time at VeriSign and we have a Cryptographic Business Operations
office and they're managing all the key material.  We're using two
different kinds of HSMs, one to store the zone signing key.  Those,
by necessity, have to be on line.  The KSK itself is kept off line in
the same kind of secure facility that our -- or I should say now that
Symantec root CAs use, and very similar to the -- to the root.

 Next slide, please.

 I think the overall motto of the implementation is that we've been
very cautious and measured throughout, trying to take things very,
very carefully.  

 I have a list of things here that we've done before deployment in
dot net and dot com.  

 We have an EPP SDK to make it easier for registrars to implement. 
We also have an operational test environment that's end to end, so it
also includes a signed dot net zone for resolution.  

 So a registrar can put a change in the OT&E environment by EPP and
then see it come out the other end in a signed dot net zone and do an
end-to-end check.

 We've done various other tools for registrars.  

 As you can see, a tool guide describing how they could deploy
DNSSEC for a Web -- excuse me, a zone hosting solution.

 We've written a paper for registrars about transfers.

 We're offering a service that registrars can sign in the cloud. 
They can send zones to our servers to be signed and we send them back
via zone transfer.  

 So if a registrar has a zone signing service -- or excuse me, a
zone hosting service, they can very easily add signing to it, if they
want, without much work on their part.

 I did want to spend just a brief moment talking about our DNSSEC
interoperability lab.  

 We've got a large suite of tests, and the idea is that software or
hardware vendors with DNSSEC-capable equipment or equipment that they
want to know if it is DNSSEC-capable, they can bring that into our
lab environment, we'll run our battery of tests on it, compare the
results with the baseline that we've established, and then just
report back to the vendor.

 This is not performance testing.  The information is not public. 
There's no VeriSign seal of approval.  It's simply a tool that any
vendor can use if they want to check the DNSSEC capability of their
product.

 So please contact me if you have any questions about that.

 We have sufficient bandwidth for the lab.  We can take more people.
We're very interested in promoting the lab.

 I'd also refer you to the DNSSEC debugging tool, the name of which
is on the slide there.  That investigates a chain of trust for a
domain name and shows you any problems.

 In terms of deployment, we're doing dot net before dot com.  In
fact, we're doing dot net tomorrow.  As of this moment, the dot --

 [ Applause ]

 >>MATT LARSON:  Thank you.  Most unlikely applause line ever.

 [ Laughter ]

 >>MATT LARSON:  So as of this moment, actually the dot net zone is
signed with the actual key in it, and all that remains is to put the
DS record in.  

 Actually, I hope I haven't spoken out of turn by saying it's
tomorrow.  It's planned for tomorrow but we'll hope for the best.

 No.  As far as I know, it's on schedule.

 The registration system was DNSSEC-enabled first, so registrars
have been able to submit DNS records for some time now -- on the
order of a couple of months -- and we did use the deliberately
unvalidatable root zone technique.  

 So as I mentioned -- the reason dot net is signed right now is that
we unobscured it earlier this week.

 Next slide, please.

 So the challenge is -- the biggest challenge was scale.  Just that
the zone is so large, the transaction rate is so fast.

 In particular, the service level agreement times on the
registration system, how fast we have to do EPP transactions, those
times are very tight, and we managed to find HSMs fast enough and
write the software fast enough that we can do as I described, the
signing in line with the EPP transaction.

 Zone size is an obvious issue and why we're using Opt-Out.  

 The other thing is that -- the scope.  

 This has touched every component of our registry system, both on
the registration side and on the resolution side.

 Another big challenge is going to be registrar adoption.  DNSSEC
absolutely needs registrar support to succeed, which is one of the
reasons that we've tried to do as much as we can to make it easy for -
- for registrars, short of actually saying, you know, "Okay, move
over, we'll write the code for you."

 And then perhaps the biggest challenge of all is the importance. 
Dot com and dot net, they just simply can't go down.  They just can't
ever go down.  And so that's the biggest challenge of all.

 So the final slide, please.  In terms of lessons learned, we did
find that incremental deployment is possible.  This is really the
lesson learned from the root zone that Rick mentioned, the DURZ
technique, the deliberately unvalidatable root zone.

 We found a few issues in the EPP extensions for DNSSEC and those
have since been revised.

 We've seen a very minimal increase in TCP queries.  And perhaps the
most important lesson learned of all is that DNSSEC does not break
the Internet.

 The root zone signing was very uneventful.  So far, dot net has
been completely uneventful and we will hope it stays that way.  Thank
you.

 >>SIMON McCALLA:  Thanks very much, Matt.  That's great.  I'd like
to welcome to the panel Ram Mohan.  Ram wasn't with us at the start
but thank you so much for joining us.  

 Ram is the CTO at Afilias.  Of course they look after the back end
of dot org, which was signed in the summer, so it's a pleasure to
have you on the panel, Ram, and over to you.

 >>RAM MOHAN:  Thank you, thank you.  

 The first thing I wanted to say is, you know, when we started our
DNSSEC deployment, we began from Afilias our DNSSEC deployment with
dot org and with PIR, and together we chose an explicitly
conservative and structured deployment.  This included detailed
threat and risk analysis work which has served us very well to date,
and while it's true that you don't know what you don't know, we've
been fortunate that we haven't really experienced many issues so far
with the deployment.  

 And, you know, we attribute that to the careful approach that PIR
advocated and has actually taken, so -- and we're continuing that
approach.  We've learned from that ourselves and we've adopted that
approach and continued that approach with all the other TLDs that
we've deployed.

 On the next slide, what I wanted to focus my five minutes of
conversation on was what actually happens to you as an operator once
you've deployed DNSSEC.

 A lot of the discussions are about what it takes to deploy DNSSEC. 
Well, we've been -- you know, we've done it now -- it's two-plus
years now, and if you're a DNS admin, in the pre-DNSSEC days there
are only a few things that you do on a somewhat regular basis.

 You do the initial setup.  That just occurs once.  And after that,
in terms of operations, you know, you add to the config file when a
new zone comes on line, and then you make the normal changes to
resource records, as you expect, as you normally run it.

 And in terms of monitoring of the DNS nodes and the DNS system that
you're running, you know, the fundamental monitoring focuses on
checking that the updates have been made and has actually propagated
out to all the secondaries that you're running, that DNS and NTP is
running, and that actual zone transfers are working.  

 So it's a fairly well-defined, structured, and standardized
methodology.  

 One of the things that we've learned is that the load, not on the
technical side but the overall load of an admin post-DNSSEC is
actually quite different.  

 So just to enumerate, on the setup itself, even though it's still a
one-time setup, the number of things that you do are a little bit
expanded.  

 And others have already talked about it.

 On the operation, again, it's infrequent the generation of new keys
and new DS records if you're rolling the key signing key and passing
that on to the registrar, but then there are other tasks.  

 For example, once you -- if you actually set up a new key and you
begin signing with the new keys, then you have to get some sort of a
trigger and deprecate the old keys appropriately and do so in a
fashion that is stable.  And that requires care and that is a
combination of actual technical work, but more importantly, it
requires your DNS admins -- it -- you're starting a little bit of an
extra specialization where it's not just applying any sysadmin to the
role.  It needs somebody who is actually a DNS and DNSSEC-aware
person.  

 And so there's extra work there that -- you know, earlier on when
we were deploying initially, we said, "Oh, it's DNSSEC, you know. 
Just read the RFCs and, you know, start deploying it, run it in your
labs, test it, and then -- and then just go make it happen," right?

 And in full-scale production, the amount of training that you have
to do and the testing, the load is certainly higher.

 On the next slide, there are a couple other operations that are
actually more frequent.  The resigning of the zone and the signing of
new records, delegation records, as they come into the zone, that's a
frequent thing that has to happen.

 In terms of instrumentation, we've actually had to go and make
several increases in the total instrumentation.

 From the -- if you look at two slides ago -- 

 Julie, if you could just go back two slides.  

 One more, please.  Oh, sorry.  Go back.  Yeah.

 On the monitoring, you see there are three things that are -- that
would be monitored in a non-DNSSEC system.  

 If you go two slides forward, Julie, you notice that there are
actually a larger number of things that can go wrong, and therefore a
larger number of things that you have to monitor.

 Now, here's the thing:  This is standard.  What's different, what
we found different, is that the types of escalation and the types of
resolution of the problems is different.

 Again, problem resolution in a normal DNS failure mode or -- or a
zone transfer failing, et cetera, the resolution is fairly
straightforward, well-documented, and you can actually get people off
the street, literally, to go make that happen.

 When you have problems with DNSSEC issues, we end up -- we've
actually had to end up, you know, pulling people at different times
of day or night, and you're far more resource constrained at this
point than we used to be.

 So for those who are deploying DNSSEC, it's an interesting -- and
for the technical people who are doing it, it's actually a fun thing.
It's a cool new challenge for them, and a lot of sysadmins come in
and say, you know, "Put me on the project."  But one of the things to
evaluate is (a) whether they have a deep understanding of the DNS and
(b) to actually test them on DNSSEC knowledge and the ability to
recover from it.  Thank you.

 >>SIMON McCALLA:  Ram, thank you for that.  That was fantastic. 
Okay.  I'm going to move swiftly on now Rickard Bellgrim who is from
IIF, which runs dot se.  Rickard, over to you.

 >>RICKARD BELLGRIM:  Hello?  Yeah.  It works.  

 So my name is Rickard Bellgrim, working for .se, and I'm
responsible for OpenDNSSEC and also worked with upgrading our signing
system from the old solution to a newer solution.  So we can take the
next slide.  

 And this is the high-level view of our registry system, and as you
can see, we are a registry/registrar model that we use, and
everything starts -- essentially all the changes that we want to do
is initiated with the registrar -- or the registrants sending in
changes through the EPP system.  And if you want to have DNSSEC, you
have to add DNSSEC extensions to the EPP, you know, so that we can
send in the DS records.  Everything then goes into our registry
systems, we generate the zone file, and then we have a separate
machine for the zone signing, and we use OpenDNSSEC for that.  

 We have HSMs for doing the signing, and then it's distributed out
on the Internet.

 We also have the WHOIS server as well, and it presents if a zone is
signed as well, so that's a change that we have to do when we
introduce DNSSEC.

 Yeah.  And the -- so we operate with a production system and then
we have a warm standby, which means that it takes some hours just to
go over to the standby site, and I think for the future we'd like to
be able to upgrade the systems to be a hot standby so that we can
easily switch between the production sites.  

 But that also means that we have to make some more changes to the
system.  For instance, when you do DNSSEC, you want to be able to be
sure that you produce the same information on the two servers or two
sites, because otherwise you will have large changes go out on the
Internet because they aren't in sync regarding the signatures.

 Next slide.  

 So we've been doing this for many years and I think we started to
do the commitment on DNSSEC in 1999, and we had the first signing on
the parallel system in 2003 and actually went into production in
2005.  

 But it wasn't done till 2006 when we had friendly users who could
publish DS records up to us and we can verify that everything worked
as planned.

 And then in 2007, we had the commercial launch, but we had manual
interfaces, meaning that if someone wanted to upload DS records to
us, we had to do manual editing or manual administration for this.

 But since the volume increased, we had to automate this, and so we
introduced a new Web interface where the registrant could register
its own DS records.

 But this had to change when we introduced the new business model in
2009 when we went into a registry/registrar model, and this means
that all the changes have to go through the registrar, and then they
can't use the Web interface anymore.

 But we moved this Web interface over to our own legacy registrar,
so that we still have that available for those customers in that
legacy registrar.

 And then in April 2010, we upgraded the signing system because we
had -- before, we used a signing system that used smartcards for the
KSKs and then the key zone disk for the status case.

 We wanted to be able to secure -- store the keys securely by using
HSMs.  We wanted to have more policy handling, et cetera.  So that's
why we did the upgrade in 2010. 

 So the next slide.

 Well, it's tricky to be the first one because we bumped into
different problems with the DNSSEC, but those problems were soon
solved and then everything went well, actually, after that.

 And as we mentioned before, you should try to work with everyone
and get everyone all on board.  You have to get the ISPs up and
running, registrars, registrants, name server operators.

 We have actually succeeded with the ISPs because all the major ISPs
in Sweden are now validating DNSSEC.  However, the registrars are a
little bit slow, but they're moving on, and I think we have 15
registrars that do DNSSEC.

 You should also try to raise awareness and knowledge about DNSSEC
in your local community because you want to spread knowledge and make
people interested in the subject.  

 You would also like to teach them how to do DNSSEC just so that
they can do it on their own and maybe you can educate other people as
well to also spread the knowledge, because you cannot do everything
by yourself.

 And finally, you should also plan for unforeseen events because
stuff can happen, as we heard.  HSMs crash, et cetera.  And you have
to have procedures on how to handle these different cases and make
sure that you follow strict procedures so that you can recover from
any possible events.  

 Next slide.

 In the beginning, we had DNSSEC as a premium service so that you
had to pay extra for it, but then we lowered the fee gradually and
now it's completely free and we consider that DNSSEC should be part
of your infrastructure.  Meaning that you should do -- include
everyone to have DNSSEC.  

 So for instance if you're a registrar, just put everyone in and
sign all your customers at once, and the end users, they don't see
DNSSEC.  They hardly know about DNS, so this should just be a part of
the DNS infrastructure.

 We've also seen that the DNS is hard to use so we want to make
DNSSEC easy to use and that's why we've been committing to doing some
work for OpenDNSSEC and maybe TLDs are using it now currently and
more are coming.  

 And you should also make sure that you handle your keys with care,
because those are the things that actually prove that you are the one
that you are, and you should store them safely.  You could just store
them directly on this, but then you have to really fortify your
system.  If you want to be extra sure, you could use an HSM for it,
but you should make sure that you choose them carefully because we
had some issues with our sound card.  

 So we will soon publish a review where we compare four different
HSMs.  I think it's Encipher, Talis, Utimaco, and AAP, and where we
compare it on different levels and different features, and so I think
we'll be published here in December, so real soon.

 And as I said before, you should activate your local Internet
community so that you can have more people working on this subject
and so that you're not alone.

 And even if you're not planning to do DNSSEC right now, start doing
a test bed, because that can really help you increase your knowledge
within your own organization.  

 So that's my final part for this presentation.  Thank you.

 >>SIMON McCALLA:  Okay.  Thank you.  

 Finally, I'm just going to hand over to João Damas now from ISC for
the last presentation.

 >>JOÃO DAMAS:  I'm João Damas, working with ISC.  

 The zone I picked to talk about here is a little bit of a clear
zone.  It's called DLV.  It's an infrastructure zone, even though
it's a DNS zone, but it was first put out by the DNS-based deployment
aid for early DNSSEC deployment.  It allows you to register DNSSEC
keys in the zone regardless of whether your registrar -- or the TLD
where you are actually supports DNSSEC.  

 This is useful for early adopters.  It's useful also for people who
are testing ahead of going live, to debug your systems, learn how to
things work and iron out all the wrinkles before you expose yourself
to the outside world.

 The reason I also picked this zone is because it shows that DNSSEC
in itself is not necessarily only an end, but a means, in the sense
that this zone, if you look at it, is a bit odd.  It doesn't have any
delegations.  It doesn't have any addresses for any Web sites.  It
doesn't have any mail exchange servers.  All it has is keying
material.  

 Which shows, basically, that it's possible to carry nontraditional
information in DNS that can then be leveraged to use it and that can
be trusted just because it's signed with DNSSEC.

 As a point to illustrate this, there's work now being started to
formalize the storage of X509 certificates inside the DNS which you
can begin trusting because the zone you're fetching information from
would be signed, would be signed in a verifiable way, and provides a
different way of operating the same DNSSEC as an enabler of
technology rather than the technology by itself.

 Can I get the next slide, please?

 So in deploying this thing, what were the challenges?  

 The actual operational aspects were not that much of a challenge. 
After all, we use -- we were using BIND for this.  We are using BIND
for this.  And we write BIND, so when things don't work, we just talk
to the engineer who is breaking code and get things fixed quickly. 
So that the feedback loop in that area is very fast, very short.

 The biggest challenge for us was actually to secure the registry.

 Even though when you sign information people can verify that what
you put in there is what they are getting, that doesn't mean that
what is in the zone is actually worth the bits that it's using to
traverse the net.  

 If you actually want the additional trust that the DNSSEC can
provide you, you need to be able to provide people with the trust
that the information that's going in is good information.

 Because we didn't have a direct relationship with many of the
people that wanted to use the zone -- we are not the registry like
the other people in this panel -- we actually had to go through a
somewhat contorted way of verifying the claims to the keys that were
being put and the zones that they were being used for, which
basically involves a three-way handshake where you have to show that
you have -- are able to put in your zone something that we provide
you only upon request.

 So that's a little bit tricky.

 Also, there is the fact that just by saying that something is a
given way doesn't make it that way.  You cannot just go about telling
people, when you put the signed zone up, that, "It's all okay, just
trust us, we know what we're doing."  You actually have to go out and
publish how you're doing what you are doing, and so on, in a way that
people can verify, then, and -- and actually build their own trust on
what's being done.

 So with regards to the zone itself, the technical aspects of the
deployment, well, obviously the zone itself is signed.  Otherwise
there wouldn't be much point.  There would be no trust to be able to
take place in the contents of the zone.  

 We chose, after looking at the risks, the costs and benefits for
the information stored there, to just go with an off-line encrypted
media to store the key.  We didn't use HSMs.  We didn't think the
additional sense of security was actually incrementing the security
enough to be worth the cost.  You just have to be careful, but not go
overboard.

 And then the provisioning, basically we used standard DNS services,
our own and other people's.  

 Afilias, for instance, is providing name server service for the zone.

 So basically the DNS part is standard.  The key difference is that
how you build trust, how you make people trust what's in there, and
also that DNSSEC itself enables new uses of the DNS that we weren't
seeing so far.  

 And that's all I had to say.

 >>SIMON McCALLA:  Great.  Thank you very much, João.  Okay.  We're
running a little bit -- about 10 minutes behind and I'm keeping
people from lunch which is never an enviable position to be.  

 Okay.  But I think in a bit I would like to open the floor to
questions to the panel here.  We've got some great folk on this panel
with some great experience, so firstly, does anybody have questions
from the floor right now?  

 We have one from the chatroom.  Great.

 We have one from the chatroom.  Thanks, Markus.

 >> I have one from the chatroom from Antoine for VeriSign.  Since
you keep your KSK offline, how often are you rolling your ZSKs and
how are you doing that?

 >> They are being rolled quarterly.  

 >> Then you bring your KSK online?

 >> Well, no, there's an air gap.  The KSK stays in the key ceremony
room and never leaves.  So the ZSK has to be brought in and signed
and taken out.

 >> ROD RASMUSSEN:  Rod Rasmussen.  I wanted to explore a little bit
on what Ram had talked about there in kind of the discovery of the
level of qualification of a person that would take to actually be
able to run DNSSEC and give a little bit more thought on that as to
what type of engineer person would need to be able to do that.  

 This is tying back again to kind of the cost-benefit analysis of a
business taking a look at deploying DNSSEC, especially in conjunction
with what we looked at some of the risk benefits we talked about this
morning.  

 One thing is what kind of person does it take?  What kind of
infrastructure does it take to be able to run it for yourself And
then perhaps how that -- where you might want to draw the line
between running it yourself and outsourcing to somebody else who has
got the technical expertise to do that.

 >>RAM MOHAN:  Thank you.  At this stage, I think for an enterprise,
if they really want to run DNSSEC themselves, then they need that
kind of specialized help.  And I suspect that in many cases, it's --
that is a larger deterrent to them doing it rather than, you know, a
CFO, a CEO, a CTO saying, We shouldn't be doing it.  And that
automatically prompts the idea of having that piece of infrastructure
outsourced to somebody who can actually do it.

 To your earlier question about what kind of engineer, I don't think
there is really a good formula for that.  It is a good sys admin.  

 My point really was that just as, you know, a decade or so ago
enterprises had, you know -- needed to specialize from hiring just a
sys admin to hiring somebody who was a router technician, if you
will, or a router admin, right, because the skill set required for
that is different from, you know, just doing a normal sys admin role.  

 I was really pointing out an expansion in the spectrum where there
is a different area of deep specialization that is coming about,
which has to do with DNS and DNSSEC as a separate piece.  

 And I wouldn't be surprised if down the road you find organizations
that go where you can actually get DNSSEC certified as an admin.

 >>SIMON McCALLA:  Thanks, Ram.

 >>ROY ARENDS:  Roy Arends, Nominet.  I have a question for the
panel and especially for the folks who are on the registry.  Policies
for a registrar transfer, when you go as a name holder from a
registrar that is DNSSEC-enabled to a registrar that is not DNSSEC-
enabled, what is the policy at your registry?  Do you automatically
remove the DS?  Do you do nothing?  Do you inform the registrar?  Do
you inform the registrant?  I'm curious about the current existing
policies in your various registries.  Thank you.

 >> MATT LARSON:  Okay.  I'll take that.  For the dot com and dot
net registry, we're not tracking whether registrars are DNSSEC-
enabled or not.  And a transfer happens as usual, and there really is
no additional effect of DNSSEC.  The DS records go along with the
domain -- or I should say, the DS records remain unchanged just as
the NS records remain unchanged during a transfer.  

 So it would be possible to strand your domain at a registrar that's
not DNSSEC capable and you would have to call their customer service
number or have us intervene.  

 We just didn't want to get in the business of certifying and
qualifying registrars for DNSSEC support.  It is just one more
hurdle.  It is already hard enough.

 >>ONDREJ FILIP:  If I can take the question, we also do not
distinguish between registrars who support DNSSEC or don't.  So
that's why we had a broader discussion with them and we decided that
if a domain is transferred, the DS record or key set, in our case, is
removed automatically unless the registrar who's transferred domain
status that he wants to keep the DS records there.  So by default,
the key set or DS record is removed from the domain when the domain
is transferred.

 >>ROY ARENDS:  Okay, thank you.

 >>RAM MOHAN:  From Afilias, this is one of the more vexing problems
that we are dealing with.  We don't want to strand the registrant. 
And at the same time, the losing registrar really has no obligation
to carry and to continue to propagate.  We don't really have a full
solution, so the default is what has been discussed already.

 But I don't think that's the right place, where it should end.  I
think we do need to have some more interaction and find a way to
ensure that the transfer is ripple-free.  It definitely causes
ripple.  It would cause ripple right now.  And that's not good enough.

 >> RICKARD BELLGRIM:  And the portal testing at all the registrars
should be able to remove the DS record at least.  So if we do a
transfer from one registrar to another registrar that cannot handle
DNSSEC, then at least he can fix the problem by removing the DS record.

 >>ROY ARENDS:  Just a question on scale.  Could you tell me how
many unique registrars you have?

 >> RICKARD BELLGRIM:  I think it is around 150 registrars.

 >>ROY ARENDS:  Thank you.

 >>SIMON McCALLA:  Thanks, Roy.

 >>RUSS MUNDY:  Russ Mundy.  One thing we have heard a great deal
about today is the cryptographic mechanisms and especially hardware
security modules.  I'm curious as to, especially from a risk
assessment and security measurement point of view, if there was any
attempt to give roughly equal protection to the content which is
really the whole fundamental purpose of DNSSEC to make sure that the
handling of the content of the zone is at least as good as the
security that's provided for the keys that are being used to protect
the zone.  Or was that something that just really wasn't thought
about very much?

 >>RICKARD BELLGRIM:  Yeah, you should actually protect the entire
chain that you have because you can really protect your keys, but
then it can do garbage in.  They can hack into their registry
database and change the information from there and then it gets
signed.  So you should really think about what are your weakest links
in your system.  So that's -- maybe you fortify your system in other
ways that makes you not use HSMs.  You fortify your systems, and you
still can protect your keys without using HSMs.  It is not required
to use HSMs to protect your system.  It is that you have to find the
weakest links in your system.

 >>RUSS MUNDY:  That is exactly my point.  And some of the folks
have heard somewhat of a Russ Mundy soapbox, and that is that you
should give exactly equal security protection to the content and the
entire correctness of the content that you do to the keys.  And I was
very curious if folks had considered that as they went through the
process because it's okay to make a considered decision that we're
going to give our keys more protection.  But, hopefully, it was done
consciously as opposed to accidentally.

 >>JOÃO DAMAS:  To add to that, I mentioned that in my slides.  We
looked at exactly that.  Why would you be protecting this particular
part of the infrastructure better than the rest if the other -- I
mean, the problem you have sometimes with security is that you don't
only need to provide security, you also need to provide the sense of
security. This is what HSMs actually do more than actually anything
else.

 >>RUSS MUNDY:  Thank you.

 >> RICKARD BELLGRIM:  You should also remember that the keys are
actually your identity and you probably want to protect your
identity.  And if the keys are stolen, then they can do whatever they
want.  But if they hack into your registry system, at least you know
that you have been hacked.  But if the keys are stolen, then you
don't know what to do with the keys with your new identity.

 >>SIMON McCALLA:  I can hear some stomachs rumbling on the panel up
here so that's a good signal it's time to round up.

 >> Do we have time for one more question?

 >>SIMON McCALLA:  If it is short, that would be great.  Thanks.

 >> It is short but I'm not sure if the answer is short.  Hi. 
(saying name), head of dot (inaudible) registry.  Matt told us that
the reason to launch service for registrars signing the -- their
zones.  And I also see in that dot EU is planning similar service.  

 So my question is to the panel, do you think this is a good idea
that the registry are signing the registrar's customer zones?  Or --
because I have some doubt about it regarding the model and who should
do what.  So what is your opinion?

 >>ONDREJ FILIP:  If I might speak on behalf of dot CZ, we don't
think we should interfere with the registrars.  We try to keep the
business on the registrars and we do not want to touch registrants
basically.  So I wouldn't support that activity.

 >>MATT LARSON:  I guess I don't see any inherent conflict.  Signing
a zone is really more like hosting a zone, and VeriSign is in the
manage DNS business.  We would be happy to host anybody's zones. 
This is just another service that makes it easier for the registrars,
and it just happens to include a signing component.  So I see this
more like a managed DNS service than having anything to do with the
role of the registry and registering the domain names.  

 And, of course, it is completely optional.  A registrar could build
their own service, if they'd like.

 >>RAM MOHAN:  We take a similar approach.  It is just a managed DNS
service.

 >>SIMON McCALLA:  I think from my point of view anything that helps
with DNSSEC adoption, perhaps we don't want to take the time and
investment to do it themselves, it is a great development.  I think
we would welcome it.

 >> ONDREJ FILIP:  Maybe my position comes from a little bit
different environment because the distraction in my country is
developing enough that there is enough services on the market that
offer those end users the managed services with DNSSEC.  That's why
we don't think we need to interfere.

 >>SIMON McCALLA:  Does that answer your question?  We are going to
wrap up.  Thank you very much to your panel.  I think we have
listened to some really interesting stuff today.  What surprised me
from what we have seen is the diversity of not just of the technical
landscape but some people focus very much on software and having a
flexible provision, some very much on process.  

 I thought Ram's point was really interesting, very close to my
heart, about making sure people are really well-trained.  I think
there is a definite scope for, as a community, developing a set of
training tools to help train our end users to make sure they make the
right decisions is an excellent idea.  Thank you for that.  

 Thank you to our panel talking about the DLV and also talking about
how we involve the community records.  Thank you very much for that. 
I really enjoyed all of your presentations and responses.  And with
that, we will close the panel and head to launch.

 [ Applause ]

 >>STEVE CROCKER:  Thank you, everybody.  We have lunch available. 
It's available up on the far side over here on my right, your left. 
Just go up the stairs and it is outside, if everybody has a ticket. 
I don't know how strongly they are enforcing this.  But you should
have this nice ticket that has everybody's logo on it.  No?  What do
we do if people don't have -- we're over-provisioned.  I can't see
that there will be a problem here.  So please head out.  And please
rejoin here at 10 minutes -- please return by 10 of, no later.

 [ Break ]

 >>STEVE CROCKER:  All right.  I declare us back in session.  We
have Jason Livingood from Comcast coming remotely.  Jason, you're
live, I believe?  But soft, speak up just a tad.  Much better.  We
have your slides up.  Without further ado, Jason, take it away.

 >>JASON LIVINGOOD:  Thank you.  I'm Jason Livingood from Comcast. 
We are a large ISP in the United States.  

 Steve, I will say "next slide" when we are ready to go.  Go to
slide 2, please.

 I do know there is a time constraint, so I will try to go very
quickly through these slides.  We might skip some of these just to
save time.  I was asked to speak about the role of ISPs and DNSSEC
deployment and sort of what the state of that is, especially in North
America and as it relates to what we're doing on our network.

 For everyone's edification, I think everyone knows this, but ISPs
act in two different roles in DNSSEC, both on a signing basis because
we have lots of domains that we are authoritative for and
particularly the domains that our customers are registered for their
reverse records and so on.  More importantly, though, validating
recursive resolvers that are operating in the network.  ISPs
generally tend to operate the majority of resolvers that end users
query.  Certainly, there are third-party services, whether it is Open
DNS IDNS, Google DNS, so on, that people switch to.  But by and
large, people get these via their (inaudible) other updates and use
their ISPs.  ISPs are really critical here in terms of DNSSEC
adoption because to really foster that adoption from a recursive,
validation standpoint, ISPs have to deploy validation in their
resolvers.

 So going on to slide 3, the next slide.  We began moving our
production customers to our DNSSEC validating resolvers in mid
October.  Previously we still offer this, we have had a next-to-name
redirect service for (poor audio).  Essentially, the first customers
that we moved to our DNSSEC servers were the ones that had opted out
of that service.  And that's proceeding well.  

 I think as of now, we have about 2% of our total queries that we
receive are hitting the validating resolvers.  So about 2% of our
total query volume of about 48 billion queries a day is hitting
DNSSEC validating resolvers.

 The rest of our customers we're targeting to migrate in roughly the
first quarter of next year.  Now, that's, of course, subject to
change based upon what happens with other TLD signings and general
things that we continue to find.  But I would say safe to assume that
at least in our network, which is a fairly large one in North
America, all of our customers would be migrated in the first half of
next year to validating resolvers.

 On the authoritative side, which I mentioned, a somewhat smaller
aspect.  We have signed all of our dot org domains and will sign all
of our dot net and com domains soon after those TLDs sign.  Typically
we try to sign a few the day they go live and try to sign the balance
within 90 days.  And certainly hope -- what we are trying to do there
is lead by example and encourage other domains to sign as well.

 On the next slide, please.  One of the things we did, we talked to
other ISPs and others in the community to share some of our lessons
learned here.  One of the things that we did when we rolled out was
to reach out to early adopters in the tech community, whether it be
via Web site, e-mail, blogs, Twitter, whatever, and explain exactly
what we were doing, why and so on to sort of get them to sort of
ambassadors for what we were doing and understand and see the value
of DNSSEC.

 In addition, we try to put in really simple terms what DNSSEC is. 
When we talked to customers, one of the things we found is their eyes
kind of glazed over when we gave the typical engineering explanation
of what DNSSEC was.  So we found we really, really had to simplify
our message of what DNSSEC was and why it was helpful to them.

 And then, lastly, we tried to be very clear to everybody about our
plans so there was no confusion, that we had announced what we were
doing wrong.  And we were there during rollout when we were first
starting to put a lot of queries in the platform, to respond to
questions in realtime and interact with customers directly and brief
other folks that might have had any issues.

 Next slide, please.

 So one of the things we did, we would encourage other folks,
particularly ISPs that roll out to be very public about this so
people know it is happening and they know if they see something on
that day instead of saying, "Oh, maybe it will go away in a few
hours," that maybe they will correlate that to some big change and be
vocal about it, call into (poor audio) or contact them via e-mail,
what have you.

 We announced this in our company blog.  We also produced a two-
minute video basically styled as a public service announcement and
very, very simply explained what DNSSEC does and why it's important. 
And we used a TV personality from one of the television networks we
manage to do that.

 As of a few weeks ago, it had over 5,000 views.  We expect as we
roll this out to more customers we will see a lot more than that.

 Next slide.  So slide 6 is some of the other rollout tactics.  We e-
mailed all of the effective customers in advance to let them know
they were moving to DNSSEC to validated resolvers.  We explained very
simply what DNSSEC was, and we linked them to new FAQs about it and
helped them understand how troubleshooting might be a little bit
different.

 Next slide, slide 7.  We also have a wider security program with a
company, as many ISPs do, and we made DNSSEC part of that.  So that's
something that's in front of customers regularly.  And rather than
being sort of a bullet server in and of itself, we have tried to
explain it to customers as one of many parts or facets of a security
protection of an ISP network.

 Next slide, slide 8.  Some of the other things I mentioned in terms
of realtime, we had outreach to customers.  We went on to Twitter,
different Web sites that we know people are on and discussion forums
and so on to make sure people knew on the day or the day before this
sort of rollout what was happening, why.  And we said, you know,
we'll be here standing by if you notice anything wrong.  

 And I would say this is something I would recommend anybody do,
whether you are signing your zones for the first time or whether you
are validating and beginning to validate for the first time.  Very
valuable.  It is a way to sort of have a canary in the combine and
watch for any early reports if anything is a little bit off.  Again,
it is a switching change in the back end.

 Next slide, 9.  This is just a graph showing how the queries are
increasing or decreasing so along the top of the red line, you see
the queries to non-validating resolvers declining.  And at the
bottom, you are seeing the queries to validating resolvers
increasing.  And as of now, it looks like we're a little bit above
where I mentioned earlier.  We are about 5%.  I think I might have
said 2% before.  So 5% is where we are as of about a week and half or
two weeks ago.

 Next slide is slide 10.  As we talk to customers.  We had a lot of
questions from them.  How do will we know that DNSSEC is on on my
resolver?  How do I know -- even if I have changed these resolvers,
how can I have proof that validation actually works or doesn't work? 
We created a Web site.  I believe some others in the community have
done similarly.  Ours was dnssec-fail.org.  

 We explained if you can get to that site and you see the content
here at the bottom, you are not using DNSSEC validation and contact
us and we will help you figure that out.  If you can't see it, you
are going to get a (inaudible).  You will not see that site.  You
will get an error page and that means you are, in fact, protected.

 And then on the next slide, slide 11, we recommended to folks some
of the browser plug-in tools.  And we have seen some people adopt
that.  We also contributed, and recommend others consider doing so as
well, to the great program that the NL Net Foundation and the DNSSEC
Support Fund so developers can apply to get grants to add DNSSEC
validation or validation indicators in their applications.  We think
that's an important part to get people to focus on.

 Next slide, slide 12, the upcoming plans for us as we indicated
planning the big phase of our rollout in the first quarter sometime,
so that other 95% of our query volume moving to validation then.

 We had found in the last few weeks that we have a need to add a lot
more FAQs, particularly concerning validation failures.  We have
gotten a few suggestions from (poor audio) in terms of what to put
there.

 One thing that I think is important to know here -- and we have
certainly noticed with some key expirations where validations is
always occurring is we'll sometimes see a customer for that -- they
can't get to a domain.  We are using (poor audio) resolvers.  And
sometimes unfortunately what has been happening is the people that
maybe own those domains, manage those domains recommend that those
people move to DNS servers that don't do DNSSEC validation instead of
sort of saying, Okay, we are having a problem in the way we are doing
DNSSEC on our authoritative servers, let's go fix that very quickly
just as if you have a problem with a MX record or any record, you
want to go fix that rather than asking someone to type in an IP
address. 

 We are trying to explain to people -- and we will be developing
FAQs in this area -- if you have a validation problem, here are a
couple of tools you can use to go and visually see if this is, in
fact, a validation problem or not.  And we may be able to round tool.
But if the authoritative domain has for some reason let something
expire or made some other mistake or error with DNSSEC, the answer
isn't to move to a resolver where DNSSEC validation is not being
done.  The answer is to really get that domain to fix the problem
that's there.  

 And so that's really an important thing to make sure the community
understands.  That's sort of the approach we are taking because,
otherwise, all you do is kick the can further down the road, so to
speak, on DNSSEC and you really need get people to move over because
every once in a while, there is a problem in the domain.  Rather than
ever see that problem, we'll just never validate by using these other
legacy servers.

 Really, the answer is to force people to really apply the same
level of rigor in their DNSSEC readiness on an authoritative basis as
they would in making sure their TTLs are set right, their MX records
are correct and their A records and so on.  I think that's kind of
important to understand.

 The other thing that we're doing, which is significant for a
company of our size, we have tens of thousands of customer support
representatives that talk to our customers every single day.  And
every one of those needs to be trained on what DNSSEC is.  

 So we're in the midst of doing a 10-minute training module.  So we
will have about 20- to 25,000 people over the next 90 days that get
DNSSEC training.  And that's very critical to enabling those first-
line employees who talk to customers all the time, helping them both
understand and explain what DNSSEC is to customers in very simple
terms as well as understand how to help troubleshoot whenever they
see those kinds of issues.  That's important.  I would say given what
we see, whether you are rolling this out on an authoritative basis or
you are an ISP and you have got a lot of resolvers, don't
underestimate the amount of training that has to go on for the people
that interact with end users.  It is significant and does take a lot
of preparation and the materials should be very, very simple and not
sort of aimed at your typical sys admin or systems engineer.

 Slide 13, I think we can skip past this.  This is sort of a
timeline.  The message here is simply, we have been doing the sys
trials in 2008.  DNSSEC deployment is not going to happen overnight
for people.  I think everyone in the room should understand that. 
Anybody company who is going to implement it, it is a significant
investment of time and make sure you are getting ready.  

 And I think we can probably skip slide 14.  

 Suffice it to say one of the reasons that we did start the work
long ago is that you should anticipate, we recommend others
anticipate as well, that they're going to have some kind of problem. 
So sort of bake that into your plans.  Expect you are going to have
problems.  Make sure that you have got enough time to react, work
with your vendors and so on to fix them.

 And then last slide here is slide 15, lessons learned.  ISPs have a
lot of operational processes related to DNS and all of those need to
be looked at and adjusted when deploying DNSSEC validation. 
Certainly, I think everyone in the room is aware of all the
authoritative structure changes that need to be done but there are a
lot of things as well on the recursive side that likely need to be
updated including the (poor audio) firewalls, upstream routers, and
other things to make sure that things are going to work successfully.  

 And, of course, you know, even things that might seem minor, like
NTP, need to be really looked at as things time out and so on to make
sure you have very accurate time sources.

 And as I indicated in previous slides, don't underestimate the
training time or educational materials that have to be developed
either for your customers or for your employees and make sure that
you got sufficient operational processes in place to monitor for
failures.  I think that's going to be one where the entire community,
not just ISPs or domain owners are going to have a bit of a learning
curve over the next year or two.  I would highlight that as an area
to pay attention to.

 Make sure customers are briefed before you go live and understand
the changes.  Lastly, as I really indicated before, there are
definitely going to be validation failures.  We have seen those as
recently as last week with some major country level top-level
domains.  And be prepared for those.  I don't think the answer is to
turn off validation when those things occur or to tell customers or
people to move to non-validating resolvers.  

 The answer is really to solve those problems and make sure people
put better signing and validation policies and procedures in place.

 So I'm happy to take any questions.  That's the long and short of
it and went as fast as I could have.

 >>STEVE CROCKER:  Any questions?  Ah.  Always count on you, Roy.

 >>ROY ARENDS:  Hi, Jason.  This is Roy Arends from Nominet.

 >>JASON LIVINGOOD:  Hey, Roy.

 >>ROY ARENDS: Hi.  How are you doing?  

 I understand that Comcast also has an additional service, and the
service includes something like altering nxdomain responses to help
end users get to where they want to go.  This is basically altering
DNS and it doesn't really mix with DNSSEC that tries to provide
authenticity of those domains.  How do these two services mix at
Comcast?  

 Thank you.

 >>JASON LIVINGOOD:  They absolutely do not mix, from my standpoint,
and we have been very public, both in, you know, things that we put
on our site as well as some relevant IETF (poor audio) that I have.  

 I view them as, you know, fundamentally incompatible, and the
larger interest, from our standpoint, is the security of the DNS, and
we intend to turn off nxdomain at the time that we move customers to
these resolvers.

 >>ROY ARENDS:  That's fantastic, Jason.  Thank you.

 >>STEVE CROCKER:  Any questions in the chatroom or somebody
watching this?

 Okay.  Well, thank you.  Thank you.

 >>JASON LIVINGOOD:  Sure thing.

 >>STEVE CROCKER:  Very, very nice, and I think you're pushing on
exactly the right frontier here and it's going to make a big
difference.

 So thank you for coming in at a distance here.  We'll move on to
the --

 >>JASON LIVINGOOD:  Sure.

 >>STEVE CROCKER:  -- last and definitely not least, but one of the
features that I've been looking forward to, which is the focus on the
region here and all of the activity.

 So first up -- 

 Let's see.  Federico are you running this or --

 >>FEDERICO NEVES:  No.  You are.

 >>STEVE CROCKER:  I am.  All right.  We had started with the idea
of a panel and it -- okay.

 So first talk is Nicolai -- let's see if I can get this right --
Bezsonoff?

 >>NICOLAI BEZSONOFF:  Perfect.

 >>STEVE CROCKER:  Thank you.  And you're CTO?

 >>NICOLAI BEZSONOFF:  COO.

 >>STEVE CROCKER:  COO.  Excuse me.  COO of CO.

 >>NICOLAI BEZSONOFF:  Exactly.  Riddle me that.

 >>STEVE CROCKER:  Yeah.  Take it away.

 [ Laughter ]

 >>NICOLAI BEZSONOFF:  Okay.  Thank you, Steve.

 Well, first of all, I wanted to welcome -- I know we've been here
for a couple days already, but thank you very much for coming to
Cartagena.  I hope you're having a good, good time, productive time,
and I hope -- I'm very proud to be hosting all of you here.

 And I would also like to make sure that I remind you and invite you
again to the gala that we're having tonight right here, so it will be
a nice way to celebrate all of the achievements of this week and a
nice way for you to see a little bit about -- a little bit more about
my country, Colombia, and my city, Cartagena, where I was born,
actually.  

 So very proud to be here.

 So let me just get right to it.  We can go to the next slide.

 Real quick, the company I work for, dot COInternet, just took over
the administration of the dot CO domain earlier this year.  We work
in conjunction with the Ministry of Communications of Colombia to run
the administration and promotion and operation of the dot CO domain. 
We took over in February of 2010, and since then, we've -- through
that transition, we transitioned administration of the registry
itself, the DNS and all its related systems.  A hundred percent
uptime and availability since, so we're -- so far very pleased with
that.  We launched with about 10 registrars and we went through a
whole gradual offering plan that included everything from
grandfathering, sunrise, to general availability which occurred on
July 20th of this year.

 Since then, we have been fortunate enough to have had a very high
increase in the number of domains registered.  233,000 domains in the
first 24 hours, and are currently at 612,995, as I just checked on my
BlackBerry, so we are pretty pleased with that.

 So that's what we've done in terms of overall dot CO in general as
a way of introduction.

 Now, specifically on the topic of DNSSEC, we realized from day one
that we wanted to and would embrace and implement all of the latest
security enhancements that are coming into the industry, so we -- as
we started working with our technology partner, NeuStar, we decided
that we wanted to be in the forefront of DNSSEC implementation.

 So we've begun our DNSSEC implementation.  We -- and we expect to
have it live by the end of the first quarter of next year.

 We're in the middle of OT&E right now for registrars, and we'll be
signing the zone in the second week of February of next year, moving
quickly to going through the approval or the root update with IANA,
and then doing the burning for the zone in the -- towards the end of
February, and finally will go live with connection for registrars in
production by the third week of March.

 So apart from that, however -- that's just kind of the technical
implementation of it -- we are starting a whole process, not unlike
what Jason was just going over before from Comcast, but something
we're done in country to promote the implementation and the adoption
of DNSSEC.

 So we realize that it's not just us signing the zone and providing
the availability of DNSSEC; it's about involving all the different
stakeholders and involving all the different actors in the chain of
this.

 So working with all the local ISPs, and everything, from going to
universities and educating different developer -- groups, to
developer associations, to -- all the way down to the ISPs and
different companies involved.

 So as part of that, our commitment is to create a whole education
and to foster the adoption of DNSSEC in country as well.

 So next slide.

 And some of the specifics about our deployment, working closely
with -- it's the previously one.  Sorry.  

 That's it.

 >>JULIE HEDLUND:  Sorry.

 >>NICOLAI BEZSONOFF:  That's all right.  

 So in -- we're using the same -- basically the same characteristics
that our technology partner, NeuStar, has been applying, so we're
going to be using NSEC, SHA-256, and based on the experience that
we've worked with and the lessons learned from NeuStar, we're not
going to have any restrictions on transfers or required
certifications for registrars.  We only have 10 registrars right now
so we're going to work individually with them.  

 And a couple more things.  Initially we're planning not to indicate
if a domain has been signed in our WHOIS.  That's something we've
gone a little bit back and forth on that.  Initially we were not
going to do it.  

 And then we're going to be just doing regular updates of the
rolling over of the keys, as you can see here.

 So I'll -- with that, that's our -- those are our plans.  Again,
we're trying to stay very committed to DNSSEC implementation and will
take any suggestions that any of the community has for enhancing our
plans.  Thank you.

 >>STEVE CROCKER:  Thank you very much.  Any questions?  

 Old reliable here.

 >>ROY ARENDS:  I guess I just should stay at the mic then.  

 Hi, Nicolai.  I'm Roy Arends from Nominet.  I've got two questions
but I need to introduce the question a little bit.  

 Your top-level domain has something in common with our second-level
domain, co and co.uk, and this question is not actually related to
DNSSEC and I hope you're able to answer it, but I do appreciate
you're the COO and you don't get your hands on everyday technical
things.

 As you know, there are browsers out there that do auto-completion,
right?  The moment you type in a domain name, it already starts to
resolve.  It depends heavily on things like nonexistence or on the
administrative border of domain names.  However, if I would, for
instance, type in "nominet.co," I already get a response even though
I want to go to nominet.co.uk.  That's just an example.  

 I wonder if you see any of that back-scatter in your registry, if
there's anything on the -- on name servers coming in or anything on
the registration level that people are registering names that, for
instance, would match very heavily to domains in co.uk.  Thank you.

 >>NICOLAI BEZSONOFF:  Good questions.

 And, yes, we do see that.  Unfortunately, we do see that.  We're
trying to -- we try to deter, as much as we can, people from that,
having always adopting -- adopted a full set of trademark-friendly
policies and having gone through a whole -- very structured sunrise
process and so on and so forth to deter those practices, as well as
adopting the UDRP and so on and so forth, but it still happens.  

 So we do see that.  Unfortunately it's just a problem in the
industry and we're trying to -- as much as we can, trying to educate
all the companies out there.

 One of the things we did as part of our launch program is we
created what we called -- we worked in conjunction with Deloitte/Laga
through -- with Bart Lieben to come up with the hundred top kind of
brands that would be Internet brands and we used them for -- we gave
those away, those domains, protected those.  

 So, yeah, we -- but we are unfortunately seeing a little of that
and we're working towards trying to fix that.

 In terms of the completion, actual browser completion of URLs, I
mean we're -- as much as we can -- and obviously we don't have the
leverage or the necessary influence that we would like on this, but
we're trying to work with the different companies, the different --
involved to try to address that.

 Our ideal would be that there wasn't any completion, obviously, but
we're trying to work with it.

 >>STEVE CROCKER:  All right.  So --

 >>ROY ARENDS:  Thank you for your answer.

 >>STEVE CROCKER: -- if you guys want to follow up on that, I
understand the topic and it's very important but it is somewhat
specialized to the fact that it's dot CO in particular and it's not
DNSSEC, actually, so --

 >>ROY ARENDS: Yes.  But I just took the opportunity, since nobody
else was getting up to ask a question.

 >>STEVE CROCKER:  Now that you guys know each other, have coffee
together.

 >>NICOLAI BEZSONOFF:  Thank you.

 >>STEVE CROCKER:  Yes.  Anything else?  Anything in the chatroom,
Markus?  

 Okay.  Thank you very much, Nikolai.  Excellent.  Very, very nice.

 Okay.  We move on.

 Erick Iriarte Ahon representing LACTLD, an update with a survey
around the region.  I'm keenly interested in the data here.

 >>ERICK IRIARTE:  Thanks.  Thanks for the invitation.

 In honor to our host, I will speak in Spanish.  My presentation is
in English anyway, so you can put... 

 The first thing I want to say is LACTLD is one of the four
organizations existing at the global level, consolidating ccTLDs in
the region, in this case, for Latin America and the Caribbean.  

 We currently have 25 members, which are the ones that are -- they
are including dot CO, and eight affiliates.  The last of our
affiliates is dot com who is now -- has now incorporated this in the
last few years.

 As part of our work, one of the critical issues is that -- one of
the priorities for the years 2011 to 2015 includes a specific target
for DNSSEC.

 On the other hand, we have an explicit policy on our strategic plan
for the implementation -- regional implementation of DNSSEC.  That's
why we're working together with ISOC and ICANN to obtain resources to
tangibly develop the implementation of DNSSEC for the next few years.

 Last year, we had two workshops that are relevant.  The first one
is an AROC (phonetic) workshop developed with ICANN and NRSRC dealing
with the specific issues of ccTLDs in the region.

 However, it was the fourth workshop in September last year that was
specifically focused on the implementation of DNSSEC.  We also dealt
with the technical issues on IPP.  These training workshops was for
about 17  ccTLDs and it was held with about 50 participants.

 This year, we had a survey on the status of the DNSSEC
implementation in the region.

 Next slide, please.

 It is now fully rolled over, point cat, point br, dot cat, dot br,
dot co, point pt -- dot pt and dot us in the United States and dot hn
in Honduras.  

 The last version that you're going to see on the Web is on the
corrections, the corrections that are necessary in this presentation.  

 As future full deployments for the regions, we see Chile in the
second quarter of next year.  Dot com has the same date.  Dot ec for
Ecuador is planned -- is planning its deployment for January 2010. 
Guatemala is projecting this for January 2012, Mexico for the fourth
quarter next year, Panama for August next year, Peru for the last
quarter next year, and Uruguay for the first quarter in 2012.

 We are now starting preliminary activities, applying preliminary
observations, seeing how the implementation is going to be done.  

 There are internal implementations in Costa Rica.  In August 2010,
Costa Rica started its implementation.  Spain started in September
2010.  Guatemala is planning to start in January next year.  Mexico
has been doing exercises on this issue from since the year 2005. 
Peru started in September this year, and Trinidad and Tobago started
at the beginning of this year.

 They are starting to see how they're going to deal with the issue
of dot mobi and dot ve in Venezuela.

 They have not started yet and there is an indication of this in
this presentation.

 You see dot hn in this presentation, and because dot hn is
supported by Afilias, we see that there is a total deployment of
DNSSEC, but locally the same ccTLD is trying to conduct its own
deployment of DNSSEC.

 What we have not seen yet and we know we don't have the data here,
though they know about is, Anguilla, the Dutch Antilles, the
Dominican Republic, Paraguay, and El Salvador.

 A little bit more than 70 or 75% in the region is advanced on the
DNSSEC issues and next year is seen as the year where at least 50% of
the region will have reached this.  Will have reached this level.

 The next activities on the DNSSEC area will be a workshop on the
ACRP in Nicaragua in February dealing with DNSSEC.  In September, we
will see our fifth technical workshop, probably in Havana, including
DNSSEC issues again.

 We will implement a DNSSEC survey each three months to verify what
is the implementation as for the next years.  We hope to obtain 50%
of the region already deployed.

 We hope to have a manual operations field for the implementation of
DNSSEC in Spanish, Portuguese and French, which are the languages of
the reach, and together with ICANN and ISOC we are planning to have a
fund for implementation projects of DNSSEC.

 I would like to say that regional organizations -- APTLD, AfTLD and
LACTLD -- have just signed an agreement yesterday to exchange
information.  These memorandums of understanding is a development of
an agreement that has already been signed in September this year for
security issues where one of the critical issues is the DNSSEC issue.
Next slide, please.

 If you have any questions on what is going on in the regions, there
is my e-mail.  The activity the region is having is very proactive. 
We have the support of ICANN and ISOC, and definitely we do believe
that next year will be the year of DNSSEC in Latin America.  

 Thank you very much.

 >>STEVE CROCKER:  Bravo.  Questions?  Anything in the chatroom?  

 Erick, thank you very much, and I applaud the initiative and want
to keep track of this and keep in touch over time.

 Great.

 The next talk is Ram Mohan from Afilias on the developments that
they're supporting.

 >>RAM MOHAN:  Thank you.

 Afilias signed the following zones in the Caribbean and Latin
American regions in October 2010:  Ag, bz, hn, lc, and vc.  That's
five ccTLDs.  

 If you could bring up the slide.

 My comments are perhaps a little bit less about just the status of
where things are and a little bit more to a couple of substantive
things that we've seen that might be worth keeping in mind.

 The fundamental area that I wanted to talk about was the way the
current IANA process works and the interaction of DNSSEC.

 In this kind of rough schematic there, starting from the left over
to the right, Step 1, a change request is sent to IANA, and Step 2,
IANA sends a request for acknowledgement of that request over to the
administrative contact and the tech contact and then they send an
acknowledgement of the change and then IANA makes the requested
changes.

 If you move to the next slide, one of the things that we've found
in the five TLDs that we were trying to get to be signed in time were
a few challenges.  These are not necessarily DNSSEC-unique
challenges, but certainly something that we noticed as far as IANA is
concerned.

 Now, one of the things is that IANA will not approve changes which
may affect stability or servers for the TLD.  

 Now, that is a good policy.  That's a good thing.  But what -- the
indication for TLD operators and for name server -- or DNS operators
is that name servers in the TLD's apex NS set must be upgraded to
DNSSEC-ready versions.  Otherwise, you may want to have your zone
signed, but you will not go through -- you will not succeed in the
process, so that's just something for folks in the region to keep in
mind.

 The last point I wanted to make really is that, you know, a signed
TLD must publish its DS records in the root zone to make validation
possible, and that publication is facilitated by IANA via its
standard process for root zone delegation changes.

 If the name servers in the TLD's apex NS set are not DNSSEC-ready,
clearly that will not go forward, so the thoughts I leave you with
are:  Signed does not mean secure.  I mean validatable means secure.

 And from a technical perspective, there are ways to determine the
difference between a zone that is signed versus a zone that is
validatable.  There's a particular bit in the validating resolver
called the AD -- authenticated data -- but that, you know, will
provide the information.

 So the -- without the DS in the root zone, the TLD zone itself is
not validatable, and some would say that as a result, it's not really
of much use, even though you could claim that it is DNSSEC signed. 
Thanks.

 >>STEVE CROCKER:  Thanks very much, Ram.

 And our last talk is Frederico Neves from Brazil.

 >>FREDERICO NEVES:  Next slide, please, Julie.

 Good afternoon.  My name is Federico Neves.  I work for the
Brazilian registry, NIC.br.  

 I will give you a short update on what's going on in DNSSEC for br.

 Basically, a pretty short introduction.  

 What is NIC.br?  It's a not-for-profit organization.  We basically
provide infrastructure for the Brazilian Internet.  

 So we are the registry for br.  We are the NIR for Brazil.  We
promote international exchanges in the country.  We run the Brazilian
CERT.  We provide some statistics for the ICT in the country.  And we
have some projects in the measurement of Internet quality.

 We are a quite large TLD with 2.3 million delegations, but they are
divided in 66 zones.

 The majority of the delegations are below dot com dot br that holds
around 90% of the zones.  Next slide, please, Julie.

 Next slide.

 Oh, sorry.

 The DNSSEC history in Brazil.  We have deployed it.  It started in
December 2006.  Our initial deployment took some small zones in the
br zone.  

 Since the beginning, we started with the signed zone and the
collection of the DS records for the zones that we have available. 
We always thought of DNSSEC as a first customer -- first kind of type
of citizen so there is no difference from the normal service for the
DNSSEC one.  So we always had it available on the Web interface and
over EPP too.

 Here we have a reference for the old spec, but we already are
implementing the 4310BIS.  

 And our final deployment, we ended in January last year, 2009, with
the signature of the three large zones -- dot org, dot net, and dot
com -- that are signed using NSEC three.  All the other zones are
signed using the DNSSEC BIS NSEC technology.

 Next slide, please.

 So the deployment strategy we created, one of the ideas that we had
and we have implemented in 2007 and 2008 is the creation of kinds of
safe havens, special domain names that to get a delegation you need --
the delegation needs to be signed.

 So we have a special domain for the judiciary power.  It's called
dot jus dot br and actually the judiciary power in Brazil moved
completely from dot gov dot br in the past to this new zone, dot jus
dot br.  

 And we created a special domain for banks, too, b dot br, and it's
signed too.  Especially so to get inside of the zone you need to be a
bank, so there is further checks to get a delegation.

 We provided some tools for hosting -- especially for hosting
providers.  There, you can go -- you can see the URL.  It is listed
on Russ' slides too.  It's called DNSSHIM.  

 We provided some training on operators' meetings and we continue to
outreach to ISPs and hosting providers, and we have special attention
to these hosting providers that we have around 45 of them in Brazil
are currently talking EPP to the registry.

 Next slide, please.

 Since the beginning in 2009, we -- the beginning of DNSSEC in 2007,
we did most of the operations of signing and rollovers manually, and
this was actually a problem at that time.  And one point that I could
raise here for anyone that is starting to do DNSSEC is that
automation is key.  You need to automate.  You need to test.  You
need to make automated tests for these operations.

 So we started with key ceremonies for doing the signing with the
KSK and the rollovers of the ZSKs and the KSKs, too, if needed, and
we just had our -- on the 22nd of November, last month, our third
ceremony.  The one that is -- that we call 2011 1.  We have two
ceremonies per year -- yes, per year, and this one of covers the
period from February to July every single year.

 And according to our key policy, it's -- we have generated two new
br ZSKs and six others actually -- actually, or 12 other default keys
that we use to sign the second-level zones.

 Next slide, please, Julie.

 And we have just rolled out a new service.  It's still not
available for all dot br zones.  It's a hosted DNS service, and we
are playing a little bit of dogfooding here, so we are using the
DNSSHIM, that piece of software that I told before, and actually what
we are trying to do is to provide basic DNS services with DNSSEC
signed by default.  

 There is no single information for the -- for the end user that the
zone is signed.  It only needs to configure basically -- we have a
basic interface for somebody that is hosting a domain name on Google
apps or maybe on -- or a blog or something that is pretty simple that
you normally only need to configure an A record or if you have e-mail
services an MX record or something like that.

 And we have an advanced interface but it's still simple DN -- a
pretty simple DNS service, but DNSSEC is done by default.

 And with that, we are trying to raising a little bit the bar for
ISPs in the country, and basically our idea is to have DNSSEC pretty
well deployed before we get to the point that we have really nice
applications like the transport of certificates and the provisioning
of TLS for the masses that DNSSEC is probably a good way of doing
that for us.

 And that's it.

 I have two more slides regarding this hosted service.  

 Next slide, Julie, please.

 So here you can see -- next one, Julie.

 We have deployed this hosted DNS service two weeks ago, and it's
only available in 8% of the zone -- domains.  It's only not available
for dot com dot br but we plan to roll out in the next couple of
weeks.  

 So as you can see here, this is a one-month period.  We have gained
more DNSSEC signed zones than we have in the last year.  

 That's it.  Thank you.

 >>STEVE CROCKER:  Thank you very much.  

 Any questions?  

 Are you running into any problems?  Are you anticipating things
will just keep rolling right along?

 >>FREDERICO NEVES:  Sorry?

 >>STEVE CROCKER:  Are you anticipating that things will just keep
rolling right along?

 >>FREDERICO NEVES:  yes, yes, yes.  Moving smoothly, yes.

 >>STEVE CROCKER:  Good.  Rod?

 >>ROD RASMUSSEN: Hi.  Rod Rasmussen.  So I just wanted to make
clear I was clear on your presentation.  

 The financial services industry has been required to sign?

 >>FREDERICO NEVES:  No.  We have a special zone called b dot br
only for banks.

 >>ROD RASMUSSEN: Right.

 >>FREDERICO NEVES:  And no credit card, only banks.

 >>ROD RASMUSSEN: And they are required to sign?

 >>FREDERICO NEVES:  They are not required, but if they want a b dot
br zone, they are required to sign.

 >>ROD RASMUSSEN: Okay.  And so from that -- 

 >>FREDERICO NEVES:  It's not mandated.

 >>ROD RASMUSSEN: Right, right.  I just wanted to understand how the
program worked.

 >>FREDERICO NEVES:  Okay.

 >>ROD RASMUSSEN: So my questions on that are:  What is the adoption
rate and what are you seeing as far as failures and things like that,
and are there any studies being done where you can get statistics out
about how the -- how successful that is?

 >>FREDERICO NEVES:  All the large banks in the country are -- have
the b dot br versions of them, but the majority of the marketing
departments from banks have kind of a reluctance to move from the dot
com dot br domain name that they have been marketing for almost a
decade, so we -- some banks, large ones like Bradesco and other --
another one, large one, you can access actually the home banking
using the b dot br but they are not yet marketing it.  

 So regarding the success of the program, it's -- it's not a big
success so far.

 >>ROD RASMUSSEN:  Love to get information as that rolls out about,
you know, adoption rates and success rates and failures and things
like that, because it's -- you're kind of leading the charge there,
to a certain extent.

 >>FREDERICO NEVES:  Okay.  But we -- we are not collecting this
yet.  We are planning on meeting with them in January in a special
meeting with the banks just to try to promote again this.  This is
something that we are trying to push for the last two years, so we
will give a new try in the next month.

 >>ROD RASMUSSEN:  Thanks.

 >>STEVE CROCKER:  Thank you.  Any other questions?  

 Well, I think things have come together extremely well.  I
appreciate everybody's participation.  Let me again thank our stellar
program committee, all of our speakers and panelists.  Another
excellent show.  

 We'll see you all in San Francisco, I hope, at the next ICANN
meeting.  And with that, the DNSSEC session is closed for today and I
think we're in time to clear the room for the next group that's
coming in.  We're good.  Thank you all.

 [ Applause ]

 ***Live scribing by Brewer & Darrenougue - www.quicktext.com***