DNSsec Meeting
 ICANN Meeting - Paris
 Wednesday, 25 June 2008
 
 
 >>STEVE CROCKER:   Welcome, everybody.  This is the DNSsec session.  My name is Steve Crocker.  This is Russ Mundy.  We are co-chairs of DNSsec deployment group.
 And this is logically part of an SSAC activity but has enough size and depth that we have been running it for a number of years as a somewhat separate track within ICANN.
 We have an amazingly dense, jam-packed schedule today.  So we're going to try to make this above along very rapidly.
 Here's the basic agenda.  I am speaking at the moment, as you see.  And will say a bit more.  Then we'll have a whole series of talks on DNSsec in the field, and another set of talks on DNSsec tools.
 Here is the seven -- I think that's right -- seven talks that we have scheduled on DNSsec in the field.  And here are another five is the right number, DNSsec tools.  And we're going to be out of here at 3:30.
 Let me turn it around the other way.  We're going to be out of here at 3:30.  We're going to have as much content as we can pack into that.
 With that, let's see if I have all the mechanics set up here properly.  I need to -- oops, I did that one.  And, let's see, it is something like --
 >>RUSS MUNDY:   So just in terms of logistics and timing and such, because it is a full schedule, all the speakers have been given a pretty short time allocation.  We'll be watching that closely to make sure we can get everybody in.  There probably won't be much time for interchange between people.  And since the room has to be emptied at 3:30, it will be let's gather in the halls.  We do encourage everybody to talk and ask questions and follow up.  But, unfortunately, it may need to be out in the halls afterwards rather than here in the meeting room.
 >>STEVE CROCKER:   So on the agenda is -- it's a DNSsec status report.  The last time, we said that we were going to issue an SSAC report on the status of DNSsec covering a number of different entities, reviewing all of these things.  This is the same material that I covered briefly in the SSAC meeting two few days ago.  Here's, roughly, where we stand.  Some of these are not completed.  Some of these are, in fact, well along, process is defined, and an RFC published for the key rollover, a white paper published on trust anchor repositories, other things that are still going.  One of the very exciting things is a survey of availability of DNSsec on commonly used DNSsec server platforms and also a survey is now starting up on what are some of the limitations on existing small routers and firewalls in processing DNSsec responses that come back.
 Here's a picture of -- screen shot of what's available on the ICANN Web site.  This is SSAC report 30.  And this is downloadable and studiable in PDF files and is being updated as we get more information. 
 And so that's that.  
 And with that, now, is Lyman here?
 Lyman knows he's supposed to be here.  I've talked with Lyman.
 Well, we had --
 >>RUSS MUNDY:   Okay.  Since we need to break the agenda anyway, at this point, (saying name) needs to leave earlier than expected.
 >>STEVE CROCKER:   That's not the sequence at all.  But we can do that.
 Okay.  So Alexa, instead of putting you up next, with Lyman, we'll squeeze JOAO and come back.
 >>RUSS MUNDY:   There he is.
 >>STEVE CROCKER:   The next question is, can I locate his slides.
 You just went from nearly last to first.
 And I think I want to do -- no, that's not what I wanted to do.  There we go.
 >>JOAO DAMAS:   Okay.  So this is about things we're trying to do with regard to bind and related software to try to ease DNSsec deployment and make as much as possible towards quick implement.
 Skip this one.  Everyone knows where DNSsec is at in this one.
 So we have this outstanding problem.  The root is unsigned.  It will probably remain so for a little while.  Of the TLDs, there are many that are unsigned.  There are a few that are already signed, and at least dot org is planning to be signed soon.
 Can you move.
 So what does a user do when they -- when they need their --
 >> Standing in front of the slide.
 >>RUSS MUNDY:   Or stand in front of it.  Whatever you want to do is fine.
 >>JOAO DAMAS:   I would like to see the slides.
 [ Laughter ]
 >>STEVE CROCKER:   Why don't you just take over.
 >>JOAO DAMAS:   Okay.
 So there is the -- the whole thing of what you have to do if you want your zone signed independently of your parents do or don't do.
 And how to make it easier.
 Right now, the process is not as straightforward as possible it could be.  And I think there are technical solutions that we could use to facilitate that.
 Also, in -- even if the root were signed and your direct parent TLD was also signed, there would be still the question of how you get your keys into each zones.
 There is usually -- your domain is registered through a registrar, and there's the question of whether your registrar will ever be interested in handling DNSsec.  So for all of these temporary problems, we put together this solution in BIND some time ago called DLV, domain lookahead validation, which we are considering as a matter of local policy for resolvers and zone owners and not so much matter of protocol.
 So far, this feature is implemented in BIND resolver, and it's a question whether there will be more or not.
 This is the process for how DLV works in two quick sentences.  Basically, if you want to have DNSsec validation turned in your resolver, you would first do a normal DNSsec attempt.  And if it fails, then if you have DLV configured, you'd go look in your DLV registry of choice and try to follow that.
 It works.  The only problem is that the implementation right now and the process as it is designed right now only allows for the existence of one registry at a time.  And that has raised some issues with some people.
 There are people who have shown interest, mostly closed networks, like .MIL.  But for making this a more general solution, we are now talking to people like Roy Arends, who had this quite nice idea of changing the model just a little bit so that it would have room for anyone to choose where to go with your DLV registry.
 So that there is a mechanism built into the DNS itself that would take over the manual configuration that's in place now and put in place a sort of DNS lookup-enabled way of where to go finding your keys which they will be registered to use for this particular lookup.  And that, we hope, will make enough of a difference that people will start using this, and you'll see more DNSsec deployment.
 So this will go through the (inaudible) processes normally, and we will support it.  We will be implementing it as it goes forward, and we will definitely have it by '09 when it comes to conclusion, hopefully.
 Another feature that some particularly big zone owners wanted to have in this and have been discussing for some time was the availability of the NSEC3.  The original DNSsec had the NSEC record, which has the feature -- for some people problem -- that would enable easy zone enumeration.  The solution for that has been pitched as NSEC3.  
 We have been supporting that standard development process from the beginning and producing early implementations that were made available for workshops so that the standard could progress quickly.
 That standardization process is now finished, so we are now working to have this feature available in BIND 9.6, which we are still expecting to come out at the end of this year.
 We are already, since the way we carry out projects is usually in cooperation with someone who is really interested in having this feature, we already have providing code snapshots to the people who have been sponsoring the development.  And the tests all seem to indicate that the implementation is working well, that the impact on performance on even a big, big zone is perfectly okay, no need to change any provisioning mechanisms or so.  So it's all going very well.  And I think you'll see these being used -- using BIND as the software within this year.  It's all going according to schedule.  I cannot often say this.
 Another thing that people have asked us to look at is what we are calling online re-signing.  When you have big zones, particularly if the zones are being updated incrementally, rather than reloading from scratch each time you make an edit to the zone, you soon come across the issue of how to keep these zone's signatures valid and not have the whole zone go stale, which would have big impact on how you do the operations.
 So we are implementing this new feature in bind as well that will allow you to do -- if you have an online key, meaning if the key is actually stored in a system where bind would have access to it, and they leave it up to you to define how secure you want that system to be.
 BIND will by itself make sure that the signatures stay online, that if the new keys, when put into the zone, are used to sign the zone is in an incremental way, so there are no big in terms of service as normally DNSsec processes take place.
 As a kind of side benefit of this, we have had to implement support for crypto hardware in BIND.  So it now at least understands at least two devices I think it is right now, that you can use to accelerate the kind of expensive crypto operations that are related to generation of signatures.  That's also scheduled to be available this year.
 And then you still have the issue of what about the smaller zone owners, the people who have a company and have control of their domain name and want to make use of this stuff.
 And we are looking at how we can make the whole process simpler, how to integrate the process of enabling bind, generating your keys, keeping them secure, signing the zone, making sure the signatures don't expire, with a minimal of system administration or technical engineering time having to be devoted to this process.
 And this is perhaps a little bit more long term than the project I have talked about.  But the idea is, basically, if you take the decision that you want to run this on your zone, then there is very little additional effort you'd have to do to actually reach that goal.
 One of the goals also is to try to as much as possible include in it the interfaces that you would need to move the DS records into your parents so that your DNSsec becomes affected.
 And that's the plans we have so far for this year.  And if anyone has questions, or we'll move to the next one.
 >>RUSS MUNDY:   Thank you, Joao.
 >>STEVE CROCKER:   Thank you.
 Well, what we had was a paired set -- what we had in mind was a paired set of presentations.  Lyman Chapin heads up the RSTEP process.  And there's a report that they've done, evaluation of PIR's request to run DNSsec in the dot org domain, to be followed by Alexa Raad from PIR.  I'm going to try to pinch hit for my good friend, Lyman, and hope that I don't do too much violence.
 But I think it's helpful to get the pair of these together.
 So is that okay with you, Alexa?
 I'm still getting acclimated here.
 Okay.  So the basic format of what has happened is that Public Interest Registry runs the dot org top-level domain, and applied to ICANN for permission to add DNSsec capability to its operation.
 Within ICANN, there is a process called a Registry Services Technical Evaluation Panel review process.  And that is invoked whenever there is a substantial technical change which may have security or stability implications.
 A professional team is assembled rapidly.  There's a standing group of people available.  They took a bounded period of time, looked at this, and then issued a report.
 They took a bounded period of time, looked at this, and then issued a report.  And with apologies for not being Lyman but wanting to move this along, I will do the best I can at conveying this.
 So I think I have described here the essence of our RSTEP is about that's on this slide.  The RSTEP team reviews and evaluates the proposal, reports to the ICANN board, it's posted for public comment.  That report is, in fact, up and available for public comment, and I think the period, public comment period, is still open or it's just closed?
 >> It's closed.
 >>STEVE CROCKER:   It's closed.  Too bad.  Can't say anything more.  And then the board decides whether or not to approve the proposal.  It has not yet come before the board.
 The PIR proposal introduces the security extensions specified in the protocol, which I suspect everybody here is pretty much familiar with dot DS records for the domains in dot org zone, changes in the registry -- registration process to allow updates from registrars through EPP and to show information in the WHOIS status.
 Our step review focus based on technical feasibility took into effect the importance and size of dot org, and focused some attention on the fact that this is in the context of the parent zone -- namely, the root-- not being signed, and, therefore, the public key for the dot org zone would have to be distributed by some fashion and be available on its own.
 The principal issues that were identified were rollover and compromise of the dot org key signing key, the consequences of misconfiguration, issues of registrar participation and cooperation, and generic issue of deployment of a major new technology.
 The overall assessment is contained in a paragraph that is highlighted in the report that PIR's proposal does create a reasonable risk of meaningful adverse effect on security and stability.
 Boy, that sounds really terrible.
 Which can be effectively mid mitigated by policies, decisions and actions to which PIR has either expressly committed to in its proposal or can reasonably be required to commit.
 So that brings back -- sort of steps way back from this is terrible (inaudible) of saying, but we have got this or they will have this under control.  At least that's the way I read it.
 And I have now come to the end of Lyman's slides.
 I could attempt to take questions on this, but probably better to move now to Alexa and if Lyman comes in, I will make a point of giving him some time to speak.
 That's not Lyman.
 >> Alexa Raad:  Thanks, Steve.
 I am going to move up here.
 >>STEVE CROCKER:   And I will turn this over to you if you wish.
 >> Alexa Raad:  Am I blocking anybody?  Thank you very much.
 Hi, everyone.  I am Alexa Raad, I am the CEO of dot org.  And this is actually my first time, I think, presenting in front of the SSAC, so....
 I am going to be talking about our responses to the RSTEP report.  And sort of the agenda I am going to follow, I am going to set in context our implementation approach, because I think it's really important that you guys understand the motivation that we have for implementing DNSsec and what -- the kind of approach that we are taking.
 And I will be talking about a little bit the RSTEP outcome report, essentially along the lines of what Steve said.  And then talk about the risk analysis.  You know, what we did and how do we categorize the risks.  And due to the interests of time, I am going to only talk about those risks for which we are actually going to change our plans or mitigate our plans.
 And then talk to you guys about the milestones.
 So in terms of our approach and our motivation, PIR is actually called Public Interest Registry, and our motivation in almost everything we do is to do something in the public interest.  So if there's one thing that you take away from this presentation, it's that this, for us, is not a commercial venture.  It is not a product launch.  Okay?
 Product launch is there is money in it, there's a set time, set schedule.  And it's commercial in nature.
 For us, this is entirely about doing something that we believe is fundamentally in the best interests of the Internet and the end users, and also doing it in a collaborative approach so that whatever we learn, we are able to share with the rest of the folks in the community.
 So in order to -- Fundamental principle is that if you are going to -- if you believe that DNS is really the fundamental layer for a lot of technologies and the expansion of the Internet, then if you are going to provide for a secure future, secure Internet, then you have to think about the fundamental layers.  The DNS layer.
 And there's been a lot of talk, I don't have to kind of review it again, but a gTLD coming forward really helps in terms of accelerating the adoption and helping in terms of the awareness.
 Our approach is to really, again, collaborate, learn, and share.  And we owe a debt of gratitude to our friends and partners in the ccTLD community, the NIC SC, special gratitude to Nominet who have really done a lot of work on dot BR, who have implemented DNSsec, who are working on the implementation.  Obviously our backing partner Afilias has been absolutely instrumental.  But ultimately, it's to understand what has actually gone before us, and then try to incorporate those lessons into our approach, turning that back around to the community and learning from that collectively.  And continually doing that process.
 As an example, we plan to do a number of different surveys to kind of gauge the adoption of DNSsec, look at the different segments that are involved, figure out what are the most important segments in terms of adoption, which has to come first, what are the key, critical, if you will, hot buttons for adoption.  Is it education?  Is it awareness?  Is it technical?  Know-how?  And then try to approach it.
 One other thing I will say is that we are a very small organization; okay?  And we're taking a big step.  We're the first gTLD to start this process.
 By no means do I want to stand up here and say that we will do it all alone.  Thankfully, we are not without friends in this community, and we have had a lot of help.  However, I am really calling on -- I have had a number of ccTLDs come up to me in the last few days and say we are watching your effort.  We are very interested.  We want to learn from you guys.  My challenge back to you is, we will absolutely share everything we learn.  However, I really would like the feedback from the community as well.  We cannot do the education alone.  There is no way that we can educate the end users on our own or really reach out to some of the segments, because we simply don't have that kind of reach.
 So I really encourage the community to step up along with us.
 So RSTEP essentially gave us a thumbs-up report.  Again, I have to give kudos to folks in the RSTEP community because they did an exhaustive, exhaustive analysis of our proposal.  And they came up with a large number of analysis and risks.  Some of the risks were basically very, very low probability; right?  But they still mentioned that.
 So they did a fantastic job.  And that certainly helps us and helps the community.
 So key observations was, look, a signed root, many of the issues can be resolved with a signed root.  Obviously we are in favor of it, but unfortunately, that's not in our hands.  If it were, the signed root would be here today.
 The other thing they said was registrar adoption is key.  We couldn't agree more.  In fact, we did a survey prior to -- we have been working on this, by the way, for over a year and a half, if not more.  And we did a survey and we asked our registrars what do you plan with DNSsec.  Are you interested?  How interested are you, et cetera?
 And ICANN had categorized interest as I am interested in a Lamborghini.  That doesn't mean I am going to go out and buy one.
 We have had very pointed follow-up discussions with registrars all throughout this week, especially those who indicated that in our survey.  And the discussions took the following form. When you say you are interested, why are you interested?  What is the level of interest?  Is it for my information, my knowledge?  Is it that your registrants are asking for it?  Is it that you see a need in the marketplace?  And if so, what do you need?  Do you need education?  Education is, what?  For your end users?  For the registrants?  For your technical staff?  For what?
 And what can we do, PIR, to help you along?  And how quickly will that facilitate your adoption?  Are we talking, you know, six months?  Three months?  Nine months?
 And what can we grab for the community to come help you.
 So again, our discussions -- what I mean to say is our discussions have been rather pointed about that.
 The good news is we have now had, as of last count, just met with my team this morning, two major registrars, both of them large hosting providers, who basically have answered yes, yes, yes, to all of those, and the kinds of things that they need are not so much in the technical realm, but, rather, in the registrant education realm.  And both of them have said that they have, actually, had some of their registrants come up and ask for information on DNSsec.  And indicated interest.
 So the interest is now market driven, which for me was a little bit of a surprise.
 And also they said that for them, they view this as a differentiator for their hosting platforms.
 The other thing it suggests is use of multiple key signing keys.  We are evaluating that.  It's really an issue of usability versus stability.  You know, the one thing -- it's a balance.  And the one thing that I think most people will agree with me on is you don't want the element of surprise.  When somebody is surprised, it tends to create a lot more problems than you initially anticipated.
 But we're evaluating that.
 Another concern was about stopping DNS if needed, and proposed implementing RFC 5011.  This RFC is very new.  I frankly don't no much about it so I am not the one to ask.  But in our opinion, this really doesn't solve a problem because a key set compromise would still need a full stop anyway.
 So we took the risks and put them in four categories.  First category, we said this is a risk; however, it's really not inherent or specific to DNS.
 Registrars have to manage a specific information for the registrants.  Their credit card information, their passwords and so forth.  They also have to now manage DS information.
 So yes, that is something that can be compromised.  However, just like anything else, they have to have good practices for it.
 So this is not something that is inherent to DNSsec.
 The other ones are, yes, it is specific to DNSsec, but the probability is so low that it does not materially impact our plans.  You know, if I walk outside, there's a probability that I will be struck by a thunderbolt.  Am I not going to walk outside because of the fact that I might be struck by lightning?  Probably not.  So we noted that, and that's why I say that the report is thoroughly complete and exhaustive, but it doesn't materially impact our plans.
 Third category is specific to DNSsec, but frankly, we really don't know we're doing everything we can.  I am going to go through all that with you.  However, we won't know until we actually implement DNSsec.  We are the first gTLD to do so.  There are a number of things, the parallels between dot SC and dot BR are not exactly the same as it would be for us.
 So we're just not going to know.
 And then there's stuff that is really specific to DNSsec.  They did a great job of pointing some of those out to us, and we plan to address their plan accordingly.
 So all of this, by the way, has been provided.  It's up on the Web site so you can do so at your own leisure, go through it.
 For the interest of time, I am going to try to focus on the number 4, which are the risks that we consider valid and that will effect our plans.
 Three four five has to do with the number of registrars that actually implement.  So we totally agree.  We have been thinking about that issue.  As I mentioned, we have been talking to the registrars and I already gave you an update on that.
 Three five five has to do with the registrants and the fact that a signature has a particular life, valid life, and that a new one has to be created before the old one expires.
 So this imposes a little bit more maintenance on the part of the registrant in terms of maintaining their data.
 So again, we agree and we have been talking to the registrars, the pointed conversations I talked to you guys about.
 We agree.
 And one of the things that we need to do, and I think with the two (inaudible) I talked about, these guys -- these particular -- particularly these two registrars are, in my opinion, anyway, masters of really educating their customer and making it very, very easy.
 So on our part we are dedicated to netting out the problems, the technical issues for them, so they understand the kinds of specific information they have to pass on to the registrant.  On their part their talent comes in because they are very good at communicating something that potentially could be complicated in an very easy way.  We have even talked about the possible use of animation or videos to make this process easier.  Registrants, as you all know, don't sit there and read 35 pages of technical data; right?
 Three six two talks about a report of DNSsec problems, reporting that may come up.
 So a couple of things that we have done -- it says that dot org is an original TLD and that the parallels between dot BR and dot SE, obviously they have gone ahead.  They have been the first ccTLDs, but it's not an exact parallel to us.
 So how would we actually handle any kind of DNSsec reporting and problems?
 So first of all, and I suggest that we create a system for that.
 So first of all, for the registrars, we have an (inaudible) that basically starts 90 days before we sign the zone, and the registrars we talk to are fully aware of this and this allows them to get in there and play along and net out any problems and let us know so we can kind of turn that learning back, collaborate, share and learn back to the community.
 The second thing for the registrants, we will also publish an e-mail address so that any problems that they have on the end user or the registrant, they can actually let us know.  Again, we can document the problems and turn that back out.
 Also remember that we are part of -- We are very active in communities like RIPE, NANOG, our partner Afilias, as part of IETF, for example.  ISOC is our founder and so we are within the ISOC family.  So we are very involved in those communities.  And DNSsec is a major topic within those communities, within RIPE, for example, the DNSsec working group.
 So all of those things actually do come up, and we have a chance to not only be very close to the problems as they come up, but also be very close to experts who can help us solve them and then be able to publish the results back, which by the way, we will on our Web site, and the Afilias Web site, as we come across them.
 Okay.  The last one has to do with the trust -- getting -- It was actually titled getting validators to remove the PIR trust anchor after the DS root is signed.  This really is an issue of education.  It says we can mitigate the impact by incorporating information into our communication and education effort.
 (Speaking too quickly.)
 Again, that's one of the things we are doing, not only with our partners, but also the registrars.
 And hopefully within the name server and the ISP community.  Bottom line, what they say is it can be mitigated both when doing (inaudible) before the root is signed and then after adding a DS record to the root zone.
 So this is fully under consideration by us.  Education and awareness is a huge task so, again, I don't want to set up the expectation that we are fully doing this on our own, and I inviolate the community, if you haven't heard me, I'll say it again, I invite the community to help us with that.
 So basically, really, their suggestions and what we are evaluating comes under the following categories.  Key management.  We are actually looking at the suggestion to use multiple key signing keys to mitigate the bogus zone problem.  In terms of key rollover policies, we think we are actually following a pretty good rollover policy, trying to strike a good balance between usability and security, and following things that are really in the vein of existing security procedures.  For example, our zone signing keys will be updated at least monthly, and the key signing keys will be updated at least yearly.
 One of the things I am going to talk about in the milestone, but you are going to see it here, is we are trying to also mitigate further by having a phased approach.  So the first phase is a friends and family phase which is only going to impact a very small number of names.  For example, PIR.org, IETF, ISOC.org, IETF.org, et cetera.
 All of that should be able to mitigate the impact.  And also allow us the opportunity to learn before we go on to a larger scale.
 The second one was, as we talked about, the use of Trust Anchor Repositories.  You guys just learned about the locus side validators.  Currently we don't plan to do that.  We are planning to place the keys for dot org in the IANA DS registry.  And last the registrar adoption and registrant adoption.  As I said, we're actively working on that, and if you know of any registrars that we haven't talked to, point them to us.  But also we believe the testing site will help because the OT and E site will actually be live over a year and a half.
 So controlled launch, we already talked about the RSTEP process.  Q4.  We expect the Bind release which will be compatible with NSEC3, and also the hardware security module integration.
 Q1 of 2009 is when we anticipate zone signing with a very controlled, limited launch of the friends and family.
 By Q3, we expect to expand friends and family based on the results of the first phase.  So in other words, the reason I said this is not a product launch and rather it's a process, it's a shared learning and collaborative process is because if anything happens during those times we are taking a very, very cautious and careful approach.
 We obviously care deeply about our responsibilities.
 So we're taking a very cautious approach, and if anything were to happen, we certainly would deal with it accordingly.
 So think of these things as estimated milestones.  By 2010, hopefully if everything goes well, we will have mainstream availability, but all of that will be subject to monitoring.  And I think that's it.
 >>STEVE CROCKER:   Thank you.
 >> Thank you very much.
 [ Applause ]
 >>STEVE CROCKER:   Good.  Lyman, would you like to stand up and take a bow for the great presentation that was done on your behalf?
 >>LYMAN CHAPIN:   Steve, I'm sure did you justice to every word on the slides.
 I apologize for not being (inaudible).
 >>STEVE CROCKER:   Then we have a presentation from Portugal.  We have Eugenio Pinto and Sara Monteiro.  And let's see what I want to do is -- here we go.
 If you want, you can press this or I can -- okay.
 >>EUGENIO PINTO:   Hello.  First of all, I would like to a congratulate the ICANN staff for having prepared this public meeting specifically focused on the always interesting DNSsec matter.  As always, we do show our appreciation for giving us the opportunity to present some results from our work on this subject.
 Our presentation goal is to demonstrate some benefits of using dynamic update enabled environmental if we are willing to provide DNS security extensions features to our users.
 All the data presented is related to the Portuguese ccTLD registry run by FCCN.  You can see more about this entity at www.dns.pt.
 By the way, my name is Eugenio Pinto.
 >>SARA MONTEIRO:   And I am Sara Monteiro.  We will try to do our best in order to explain all the things in the ten minutes we have for the presentation.  However, if you are interested, and we hope so, we -- you -- if you would like to know more specific details about any of the topics presented, we can always join -- you can always join us at the coffee break and we will be very pleased to give you additional information.
 So let's start with the first slides.
 When we talk about DNSsec, we immediately think about signing zone signature and authenticator response.  These are the main assumptions to a secure DNS world.  
 However, authentication as we know it, using encryption algorithms supplied in DNS, leads to a nasty effect, like the rising of the required resource on building a zone file.
 The resources can be measured in terms of processing power consumption, memory, or even time.
 This presentation shows how to employ dynamic updates in order to optimize its use.
 As you can see in this graphic, this showed the (inaudible) of the number of delegations registered under PT during the last month.  Our zone file is gradually growing in a nonlinear put persistent way, reaching, at the end of the month, around 104,000 delegations.
 Although, analyzing this other graphic that shows the amount of changes made to the zone resource records on a daily basis, also in the last month, we can see that there are very few updates being made on the zone file, with big values of just around 400 updates per day.
 If you could just sign the updates, you could save a lot of time in writing resigning or resource records.
 Okay.  So we'll compare numbers, with around 100,000 delegations in the zone and 400 domain updates per day, using the DNSsec-signzone tool.  Every time we do a full zone signing, we have to sign all 104,000 delegations.  So, like I mentioned, if you could just sign the updates, we could save a lot of time avoiding the re-signing of resource records that were previously signed and were not updated.
 >>EUGENIO PINTO:   But we can.  Doing dynamic updates is -- in an already-signed zone BINDS automatically signs every new resource record and updates the necessary NSEC resource records, too.
 And best of all is that it's very easy to use this feature.
 Let's compare full zone generation and signing versus dynamic updates with signature on the fly.
 Starting with full zone signing.
 An analysis of the time required to build the entire zone files from the database shows it takes 135 seconds to conclude.  The signature of the zone file takes even more time, 150 seconds.
 Finally, the reload of the zone takes around nine seconds which means the total time required to sign and install a new zone file using full zone signing takes around five minutes.
 Now let's see some results on dynamic updates and signature on the fly.
 This graph shows two different lines.  The blue line represents the time required to send and load different numbers of resource record changes on a single dynamic update for an unsigned and signed DNS zone.
 Because of some DNS protocol restrictions in packet length, we have reached the limit on a single dynamic update at 1,400 new domains, with two name servers each and with (inaudible) records.
 We have not enough data to interpret the (inaudible).  However, the relevant information we can take from this shot is that, in our server, a single dynamic update on unsigned zone takes no more than three seconds to be processed.
 The yellow line shows similar data, but for a signed zone.  The (inaudible) values shown are related to the extra time required to the signature on the fly.
 As we can see, a single dynamic update on a signed zone takes no more than ten seconds to be processed.
 We can also realize that in less than five seconds, we can update up to 800 domains.  So let's compare numbers.
 Our calculations show that the actual full zone (inaudible) and subsequent signing will always take up to five minutes to conclude.  With the last results, we have seen that a dynamic update can be very quick, and in less than five second, we can change up to 800 delegations in a signed DNS zone.
 That's a big difference and big saving in resources.  Just notice that five seconds is 1.7% of five minutes.
 So --
 >>SARA MONTEIRO:   So dynamic updates and signature on the fly solve the processing power consumption issue.  But does it itself bring other concerns, like security issues?
 >>EUGENIO PINTO:   Yes, it's true.
 Our suggestion is that you configure BIND to accept dynamic update requests only from your own machines, and using a key that only you know.  For additional security, you should enable dynamic updates to your zone just before you do a dynamic update and disable it right after.
 This way, you will avoid having the feature enabled for a long time, reducing the possibility of exploit of this feature.
 There is another issue related to key rollover and signature expiration.
 From time to time, you should sign into our zone to renew the resource record set signatures as well as your public keys.  This can also be useful for protection from any kind of dynamic update failures.
 >>SARA MONTEIRO:   Hmm, tell me, if you have to sign our entire zone anyway, what are dynamic updates for?  It is really necessary?
 >>EUGENIO PINTO:   As we stated at the beginning of this presentation, our goal is to demonstrate some benefits of using dynamic update-enabled environment when implementing DNSsec security extensions.
 So dynamic updates aren't really necessary, but can help.
 And as mentioned by Joao Damas, BIND is coming up with the online re-signing feature, which will make full zone signing not really necessary.
 >>SARA MONTEIRO:   Okay.  That's enough about dynamic updates, as this session should be about DNSsec.  So we will finish our presentation with the status of DNSsec implementation at dot PT.
 Our main concerns for DNSsec deployment are NSEC and --
 In order to avoid zone walking, DNSsec will only be available for our registrars after a successful NSEC 3 patch is applied to the BIND server.
 In the matter of the key rollover, we will lose very short time to (inaudible) and timely mitigate them.  And for the same proposal, our development DNSsec server will also be fed by our live data for a while before it is put in production.
 The provision is to be deployed in the beginning of 2009.
 >>EUGENIO PINTO:   So it's finished.  I don't know if there's time for questions.
 >>SARA MONTEIRO:   Any questions?
 [ Applause ]
 >> Do you want to take questions or --
 >>STEVE CROCKER:   Are there any burning questions?
 I thought that was stellar.  That's very impressive.  Very nice work, and a very nice presentation.  So thank you.
 And I congratulate you.
 Moving along, we have Pavel -- am I saying it right?  Pavel Tuma?
 >>PAVEL TUMA:   Yeah.
 >>STEVE CROCKER:   There we go.
 >>PAVEL TUMA:   Good afternoon.  My name is Pavel Tuma.  I am from CZ.NIC, dot CZ registry, and I'm going to give you a short overview about the ongoing DNSsec deployment in dot CZ and Czech ENUM zones.
 I'm going to skip this first slide introduction about the CZ NIC, as we have a tight schedule.
 Yeah, let's move to the DNSsec.
 We as a registry think the DNSsec is the next logical step to improve the registry services and, of course, overall DNS security.  So we decided to deploy DNSsec, I would say, as soon as possible, with the following conditions.
 It will be available for both zones, for dot CZ and Czech ENUM, we will allow users to share the keys, to use the same keys for multiple domains, which should reduce the overhead for the multiple domain holders.
 The DNSsec itself will be free of charge.  We think DNSsec is more a feature than a new service, so everything will be included within the domain registration fee.
 We are going to public our DS records into the DLV repository operated by ISC, but we are definitely not happy with that.  We would like to see a root zone signed by IANA as soon as possible, because, in our opinion, all those work-around, all those separate repositories just make things more complex.
 They mean more effort on the ccTLD operator side, because we have to publish the key somewhere else.
 They mean more effort even on the end user side, because they must configure their resolvers with something else other than just the root zone.
 So, at the end of the day, we think it makes just DNSsec more complicated for everyone.
 Regarding the operations and security, we are going to follow the recommendations in RFCs, so we are going to use the stronger key signing keys, with a once-per-year rotation, and I would say a weaker zone signing keys with a monthly rotation.  Sorry for the typo.  There should be, of course, "RSA."
 All the keys -- all the key manipulation and management will require the multiple persons to be present at the time of doing the action.
 Regarding the zone-walking, it's not a problem for us, because we don't disclose any personal data into the zone file.  But, still, we approached the government to approve that, and we have okay to go with the DNSsec deployment from the personal data protection office.
 Regarding the road map, we announced DNSsec deployment in March of this year.  And since then, we are in the preparation phase, so it means the technical testing of the process, the registry software, update development.  And within this preparation phase, we already signed the ENUM zone and published the DS records into E164.arpa.
 We are going to language DNSsec in public trial in August this year, and because these trials are often seen as the service is not finished and it's not ready for prime time, mostly by the enterprises, so we are -- we don't want to keep that in a trial phase for a long time, so we expect just after one month of trial to run it in production.
 The last thing I'm going to share with you are some experiences from the preparation phase.
 We conduct a little survey among our registrars, and the good results are, all of them said they are going to support DNSsec and offer it to their customers.  Some of them are going to offer some complimentary services, the key management for the customer.  What is not a good result is, nobody from the registrars is going to use it for himself.  But we are going to have some partners for the trial, because we think, with partners, we can get the higher media attention when we launch.
 So we approached banks and media, because we thought, like, these are the natural customers of DNSsec, or users of DNSsec.
 Both of those groups have shown interest.  And this presentation is sort of abated.  We know now the results, and they are positive.  We have the confirmation from one bank and two mainstream Czech media, they are going to sign their zones.
 And quite a surprising output of the talks with them was the overhead of the key management is not an issue at all, because the key management is similar to the SSL keys, SSL certificates management.  And the end users are already familiar with that process, so this is not an issue for them.
 Thank you.  That's it.
 [ Applause ]
 >>STEVE CROCKER:   Actually going live?
 >>PAVEL TUMA:   Yeah.
 >>STEVE CROCKER:   Good.  Thanks.
 >> Hello.  My name is Lutz Donnerhacke.  I'm here for some practical experiences.  I do not know many about DNSsec.  Especially I to not know how it works.
 And so I tried it out to find what will happen.
 Two years -- oh, just a moment.
 Yeah.
 I'm a late adopter.  That's the main point.
 After everything has done, the tools were finished, we can start, or I can start, can try out what will happen if it goes into a production state.  That's very easy, because I'm working for one ISP.  We have a lot of customers.  So I have a large test bed.  I can use them, unless I broke their connectivity.
 First of all, I tried to start a survey and to find out what's really happened in the DNSsec world.
 For the ccTLDs, it's very -- it might be interesting that it's possible to have a signed contract with me, that I do the server for them.  I had some contracts, too.
 The other point is that these DLVs does not work very well.  If they are running on the BIND last year or two years ago, after a while, the validation process stopped with obscure error message.  Nobody knows what happened.  And only stable way to get it running was to sign the root.
 And because there was no signed root, I signed the root myself and put in production state.
 It's based on IANA states, not the other root, no?  It's the same.
 So and deployed it to all the customers.  So, at the moment, there are about 15,000 people using fully validating resolvers.  Most of them doesn't know.
 Next point was to find out what happens if a large number of zones are signed, how's the maintenance?  What's the experience with such things?
 And there was an incident earlier this year, YouTube was gone from the international (inaudible), and the secure Internet domain working group in the IETF has a lot of effort made in producing infrastructure for BGP.  And with a couple of people, I wrote all these proposals.  Go to the very first one.  And the very first one was to use DNSsec.
 And we redo the work, offer a (inaudible) on BGP.arpa, one of the changes in the root that has been included.
 And I will say something about this.
 And the other point is that nobody knows about, even our customer does not know.  And if somebody comes up and says, hey, what are you doing there?  I need a tool to show them.
 So that's the main (inaudible).
 Yep.
 First of all, we need stable software.  We do have stable software beside the DLV issue.
 And the most important point is, if you are going to could this in an ISPN environment, you need a real skilled hot line.  You have to train them.  That's the main point.  If you don't do this, you will fail.
 Upper management commitment is only needed if the customers complain too much.
 We had this only one time.
 More important is that you need some people, technical people, which really like to solve obscure problems, for instance, you can't deliver e-mail if you're a signed zone.
 So next point is, please do not sell it.  If you sell something to a customer, a customer expects something back and there's nothing but (inaudible) in the first place.
 So next one.
 So the hard lesson, first lesson was that my tools do not cover every of the signatures.  I don't know why exactly, but on one day, I missed, had an expired signature on the name server records of root.  And that was the day where we had a four-hours' outage of DNS system completely.  We are now going back to the (inaudible) host for all customers.
 It's an interesting experience.
 Next is, you have to deal with broken firewalls, you have to deal with broken customer routers.  That's okay.  But it has to be done.  And you need the effort to do it.  You need people to do it.
 More problematic is that a lot of people running Qmail can't send e-mail to signed domains.  That's a long history why and how this happened.
 In the first nine months, I killed about 200 or 250 Qmail installations in our region other than mine.  Because they can't send an e-mail.  The problem occurs in a very interesting way.  You sign the zone, nothing happens, nothing interesting happens.
 About one to two months later, the first complaints come in.  That's because Qmail can't send, can't determine the right host to send the e-mail to, assume a temporary error and retry.  The retry period of Qmail is 60 days before it complains to the customer, sending customer.
 So it's completely unrelated to DNSsec signing, of course, because we signed last month, problems occur now, it can't be our problem.
 It's very good for the hot line.
 But most of you already have databases, already have tools, and these tools need to be changed, and they need to be changed only a little bit.  And this little bit can be very, very time consuming.  That's why we offered to several of our customers trained in the BIND configuration, they generate their zones as usual.  We make a zone transfer to us, sign the zone, make a zone transfer back, and use the authentication on (inaudible) to say if the zone transfer of the sign or if it's a request from outside, so you put out the signed information instead of unsigned.
 That works very cute.  So you can deal with customers that on average do not want to change their tools.
 Next one.
 If customer noticed that they are -- have a signed zone, they feel secure.  That's great.  Most don't notice.
 We have a bank.  They were very surprised that they are proven secure against phishing attacks, will not work.  But they are very cute, and they were very -- the only problem is they can't bring it to the marketing.  But it's better they don't tell their customers they have a signed zone now.
 You have to train people.  You have to train people which are mostly unrelated to technical issues.  This can be very, very hard.  And if you are going to do anything with DNSsec, every time, think about its infrastructure.  Do not try to sell it.  It will not work.  Its infrastructure has to be there, as well as IPv6.  It's the same issue.  You have it; it works.
 Interesting point for this area here is that if customer leaves to another registry or change their name servers, they do not move their signed zone with them.  They get a new one.  And the new one is unsigned.  In this case, they face problems, because the zone becomes bogus, at least in our environment, because we have validating resolvers.
 And there's a point I missed in the (inaudible) presentation, what will happen if a customer or a zone is changed from one customer to another and the new one does not offer DNSsec.  It will face problems.  And we have to about this.
 So next one.
 BGP.arpa.  This is a small project.  I do it on personal servers, mainly working as Tomcat Web host.
 It runs.  It runs very well.  The modulation test bed is -- has some impressive data.  It doesn't work with BIND anymore.  We have to switch to NSD, and we faced the problem that some records are so large that they are not longer matched DNS packet limits, so we had to change the internal format, too, in order to get the information out.
 The approach to use DNSsec for BGP is interesting in the point of DNSsec deployment, because it offers a benefit over classical PKI with X500 MIME.
 The first one is that the routers out there do not have the resources to check the signatures.  You have a lot of hardware out there, and this hardware has to be -- work without change.  If you are going to make a protocol change, to all ISPs, please buy a new one.  It will not be deployed.
 DNSsec has the opportunity to do the -- all these cryptographic issues outside, and rely on the authenticate (inaudible).  So it's a very small change on the router software and can be done easily.
 The other point is, routing is a local issue, not a global one.
 If you have local differences from the global routing policy, we have a problem in getting them signed with an external DNS server, you can set up a new trust point, trust key, use a locally-signed zone, use a local used zone, you can share them with your peers, and you have no problem.  Because outside your peering environment, that zone is no longer available; the signatures cannot be validated.  And so the routing policy reflects directly to the DNS implementation works very well fine.
 So next one.
 Because the customers nearly ask what to do, what happens if DNSsec is enabled, I made a small tool to show what happens on a DNS request, what happens behind the scenes, which servers -- where (inaudible) information from, and what happens if a phishing attack is in this way.
 I changed this tool on Sunday.  I broke it completely.  I rebuilt it from scratch in the last two days.
 So I currently do not really use DNSsec validation.  But it's in a stage that you can try it out and see what will happen if the next week the DNSsec validation will work again.
 If you think such tool is interesting to others, please tell me.  If you think you need some information more on this tool, please tell me.
 If you think that the tool is interesting to others, please tell me.  If you think you need some information more on this tool, please tell me.
 I'm happy to include it, but it's all German.  It's for our customers.
 So I'm ready -- oh?
 Yeah.
 >>STEVE CROCKER:   Thank you very much.
 [ Applause ]
 >>BARBARA ROSEMAN:   Hi, I am Barbara Roseman, I am the general manager of IANA.
 And this presentation was actually prepared by Kim Davies.  He has given it once already at this meeting, and I am just cribbing from it.
 This is the resolution that was put before the board and that they voted on.  I'm going to read it out from a different version because the full text wasn't captured here.
 Whereas in the interest of aiding DNSsec deployment, the ICANN board believes that DNSsec trust anchors for top-level domains should be made available conveniently to the DNS community.  It is hereby resolved that the board instructs IANA staff, as an interim measure, to create and maintain a registry of DNSsec trust anchors for top-level domains until such time as the root zone is DNSsec signed.
 What is the ITAR or ee-TAR (phonetic), depending on which language you are working in.  The interim Trust Anchor Repositories.  It's a mechanism to publish keys of top-level domains that currently implement DNSsec.  If the root zone is DNSsec signed, such a repository is unnecessary and therefore this is a stopgap measure and it should be decommissioned when the root is signed.
 The ICANN board voted to implement this in April 2008 based on community requests.
 If the root was signed, this is what the path would look like.
 It isn't, so there are multiple Trust Anchor Repositories out there.
 Our proposed registry details are that it will support different types of DNSsec signing.  DS hashes either SHA-1 or SHA-256, DNS keys in any algorithm, published in a number of formats, list on Web site XML structured format and master file format.  Should work with major software implementations out there.  And we're asking that implementers should not be putting special ITAR provisions in code.  This is meant to go away when the root is signed.  So it is not a permanent repository for these trust anchors.
 Our acceptance model is that a TLD operator can submit a DS key, data -- submit their DS key data via web form.  The DS record is validated against DNS key data in the DNS, and it must match before the DS key is made active in the registry.  We have got a provision where people can submit their data to us prior to a date when they want it to become active.
 The DNS key does not need to be in the DNS at the time of submission, so people can stage their deployment, but needs to validate prior to publication.
 The administrative and technical contacts for the TLD must consent to the listing.  This is very similar to how we handle name server changes currently in the root zone, and this model is fairly robust for ensuring that changes are done only at the behest of the TLD managers.
 The removal model is identical to the acceptance model without the technical test.  And a list of revoked trust anchors will be provided.
 Our exit strategy for the repository will be that it's decommissioned within some number of days after the DNS root is signed, in a number of different presentations I have been talking about like a 60 to 90 day window.  Clearly when we are faced with this situation more pragmatically, we will be able to define that number a little bit better.
 Some limitations of the repository.  The ITAR will only operate for top-level domains.  The keying information that would otherwise go into the root.  And IANA will not accept anchors for descendants of top-level domains.  So no second level, even if the relevant TLD is not signed.  So even if dot com is not signed, we are not going to accept trust anchors from second level dot com domains.
 Why are we doing this?  There's an interest in having the DNS root zone signed with DNSsec.  However, there are a number of questions that still need to be answered and that are inhibiting deployment.
 Most of them are layer 9 issues.
 A few of them -- I'll just be very frank, a few of them are not layer 9 issues.  They are more operationally oriented.  But nothing can be done at that level conclusively until the layer 9 questions are answered.
 IANA has had an operational test bed for some time signing the root zone, and our aim is to be operationally ready once the policy is set.
 So we're in a position to say that we're going to be in a position to say that we are operationally ready to support a signed root zone once somebody tells us that it's okay to go ahead with that.
 The ITAR is intended to assist early adopters in utilizing the technology until the root zone problem is solved.
 Thanks.
 [ Applause ]
 >>STEVE CROCKER:   So, Barbara, thank you very much.  I can't resist.  How long, in your mind, is temporary until the root zone is assigned?
 >>BARBARA ROSEMAN:   I have actually been asked this question a number of times this week, and I have got to say that I truly don't say the layer 9 issues being solved in any short-term fashion.  They have been going on for a while, and, you know....
 My guess is we are not looking at any kind of movement on this for about a year.  And that's just a best guess based on how I have heard discussions going in various venues, and what I see the political problems as being.  And the fact that there has to be a much greater sense of consensus within the technical and operations communities about who is going to be the appropriate signer of the zone regardless of who you think should hold the various keys.
 So I think there are some operational questions that still need to be answered.  I think the technical and operations communities need to come to some consensus.  And then I also think that the political issues are going to keep us talking for quite a bit longer.
 >>STEVE CROCKER:   Thank you.
 Okay.
 We now have Rick Lamb, also from IANA, talking about DNSSec activities for other parts of the operation; right?
 >>RICHARC LAMB:   I think Barbara mentioned some of the things I was going to talk about as well.  I am the DNSsec program manager at IANA.  And the purpose for this presentation is to let you know that we are working on things, we are trying to make things happen.  And to try to outline, as was just said, what needs to happen for the root to get signed.
 And right now, some of the issues I see, and there are three main ones I see, are some of the procedural issues.  These are things that -- like getting the IANA functions and the VeriSign contracts modified to allow us to put DS records in the root zone file.  That's something that is -- the discussions are in progress.  I can say that much.  And being I am a DNSsec program manager, I'm sometimes a little more overly optimistic, probably, about things.  But I think as far as the call of at least a year, I still completely agree with that.  Even if all, everything was pointing in our direction the way that these sort of updates and changes happen take time.  But I'm confident.  There are various parts of the U.S. government that are interested in DNSsec.
 For example, just like IPv6 was mandated for a lot of government agencies, U.S. government agencies, sometime ago, there is a similar mandate coming down the pike in the very near future, in the next, probably, month or so that will push DNSsec to all the government agencies.
 Now, that may not sound very important to this audience, but that's another big group.  That's like another TLD; okay?
 So it's a good thing to see that coming.
 And so like I said, there are some parts of the U.S. government that are very interested in DNSsec and understand all the technical issues, understand international sensitivities about how the keys should be handled.
 And so I'm hopeful.  That's in progress.
 And the other side of this is to get some additional support from the international community.
 We have gotten a lot of support already, and we have formal letters from ripe, dot SE, dot UK, and it sounds like that's easy, and many others.  I know BG, Bulgaria has also mentioned their support as well.  And there was a ccNSO survey that said 84% of the respondents believe the DNSsec was going to be deployed in their ccTLDs in the near future, and that same 84% said that they thought ICANN, IANA would be performing the function.
 But we need -- I think we need a clearer sign.  And that will also help the first bullet as well, I think if we get an overall clear sign that DNSsec is not going to go away.
 And then finally, as far as being technically ready, we have had this test bed, signed root at NS.IANA.org.  It's open to the public.  It's been operating since June of last year.  It has the full complement of very secure crypto devices, HSMs and things sitting in the background, and it was developed with a lot of help from the current DNSsec deployment community.  I have been very grateful to that group because most of our designs I just lift directly from the dot UK, dot SE, et cetera, folks.  They are absolutely the experts in this stuff.
 And we're completing some of that now.  And I will go through this next slide as quickly as I can.
 So many operational practices we are going through, and the reason I am going to mention this will become clear in a moment.  KSK management.  Who is going to do this?  That's a question.  That's something that we need to understand.  Generation, publication.  Publication of the key is what makes the KSK valuable.  Anybody can generate a key pair.  ZSK management, the signing process.  Then we need to demonstrate this whole thing to the world that it's not going to affect security and stability.  And then getting the root servers to fetch the signed root from us.
 These are some of the steps that we're going to have to go through.  Some of the steps haven't completed, and one of the aspects of this is in the KSK management, I think it's important for us to hear what the concerns are from some of the TLD community and the ccTLD community as well as far as the involvement in that.  I'm trying to develop now some sort of key signing ceremony.  This is where the KSK, the root keys would be generated, and the standard approach is to have this, like I said, a ceremony where multiple people, multiple stakeholders are involved.
 And it would be interesting to find out what kind of requirements on that people would be interested in.  I mean, how many people want to be involved.  This is a very public thing.  You want the public half of this key to be very visible.  So videotape and all that other stuff.
 But the point here is that the design -- some of the concerns can be addressed by the technical design at this stage.  So it may be really early for some of you, but to understand some of the needs, I can at least try incorporate them in the technical design, because my work in the technical area here is to make sure that we have the most optimal design from a security standpoint.
 So that's all I care about; okay?  The layer 9 stuff can come in later and change that, but I'm going by security engineering.
 Anyway, so that.
 And then the related efforts we have already talked about.  This is my last slide.
 The ITAR effort, that's wonderful.  Some test IDNs are signed, for what that's worth.  And an example would be eating your own dog food.  We intend  in signing icann.org and others, and now that dot org is making a lot of progress, this is going to dovetail nicely.
 Dot arpa transition and signing.  That is something we had agreed to do some time ago to sign dot arpa and we are still collaborating with the IAB on that as well as dealing with the Department of Commerce which may require some contract revisions in that in order to be able to sign the dot arpa zone for that particular use.
 And that's it.  I encourage questions.  I encourage you to grab me and just vent your concerns, your anger.  And that's it.
 Thanks.
 [ Applause ]
 >> A quick logistical comment while we do the presentation shuffle, for the scribes and translator and everyone else in the room and those listening, the next two links on the website were wrong up until about three minutes ago.  We just got them fixed.  So if you downloaded the slides earlier, you will need to get them right now do it again now because the next two presentations by Russ were only just fixed.
 >>STEVE CROCKER:   Before we turn this over to you, this is the transition between the section we marked as DNSsec in the field --
 >> Actually not quite yet.  It's in the center.
 >>STEVE CROCKER:   It's in the center.  Well, I am going to do this anyway.
 You're right, but I am going to do this anyway.
 So we are in reasonable shape.  Not great shape, but reasonable shape on schedule, which I really appreciate all the discipline that the speakers have had so far and that the speakers are going to have coming up.
 So we have time for about 60 seconds to get up and stretch and not enough time really to go away, but just we'll take a brief break here if you want to stretch yourself and I will count it down momentarily.
 
 
 >>STEVE CROCKER:   Okay, folks.  Time is up.
 We are going to reassemble here.
 I know this was the best part of the whole session, but it's over.
 Thank you.  Thank you very much.
 Okay.  I erred slightly.  Russ Mundy is going to close off this session with a discussion of Trust Anchor Repositories and move into the next section on tools, survey of tools.
 >>RUSS MUNDY:   It's probably just as easy if you don't mind, I can punch the buttons and you can stay wherever.
 Great, thanks, Steve.
 Am I being heard on the Mikes back there?  Yes?  No?  I usually have enough volume that people don't have a problem hearing me anyway.
 This presentation is about a white paper that was released recently on trust anchor management, and the need for Trust Anchor Repositories or lack of need for Trust Anchor Repositories.  
 Just a if I can look at the place where trust anchors and Trust Anchor Repositories might come into play.  When you have one zone that's signed, a parent that is not signed, you need to have a place to keep the keys, and people in the world need to know where to go to get the keys that they want to use for a trust anchor before they are any good being out in the world.  So if you have a signed zone and no one knows where the public key portion of it is, it doesn't really do users any good if they don't have a way to validate it.
 So the point that a trust anchor becomes a trust anchor is when some validation, some DNSsec validator function, takes a public key from some zone and starts making use of that as a secure entry point from which they will validate that zone, or that zone and those below it in the hierarchy.
 If this is chosen carefully, done well, it can provide essentially as good of security and as strong of validation as having the root signed.  And when we get to nirvana where every zone in the DNS is signed.  Which of course will happen in about two years, something like that.  Six months, yes.
 So if you make a wrong choice, though, you can have a real mess because you can end up invalidating valid material and all sorts of problems from that standpoint.
 The quality of trust anchors that some validator or some set of users that are running DNSsec validators in the world have is really the crucial issue when it comes to whether there is a need or not a need for trust anchor repositories.
 And let me just say that part of what we are trying to accomplish with this paper that was originally released on our DNSsec deployment mailing list is to try to encourage discussion, try to develop a community consensus about the need or lack of need for Trust Anchor Repositories, and if there is, indeed, a need for Trust Anchor Repositories, a description about how -- what is needed and how they might work, when are they needed, when do they need to go away and so forth.
 This illustration shows, on the left, the ideal situation of the root assigned and all the zones underneath the signing.  So DNS is a totally signed DNSsec signed operation, and so any validator in the world only needs the root trust anchor and they can validate any zone in the hierarchy.
 Well, as we said, this might happen in six years, might happen in two years, might happen in who knows when?
 But until that occurs and the entirety of the DNS is signed, you will have on an ongoing basis some number of islands of trust, is the term that's commonly used to refer to these places on the right-hand side where you see the green and there's a spot where there's a signed zone and there may be some other signed zones underneath of it.
 There may be some zones underneath of that point that aren't signed.
 So you can end up as a user who is trying to manage a large number of trust anchors saying I want to be able to validate anything that is signed anywhere in the DNS.  So if, in fact, that's what you are trying to do, you can end up with a huge number of trust anchors that you are trying to manage.
 Come on.  There you go.
 So the concept of a Trust Anchor Repository is that there will be a place established that will be a spot that can be a holder, a distributor for trust anchors that people want to make use of.  And there's several ways in which this can be done, can be established, and, over time, merged and done away with once the root and more and more DNS is signed.
 Now, the idea of what we were trying to get to is, so a trust anchor repository would be a place where all of these various signed zones throughout the hierarchy at any spot in the hierarchy, which is one of the potential architectures, could use, as a place to store their public keys so that validators that wanted to make use of them could pick them up and use them as trust anchors for their validation purposes.
 Now, this is, in fact, different than the repository that the IANA is in the process of setting up because, if you recall, it was specifically just talking about only top-level domains.  So if you look on the far right-hand side and on the left-hand side, you will see that most of the signed zones would not be able to meet the criteria that's described for the IANA planned registry.
 So of the various types of TARs that we talked about, there's three general classes.  One is what's viewed or described as the global TAR that's intended to be broad Internet wide use, Internet available, and most likely intended to eventually become smaller as more and more zones become larger -- become signed.
 Community of interest TARs are TARs that would be potentially set up by particular groups that have a specialized interest in making use of DNSsec for their particular function or applications.  They may or may not go away over time depending on the intended use.
 There are what are described as enterprise TARs which can be thought of as dealing with a single maybe large enterprise, but a single enterprise.  And again, they may or may not go away as more and more zones widely are signed.
 The focus of the paper that's been published is really on the global TARs.  The other two are there identified as possible TARs that are functionally similar but not, in fact, the focus of the paper.
 So why would you not want to have a TAR?  Why would you not want to have such a thing in existence where you could store stuff?
 Well, there have been a number of things pointed out over time, not the least of which is once a TAR gets established, it will refuse to go away forever.
 Well, we don't really know whether or not that will be the case, but that's certainly one of the often stated arguments against it.
 So one of the other ones is it is -- it establishes additional burdens on zone owners because they have to do all of the normal things they do through the regular DNS chain for NS changes and so forth with parents, and they have to do something elsewhere for DS changes.
 So there are a few other items here that are mentioned that are in the paper that I won't go into here in the interest of time.
 What we're looking at is, again, encouraging discussion.  We want to see and continue the dialogue that's going on on the mailing list.
 So there's the status quo, just wait and see what's happening.  There are a couple of potential TARs that are being looked at, being discussed.  And some of them are in operation, some are not, some are just being discussed, and waiting to see what the market pressure is.
 So that's one choice that the community can make, just wait and see what happens.
 That's one possible outcome.
 The overall document goal is like I said encourage discussion, encourage the community to consider what is needed in this space.  In fact, does a TAR or a set of TARs make sense?  Does it not?  And though I think based on the mail list discussion I have seen thus far, some people think that there is a predefined set of assumptions that TARs are needed, that certainly wasn't intended to be the case by the group that -- of several of us that put this together.  It was intended to lay out the issues, get a consensus, and whatever the results are, we'll have better guidance, communitywide, for what ought to happen and where it ought to happen and what things ought to be done going forward.
 So -- oops, went the wrong way there.
 Already, general discussions, aggregation points in terms of DNSsec are places that are looked at where a lot of zones come together that if that functional activity does DNSsec, a lot of zones can be signed quickly; okay?
 That makes a good sensible spot to think about for where a TAR might be operated from.  Possibly yes, possibly no.
 Simplicity.  Keep it easy, keep it obvious.
 And supporting the main deployment on the main tree is critical.  Now, I don't want to go through all of the separate slides and all of the separate pieces here just because we don't have that much time, but I'll just kind of hit the highlights of the ways that we looked at this.  And one of the different ways that you can operate a TAR is how you go about getting the keys.
 One is to just go out and harvest keys, any that you see, as far as a TAR operator.  Bring them all in, bring in everything you see.
 Not real strong on the security aspects of things.  In other words, someone else could be out there pretending to be somebody else and get a key implanted, and it would be relatively straightforward to spoof that.  But then you would have the widest collection of keys.
 If you have a very explicit set of things you step through where you had to pass certain hoops, then, well, like we just heard described for the IANA, there's a set of hoops that have to be passed, and so that's a different set of end results that you are going to end up with the key for acquisition.
 Then the distribution of the keys, how you would go about doing the distribution.  Another set of choices that can be made there.
 The different types of quantities of TARs.  If TARs, in general, are needed, does it make more sense to have multiples?  Does it make more sense to have one?
 Again, we're not trying to state any or -- more or less what is better or worse.  What we're trying to put out is a discussion of what we saw initially, and encourage more discussion on this issue of how many tars does it make sense to have in the world, if TARs do, indeed, make sense.
 There's alternatives in terms of the registration policy of how you go about doing this, how firm you'd be with throwing out a lower-level zone once their parent became registered to try to make the TAR become smaller as signed zones in the world became larger.  And so there's a set of registration policy alternatives.  And getting keys out related to the registration policy but slightly different, similar set of questions, though.
 And the overall phaseout of a TAR and how do you go about doing that.  
 Organizational considerations, what is the right kind of organization to run it?  How should it be structured?
 Is there a need for some kind of accreditation function or some kind of international continuity of thinking, you know, a certain set of things are required or not?  And what are the various considerations there?
 So the fundamental discussion topic that we wanted to cause to get put forth to try to reach some type of consensus over time, is there really a requirement and a need for having a global TAR for the Internet with respect to facilitating the deployment of DNSsec?
 And so this is, indeed, an open question.  A number of us that worked on it, I think, have seen that, especially with a number of the down in the hierarchy kind of domains being signed and operated and signed, it seems like it's a good idea.  But it's certainly not a predrawn conclusion.  And, you know, should we use it -- if one's needed, should we use existing?  Or is there some other set of parameters that need to be addressed here?
 So this is a very, very quick overview of the TAR discussion.  And I encourage people, if you're not already a member of the DNSsec deployment list, to sign up for that mail list.  The easiest place is to go to DNSsec-deployment.org Web site and sign up through there.  And in the archives, they're all public, you can see the discussion that's been ongoing and participate in it going forward.
 So in the interest of time, we're going to just move right on here and end the first part of DNSsec into the field and go now into DNSsec tools.
 Okay.  So number two.  I'm trying very hard to keep these within our established ten-minute limits for all of us.
 >>STEVE CROCKER:   Five now.
 >>RUSS MUNDY:   It's five now.
 No, I did want to let the TAR have a little bit more time.  So we got -- yeah.  Got it out.
 What a wonderful opportunity, though, to talk about it and not have time for questions.
 But we do want to discuss it.  Please, please do join the mailing list, please catch up with us in the hall.  This is a very important topic.  We want to try to make progress on it.
 The next presentation deals with DNSsec tools.  This is a project that is specifically work that we have done with Sparta -- as part of work we've done on Sparta on primarily DHS funding, some other efforts.  But there is a particular Web site, DNSsec-tools.org, where all of this work is available.  It's all open source.  It's all Berkeley-type license.  So there's no restrictions whatsoever on how you use it.  We encourage the broad use of it.  And it's there for the community specifically to facilitate deployment.
 There's a set of general breakout of material.  And I'll go through these and do them very quickly.  But one of the things I want to mention is, I heard several of the other presentations earlier about where people are using things that I think there are a number of tools in this tool set that may be available -- that may be useful for folks as they go take a look at it.
 In terms of -- there's core pieces, there's zone management tools, resolver management tools, developer tools, applications.  Sometimes people will say, "Well, we're not doing DNSsec 'cause there's no applications."
 We have done applications.  Again, some of them are used in conjunction with others.  And they're plug-ins.  We've got a browser, Firefox plug-in.
 DNSsec debugging tools documentation.
 So I won't go into detail on these with -- just mention a couple as we go through them.
 DNSsec validator library can be used, and it is a wholly standalone library that you can run in conjunction with other software running on a machine.
 So it gives you the ability to do validation outside of a resolver directly if this fits your needs better.  And this is, in fact, what we use predominantly to do validation with our applications that do DNSsec-driven validation.
 And so it's very flexible.  It does most all of the current standards, with the exception we're not fully up to date on NSEC3.  We only have a very early implementation of it there.  But we will get that in there, we believe, eventually.  But, otherwise, it is -- it does all of the necessary validation.
 Libval-SHIM, another detailed piece of library validation API.  We have written and submitted to the -- or through the Internet draft process, an API.  We encourage -- it was developed, really, jointly through a series of meetings that we had at IGF meetings for about two years, two and a half years.  We've tried to incorporate all the input that we've gotten there and reflected in there.  And it's been boiled up and down over time.  We think it's probably the best documented API out there, and so we encourage both the use of it, the review of it.  And if it doesn't meet your needs, we want to hear back about it and we want to know what else needs to be changed.  At some point, it will go through the IETF and become, hopefully, some API will get standardized for the interface.
 Zone management tools.  This is where a large set of compatabilities that we've heard talked about earlier really, I think, will help out, key changing can be fully automated.  The rollerd does that. 
 Donuts let you completely see what's happening with your zone file and check it.  And mapper lets you actually look at what's going on.
 So I'll show --  These are -- I have them in here mostly so you can see what shows up on the screen.  Take a look at the slides that are on the Web site, and happy to share these separately if anybody wants them.
 Just to give you an idea of what some of the tools are that are there.
 So this really is pointed at helping the ongoing operation.
 You can visually see the state of all of the zones that you care about.
 Resolver management, Trustman is one of the, I think, most important tools in this space, because it does implement RFC 5011 for trust anchor rollover.  And this is -- I think it's the first implementation out there.  I'm not sure -- I haven't seen another one.
 But this has been one of the concerns that people have, okay, we have a standard now, so do we have any code?
 Well, yes, here is some code that does RFC 5011.
 Logwatch works specifically with logwatch and is part of the mainline distribution, lets you see DNSsec errors.  So if you use logwatch today, you are already getting DNSsec-aware.
 So jump into the application.  We've got Firefox, we've got livSPF2.  And extensions let you see it right up into the applications.  So you can see e-mail.  DNSsec debugging.  We've got packet flow.  This is a very handy tool.  You can actually see where your packets are going and see where the -- each step as you go through a resolution is.
 We've got a set of documentation that's -- there's kind of two sets.  One is DNSsec tools on the tools themselves.  Another set is extended use of the tools with the BIND software, which is the main underlying name server that we make use of in our tool set.
 Hello, is this the end?  I think this is the end.  So I guess that's the last slide.
 So -- I think I was very close to my five minutes there with that.
 So the next one is on the tools survey.
 While Steve's doing the slide changing here -- boy, that was fast -- one of the other things that we've done in conjunction with our project is, we've tried to identify all of the DNSsec tools that are out in the wild, so to speak, out available for folks to use, both products, as well as open source.  And so this is the -- a recap of that.  It is available on our Web site, the DNSsec deployment Web site, which is the kind of core Web site for the project that Steve and I kind of co-PI on here.
 And the particular place is www.dNSsecdeployment.org, slash, tracker.  And everything is out there.  It's the current information.  But I wanted to have them listed here so they make it into the slides and get archived.  And we know where we are now.
 So I won't go through all of them in detail, but I do want to point to the set of name servers that are DNSsec-aware.  That's obviously a critical issue.
 There's a whole batch of key generation zone-signing things.
 Key rollover, well, it's a little sparse.  But it does exist.
 The hardware interface, we've got a batch there.  And I think that if -- I'm sure there are some things that we haven't picked up.  So I do want to take this opportunity to say, please let us know, contact me, contact, in general, or send it to the DNSsec deployment list, the various things we might have missed.  Hardware solutions, zone troubleshooting.
 And then DS record activity, how you can automate and help with doing DS records.
 And parent-child interactions.  Obviously, an important area.
 Making sure your zone is working the way you think it is and that you're able to get the material that you need.  These are what could be looked at as a TAR in some way, some of them.  And, again, the trust anchor rollover for resolvers.
 A fair number of troubleshooting tools, and then a nice size list of DNSsec-capable applications.
 And please, especially for folks in this room that hear accusations that there are no DNSsec applications, you know, please take a look -- the list isn't gigantic, but they do exist.  So it is much larger than zero.  And so they are out there.
 Developer resources, there's a set that's available out there for developers to use in testing.
 And other documentation and other aids for step-by-step activities and various how-to kinds of things.
 And this is, I think, the end of the survey.
 And I did just take a quick count -- I hadn't actually done an explicit line item.  And it's about 75 items that we have listed here.
 So I'm sure there are more.  And, please, folks who do have some DNSsec-related material, we'd love to get more information on it, whether -- you know, whether it's a product, whether it's closed source, open source, doesn't matter.  We want to try to collect all the DNSsec-related material and tools and capabilities and have them listed here.
 So that's the purpose of this survey, to provide a place where people can go to find what they're looking for in the area of DNSsec.
 So with that, I will close off this part, and I believe that is -- we go to, I think, secure64, is Joe next?
 >>STEVE CROCKER:   And, Jaap, you can make your plug for when your turn comes up next.
 >>JOE GERSCH:   Thank you.  It's an honor to be here.  The Department of Homeland Security has been a longtime supporter of DNSsec.  They funded much of the original research at universities that even led to the DNS spec, they fund tools like Russ's efforts at Sparta, and they have recently given us a grant to develop something that will help in what is perceived to be a barrier towards DNSsec adoption, which is its operational difficulty.
 Right now, to sign a zone, to deploy a zone takes a number of steps.  You have to generate keys, you have to insert the keys into the zone with an edit, you have to then sign the zone.  You then have to edit the BIND files to say, "By the way, I'm using signed files."  A number of operational steps.  And, "By the way, don't forget to do it again next month, and I hope you haven't lost the cookbook."
 So their thought, our thought, was if this can all be automated with a secure appliance and just made a turnkey operation, this ought to enable a much wider tipping point for adoption of DNSsec at ccTLDs, at registries, at ISPs, in particular, because ISPs, for example, if you've got 100,000 zones you're dealing with and you have to do this manually, it's just a very difficult operation.
 So let's go to the next slide.
 This grant was announced just last month.  We received $1.2 million.  We're working with Colorado state University as well to do this, Dr. Daniel Massey is one of our partners in this and one of the original authors of the original DNSsec.
 The first phase is an automated signing engine.  I'll spend most of my time talking about that.  And then the you a mated parent-child communications.  How do we propagate the DNS keys so we can do this much more frequently and automatically.  The motivation.  Why are they doing this?  They want to see this get deployed.  Let's take a look at what can help in this deployment.
 Basically, it's to make a turnkey appliance, a box, with some software running on it to make it simple and secure.  By simple, as I said, rather than have to do all of these steps manually, I'll show you in bait, you have to only insert one line, our DNS base, we have a secure operating system.  We have an operating system that you cannot --  It's not Linux.  It's not Windows.  It's from scratch, microoperating system that is totally resistant to malware.  You cannot inject a virus.  Root kits are detected on bootup, so are there didn't be a root kit.  There's no way -- you have to have some way of having a safe place to keeping the signing keys.  Even with a safe place to have the signing keys, you don't want a virus to get in and change the zone files.  What good is having DNSsec if the data you've got is being manipulated before it even got to the signing state.  It's a very secure operating system.
 Keeping the data safe.
 Once you have the keys online, you can do the rollover automatically, the key generation automatically, everything.  It has to be secure, as I said, the malware resistant.  It cannot be what I call silent but deadly, "We're doing all the signing for you, but we forgot to tell you what's happening."   We have to send notifications, alerts.  We have to talk to management systems, such as (inaudible) or Open View or other things to say, "Here's what's happening.  Here's the current status of your keys.  Here's what's going right.  Here's what's a warning state." And it's got to handle everything from small zones, huge zones, with millions and millions of records, or ISP situations where you have maybe only ten records per zone, but you're dealing with 100,000 zones.
 So all of that is part of this, as well as incremental zone (inaudible) I've got to tell the people from Portugal, I'm totally in agreement with your statement about why incremental zone signing is important.  We want to make it easy to deploy DNSsec, almost brainless, if at all possible.
 So, Steve, if we can go to the next.
 One back.
 Okay.  So the first thing is, if you're going to make it easy to deploy, well, how easy is easy.  We are based on -- Jaap will be glad to hear this -- we use NSD.  We think that's awesome.  We have an authoritative name center.  It builds a beautiful RB3 of all the data.  It's already in canonical and sorted order.  So we said, "Sign it in memory."  
 So the simplest way to deploy DNSsec is a single, one-line automation statement in the NSD configuration file.  "DNSsec automate on."  It doesn't get much simpler than that.  
 At that point, you're done.
 You just turn it on, you bring in the zones, it will generate the keys for you automatically.  It will insert the keys automatically.  It will sign the data automatically.  And based on various timed events, it will resign it daily, it will roll the keys monthly, it will roll the KSKs yearly.  It does all of that.  
 If you want to change any of the defaults, you can add extra configuration statements.  So you can say, "I want to actually use a 2048-bit key, instead of 1024-bit key."  So you do have control.  It's not a whole lot of extra statements.  You have control on a global basis, do this to all of the zones or you can do it on a zone-by-zone basis.  I want to use NSEC in this zone but NSEC3 in this.  I want to use a --
 So you have all the control you want, but if pretty much you want to be consistent among all zones.  You might even say, sign this zone, don't sign that zone, they didn't pay.  You have all the control, but it's all in one place in the configuration file, start it up, start up NSD, and you're delivering signed data.
 That's how you configure it.  How do you deploy it?  Well, you have a couple of options.  One is, it can be your standalone signer as well as the authoritative server all in one fell swoop.  This might be for an ISP.  Another way is what I call the sign Mr. the middle.  You may already have a provisioning system.  That provisioning system already talks to these slave servers.  By inserting the appliance into the middle with an AXFR or an IXFR talking to us, we get the unsigned zones, we sign them, and we then pass the signed data on to the next one.  By an insertion of the appliance in the middle, you've just done DNSsec, pretty much as simply as possible.
 Next slide, please.
 How fast is it?  We want it not only to be secure, not only really, really, really simple to operate, but it better be fast.  So we started looking at our operating system and what we've done and we said, let's optimize some of the crypto operations.  You can see that we're somewhat faster.  This is same hardware on a Linux operating system, and our operating system.  We're a little bit faster in the crypto operation.  But we said, let's see what happens when we use the parallel capabilities of the chip we use.  So for the 1024-bit keys, we optimize that, we're going to continue to optimize for the remaining large keys, but we're doing approximately 4,000.  So that's a quarter million signing operations per minute.
 Or 4,000 operations per second.  So it signs reasonably fast.  That's with just one core.  If you add multiple cores, you scale linearly.
 So we've optimized that bit of code.  We now that right now, most people are using 1024 bit keys, so we took the sweet spot.  But we will be going down the line as necessary.
 Incremental signing, back to Portugal, totally agree.  If you have a million records and it takes, even with 4,000 signing operations a second, a bit of time to sign that zone, we've done some things as large as dot org and we've done five million records, ten million records.
 It's not slow, but it's not fast.  If you have a duty cycle, let's suppose it takes you 15 minutes to sign a zone, and your duty cycle is you get changes every five minutes.  You cannot possibly keep up.  So the solution to that, as our friends from Portugal outlined, is, how about getting a dynamic data update or an IXFR in of just the two or three records that change that time.  Do the incremental designing.  Because we do have the keys online in a very safe environment.  And IXFR out the -- if this is one transfer in, just an A record, this might be seven transfers out to the slave servers, because you have to send the A record, the RRSIG, delete the old NSEC, add the new NSEC, delete the signatures that are invalid, add the new valid signatures, so you get seven updates from that.  
 Don't worry about it.  It just happens.  
 So incremental updates, basically, we're doing at this point, we hope to optimize that as well, about 1200 changes per minute.  That's the largest, most dynamic environments can be updated quickly with the incremental capability.
 Next, secure from compromise.
 We are taking this -- we know and have had our secure operating system evaluated by research organizations like Montasano, a very respected white hat hacking organization.  They have analyzed the architecture, they've tried to find any way to inject a piece of malware, doing buffer overflow attacks, doing stack attacks, doing Internet attacks, denial of service attacks, all sorts of things.  This operating system was designed to be self-defending and genuinely secure.  It is not a hardened operating system.  It is built with security principles from the ground up.
 We are taking that and getting FIPS140 certification for that.  We've already gotten the papers saying we have no found no way to compromise this operating system.  We believe it's going to be quite safe and certify it.
 We also make use of an Infineon in the itself, which is an off the chef --
 Which basically generates inside the chip all the roots of trust for encryption.  So the storage root key that's -- encrypts everything on the disk is basically inside a chip and can't get out.  All the operation takes place in that chip.  It's immune to malware, has key security, has a TPM in it.  We have levels of security well beyond the FIPS requirements.
 And as I said, earlier, you may have a lovely device that you can just plug in but it better tell what you it's up to.  This has been a key point that Doug (saying name) of the Department of Homeland Security said tell people what this box is doing, don't just doing the operations.  It's nice it's doing it.  When we sign something, send an event.  When a key at 30 days have passed by, it's time to roll the case, send e-mail notifications, send a sys log notification, tell people the keys have just rolled.  Because this is a set-and-forget kind of box.
 So send that notifications.  If a key is nearing expiration, send warnings.
 On-demand reporting is there as well.  But the more interesting things are, use security models for any key management process.  If you're going to do a key backup, you want to have that backup be secure it is also encrypted.  But even the fact do you it, we do secure box to secure box key backup.  Every time that happens, people have talked about multiple people, it's called trust but verify.
 Person has to be -- it's a roll-based operating system.  So it's log in as a person.  You enable the roll that you are a security administrator and you start a backup operation.  That operation must be logged to the security audit file.
 That way, a security auditor can go in and look at the log and say, oh, my gosh, somebody did a backup unauthorized.  We better have an emergency key rollover.  And those commands exist already.  The whole thing is a self-contained signing box.  DNSsec in a box.  We are in beta test right now.  It is something that's looking really sweet, frankly.  And it is going to be -- this is just a technology preview and to show you why the Department of Homeland Security is interested in this.  This should help widespread deployment as I said, at banks, financial institutions, ccTLDs, and so forth.  There will be an actual product announcement later this summer.
 Thank you.
 [ Applause ]
 >>STEVE CROCKER:   One moment.
 Let's see.  Where is so Joe mentioned it's in beta test, that their product is in beta test.
 When I'm not doing ICANN matters and so forth, I run a small company, Shinkuro.  And we're one of the beta testers for this box.
 We have set up a handful of scenarios that involve registrars, registries, various DNS name server operators and a handful of test domains, quadA.org is a cover name, because we're not ready to announce that yet.
 RRR and DDDD are also cover names for the parties involved.  But the rest are actual.
 So we have, for example, this green little square here represents Shinkuro.SE.  And we have had that in operation and signed and working with dot SE for more than a year, I think.
 So the point that I want to emphasize is that we have the secure 64 box in our shop, beginning to put it into service, and plan to have it signed four different zones and have those zones served through a variety of different parts here.  And as each of these scenarios comes alive, they will exercise different combinations of registrar, registry, name server operator, whether it's in-house or whether it's a -- an industrial-strength external server.  Label down here is coalition is Sparta, NLNetLabs, and Shinkuro providing DNS-compliant name server for whatever set of zones people want us to serve.  This is not an industrial-strength service, so we don't use this for supporting names that have to be up and operational all the time.  But it's helpful to have that as a kind of leading edge.
 Here's another organization that is not quite ready to announce, but that we'll work with them to get their zone signed.  And it's a dot org zone, and we'll put it onto PIR when they're up and ready.
 And here's a trust anchor repository for Shinkuro.com, on the assumption that COM is not going to be signed for some time to come.
 So I just wanted to mention that and support the activity that Joe's talked about.
 All right.  And now, we are privileged to have Jaap Akkerhuis from NLnetlabs, talking about unbound.
 And here we go.
 >>JAAP AKKERHUIS:   Off we go.  (inaudible).
 >>STEVE CROCKER:   Yes, we should do that.
 >>JAAP AKKERHUIS:   Unbound is validating caching resolve made up from (inaudible), again.  And it's a scaled-down version, most work is done by (inaudible) so let's move on.
 And why are we actually doing this?  Well, one of the main reasons was, we had another way of doing code diversity.  A lot of people are writing the same code, let's do it again, and mono culture.
 Another thing is an alternative validator choice for BIND.  (inaudible) is the one for BIND 9 and to test operational -- operational and interchange -- I've forgotten the words, to test that.  And so we just did it again.
 And this is, as we said, this is just a cache resolver.  Deployment times are actually people that really need local DNS resolvers, caching resolver installations like ISPs and various people like that.  And also the five validating library for -- to be used inside applications.
 The way it's set up, it's quite modular and the hope is that we can use the library for -- to be used by other applications.
 And just look at API from.
 The way it's set up, it's quite modular, and hope we can use the library for -- to be used by other applications.
 But did look at API but decided to do our own just to get experience what we really want.  And we can later figure out how we can standardize the API.  That's the idea.
 Well, we are -- NL net labs is a nonprofit public benefit foundation, and we did some other stuff with DNS like NSD, which is actually the authority for server, and DNSsec were used by couple people.  And the other thing is LDNS, the a library to simplify DNS programming.  With this library came a big set of tools, some of which are actually on the list of (inaudible), and the latest version is key resolver scheme following ISO 50 -- 51, whatever.
 And it's basically simplify DNS programming but I am not going to talk about that to save time and we can go to the next slide.
 And there is a prototype that was developed for people from (inaudible) and Nominet.  They have to build a (inaudible) with all these IDs built in.  And most prototype (inaudible) David blacker, if I'm correct.  Anyway, which was just a proof concept meant to be production quality stuff.  And, well, and that elapses all the time be sitting on the time and take it upon us to make it into production class real thing.
 Well, there's the usual DNS server features, IPv4, IPv6, recursion, caching, thread support.
 Also, when it starts up right out of the box, it's all relation to local host so we don't, by accident, put up an (inaudible) because of resolver.
 DNSsec validation actually knows about all the forms of DNSsec.  So NSEC, the class for NSEC3 is fully supported, and it's still ready for the SHA256.
 For the trust anchors, we made it feature rich because we are not sure how it's going to help, how it's going to be.
 We actually made sure that we had (inaudible) trees to store trust anchors as well.  So we saved it.  If we want to, we can do millions of trust anchors when needed.  I hope it's never needed.  But since they were added, we just do it.
 And as said, we don't do authoritative things.  It's completely absent.  Although there are some hopes for doing some authoritative stuff, like 1918 edit space, things like that.
 And at the requests of lots of people, we actually built in some steps (inaudible) authoritative answers.  That's especially because local governments allow, disallow, want to block certain domains.  So that's basically you can do a two-step resolve, and resolve stuff there.  Just people wanted.
 And full documentation and little tools.  One is just to check it's own way it's configured and it has a little program, unbound host which actually does a validated host lookup so it could see how it finds -- what it does for validating and host.
 This (inaudible).  With the LDNS its actually a better tool for doing (inaudible).
 Anyway.
 The other thing, the other feature we have is that we completed paranoia and we put in all the forgery resilience recommendations being talked about now in the IETF.  And a scrubber filter to remove packets out of zone just in case somebody manage to spoof stuff in the cache.
 The 2181 trust model is fully supported, and no shortcuts.
 There are a lot of other operating methods, a lot of random numbers for the DNSsec and IDs and things like that.
 There's also even about the round time tape -- round trip time banding.  So instead of loading onto the faster authoritative name server, there is some band, within the milliseconds, you will choose from them.  Again, it gives more end space and more security.  That's for the non DNS hookup.
 (Inaudible) about performance, we did, just to check out how this would work in practice, and some of the band test taught us that we were really fast, which we didn't believe at that time.  So set up test lab and did some testing.
 What you see in the black line there is if you have the system (inaudible) test, do nothing.  Basically echo the packets.  So what you can see there is how quick you can get the request in and out to the application and get the answer back.
 The little hump of that is what you see when you use BSD end lining system.  It's basically by the time we are trying to lose out on network traffic they start to allocate extra and extra buffers and then they kind of recover from this (inaudible) situation but start to lose as well.
 So the green line of that is the authority server and --
 >>STEVE CROCKER:   Sorry:
 >>JAAP AKKERHUIS:   That one.
 Answering as fast as possible directly.  It can do that slightly faster than the blue line, which is unbound answering.  All the questions out of the cache.
 First you just fill up complete cache.  Think of how many requests we had.  Then you are going to test another time, see how quick we get.  So you get the information about test performance.
 You can compare it to power DNS, the purple line, and a version of Binds.  
 So you see this hump in the network stack pops back in all the lines.
 >>STEVE CROCKER:   Now?
 >>JAAP AKKERHUIS:   Yep, now.
 And here you see where we do a fully recursive testing.  Basically do you that by simulating the Internet, which is a bit hard, so very simple (inaudible) off the Internet where we sent (inaudible) involved, per TLD, a thousand (inaudible) for fully qualified names.  About a hundred thousand.
 And you see that it's pretty much really what's the production standard.
 For people who want to know how we did it, it's done on AMD Athlon machine, just that you buy at the shop on the corner of any street in Amsterdam.  And yes, we can go on.
 And basically, I know there are a lot of questions and answers so I prepared some of them.
 We are validating caching resolver.  It comes with a BSD license.  As you know, three type of licenses.  Copyright, copy left and BSD is actually copy shop.
 It's highly portable on various operating systems.  That's what we used for the development.  And note that we don't support specific operating system.  We know it runs.  And (inaudible) distribution has different ways of maintaining the systems.  We leave that open to the ports, people who are doing the ports and packet managers and stuff.  But we do get support on that, special mail list for that.
 And the latest addition is Windows port.  It's actually doing better than I thought it is.  And basically it's proof concept again, and the idea is that you can run it on your window box next to all the other DNS stuff and use only the validator.  So you can do DNSsec for the masses, which is our nickname for this product.
 And more information you can get at unbound.net or nl (saying name) dot net or whatever.
 And these are the last slides.
 >>STEVE CROCKER:   That's fantastic.
 (Applause.)
 >>STEVE CROCKER:   Let me ask all of the speakers who are still here to stand up and take a bow.
 We packed an enormous amount into a relatively short period of time.
 We have another crowd waiting outside, so we need to be relatively quick, but I would like just a moment's worth of feedback on whether this format of sort of a dense run-through was a good use of the time or whether you would have preferred something else.
 >> And especially with more question and answer and less dense be better?
 >> (inaudible).
 >>STEVE CROCKER:   Yeah.
 So it was sort of a deliberate tradeoff here in just that there was an awful a lot of activity, and if we had said we were going to have that, we wouldn't have had as many talk.
 So I apologize, and that was one of the tradeoffs.
 All of the presentations are available on the net.  There's a little bit of sprucing up we are going to do on the thing, but the information is there.
 Plenty of pointers, and all of the people are available.
 So again, let me thank everybody, presenters particularly but let me thank all of you for coming.
 [ Applause ]